設計評審桌上要交出的資安欄位，決定後續的控制、驗證與交接能不能沿同一份判斷展開。同一組條件也可以等系統跑起來之後有人來問才補，而那時的成本結構完全不同——下一段就是這個對照。

這組欄位的形式假設有一場設計評審、以及可以被指名的承接者。沒有評審流程的團隊（兩三個人、直接部署）把它當一份寫給三個月後自己的清單即可：交接路由那一欄退化成「這件事發生時我會從哪裡知道」，而驗收條件的「具名負責人要有人在會議上點名」換成「寫下這件事將來由誰接手，即使那個人是自己」。

另一個方向的邊界是要求的來源。控制來自合約或稽核標準時，證據的受眾在組織外，而那個受眾同時決定證據計畫的保留期與可接受的形式。

設計階段與事後盤點的差別在分母的來源

資安控制的每一項都需要一個分母：要保護的資產有哪些、對外入口有幾個、憑證發出去幾張。分母不存在時，控制的完成率衡量的是「已知的那批有沒有做」，它與實際風險之間的關係未知：覆蓋率很低的系統照樣可以交出漂亮的完成率，而兩個數字之間沒有任何一條線相連。

這份分母在設計階段是設計文件的副產物。介面清單、資料表、整合對象、要存哪幾類資料，這些在設計文件裡本來就要寫，把它們抄成一份資產清單不增加額外的判斷。系統跑起來之後同一份清單要用三份互相獨立的來源對帳才重建得出來——外部掃描、設定反推、出向觀察，做法見 7.3 的資產與憑證分母的來源對帳。差別在來源的性質而不在盤點的難度：設計階段有一份權威的意圖清單，運行階段只有幾份各自不完整的觀察，而它們的差集還要再分類才知道哪一項是殘留、哪一項是本來就掃不到。

前移的另一個效果落在證據上。一個控制會不會留下可回查的紀錄，是設計時決定的；設計時沒決定，事後要驗證它有沒有生效就只能靠側面推論。

設計輸入欄位

設計評審要交出的輸入分六欄，而它們是一條鏈：先有分母才畫得出邊界、有邊界才寫得出假設、有假設才定得出控制意圖、有意圖才知道要留什麼證據、有證據才交接得出去。任一欄缺席，它下游的每一欄都失去輸入——這也是自檢有沒有漏欄的方式。表格是索引，每欄的判準在下方各自展開。

資產分母與發版關卡的判定用同一套類別，六類是：認證與授權路徑、對外暴露面、秘密與憑證、資料分級的流向、供應鏈與部署路徑、既有控制的削弱。類別的定義與各自的具體形態以 7.22 的資產類別表 為準（那裡是變更判定的視角，這裡是列舉的視角）。設計階段列得出前四類的具體項目（要開哪些端點、要發或要收哪些憑證、要存哪幾類資料、身分怎麼驗）；供應鏈與部署路徑在設計階段多半只有意圖形式（要用哪些第三方、部署身分由誰簽發），先列意圖、實體項目在實作時補；最後一類要等系統跑起來才有東西可削弱，設計階段留空。兩處用同一套類別的理由是讀者只會列舉一次資產：設計階段列出的清單就是發版預檢要對照的那一份。驗收條件是設計文件裡每一個對外介面與每一份持久化資料在清單上都有一列。列不出來的項目通常是「還沒決定要不要做」，那也是一列，標為待定並綁在同一份清單上——設計階段的待定項不進清單，就是運行階段那份掃不到的差集的來源之一。資料的分級與遮罩需求接 7.4 資料保護與遮罩治理。

信任邊界標的是信任假設在哪裡開始不再成立。設計階段的問法是把請求路徑上的每一次換手列出來——瀏覽器到服務、服務到服務、服務到佇列、服務到第三方、一個租戶的資料到另一個租戶的視野——每一次換手問「這一段的身分由誰重新驗證」。答案是「前一段已經驗過了」的位置就是一條邊界，它要嘛需要重新驗證，要嘛需要一條寫下來的理由說明為什麼可以沿用。呼叫方的身分落在使用者、系統還是委任哪一層，判準在 7.29 API 認證的信任邊界分層。

威脅假設是合法功能被重新組合成非預期用途的具體敘述，不是一份風險分類清單。設計階段最有產出的來源是流程裡的權限跳轉點：匯出、邀請、重設、審核、試用、身分切換、分享、自動化。這幾種流程的共同形態是有例外分支或角色轉換，每一個跳轉點寫一句假設就夠——「匯出功能被用來批量蒐集不屬於這個角色的資料」是一句假設，「有資料外洩風險」不是。這一欄與威脅模型的分工是粒度：模型給的是資產與邊界的系統性列舉，假設給的是單一功能上的濫用敘述。

控制意圖在設計階段能定的是效果與承接層，不是產品或規則。第一個理由是材料不足：選型的判準（成本、鎖定、營運負擔）要等平台能力、vendor 清單與預算定案，設計評審桌上還沒有這些。第二個理由是黏性：設計文件在下游被當成規格繼承，寫進去的產品名要改就得重開一次評審，成本高於沿用，於是一個順手寫下的名字變成既定事實。可交付的形式是一句「對某類資產、在某條邊界上，要能阻止某個行為，並留下可回查的紀錄」。這句話會落到哪個控制面，分類以 7.B1 防守控制面地圖 為準。這裡的「控制面」指防守責任的分工面，與基礎設施的 control plane（下發配置與策略的那一層）同名而不同義。

證據計畫回答將來拿什麼證明控制生效。要填的八欄是來源、時間窗、查詢入口、負責人、資料品質、信心水準、已知缺口、保留期，定義以 evidence package 為準（欄位有變動時改那張卡、這裡跟著改）。本章只展開保留期那一欄，因為它的值有一個卡上沒有的輸入：證據的受眾。受眾由「這個控制為什麼存在」決定，而設計階段是唯一知道答案的時點：控制來自外部義務（合約條款、稽核標準、法規）時，證據的受眾在組織外、保留期的下限是那個受眾的檢視週期——年度稽核的證據保留三十天等於稽核當天無證據。控制來自自己的風險判斷時，受眾是未來的自己，保留期取事故調查回溯得到的時間窗。設計階段就要定它的理由是證據的可得性由設計決定：一個控制若在設計時沒決定它會寫紀錄、紀錄裡會不會帶主體與時間，事後補的紀錄不涵蓋過去那段時間窗——而要驗的通常正是那段。缺這一欄的典型形態是放行時拿「連得上 https」當傳輸加密的證據，而該控制實際要證明的是加密套件、憑證有效期與 HSTS 三項——這個落差在 7.22 從關卡通過到控制實際生效 展開。

交接路由要定三樣：交接時點、交接物、以及接手的人。時點是設計評審通過的那一刻；交接物是其餘各欄的內容，包裝的格式沿用 7.8 的交接模板（設計階段填得出問題摘要、判讀訊號、風險邊界與主責角色，驗證與回退那幾項留給實作階段補）。接手的人要落到具名的角色而不是模組編號——證據計畫交給會維護那份紀錄的人（通常是負責觀測平台或資料保留的那一位）、控制意圖交給會實作它的團隊的技術負責人、資產分母交給之後要維護那份清單的人。這幾個角色在評審會議上點得出名字，而下游的承接模組（觀測、部署、可靠性、事故）是那些人各自的工作範圍，對照見模組首頁的從章節到實作的 chain。交接物寫不出來時，通常是控制意圖還停在「會做好權限控制」這種無法驗收的層次，交接流程本身沒有缺口。

設計評審上的固定問題

把資安輸入接進標準流程的最小做法是在設計評審的檢查項裡固定幾題，而題目是六欄在會議上的問法、不是另一組欄位。資產邊界與資料流向問分母那一欄；身分假設問信任邊界；秘密與憑證問分母裡最容易被跳過的那一類（這個服務會拿到哪些秘密、放在哪、誰能取；它同時是最不可逆的一類，見 7.22 的回退軸）；供應鏈路徑與回應路由問威脅假設與控制意圖的覆蓋。證據計畫與交接路由不在會議問答裡，它們由下一段的參與者組成承接——證據的提供者在場，交接的 owner 才點得出來。各題的驗收條件相同——答案要指到具體對象。「會做權限控制」是原則，「這三個端點只有帶租戶管理員角色的 token 能呼叫」是答案；「有記 log」是原則，「這個操作寫一筆帶操作者、目標資源與時間的稽核紀錄，查詢入口在某個資料集」是答案。

參與者要包含之後會被要求提供證據的角色。證據計畫由不負責維護證據的人單方面寫下時，它的成本沒有被任何人估算過，而估算錯誤要到放行前才會浮現。

這些欄位怎麼進介面契約

高風險介面與資料流的資安條件寫進介面契約之後才會被後續的實作與測試繼承。契約層要帶的是四類欄位：呼叫方要用哪一層身分、授權範圍怎麼表示、哪些操作要留稽核紀錄、以及被拒絕時回應什麼（回應的內容也是一個資安決定，錯誤訊息的詳細程度會決定攻擊者能不能靠它推回內部結構）。

契約沒帶這幾類欄位的後果是控制的位置漂移，控制本身通常還在：每個實作團隊各自在中介層補一次，補的方式不同，而稽核要問「這個限制在哪裡生效」時沒有單一答案。

判讀訊號與下一步

驗收條件

設計輸入齊備的驗收是每一欄各有一份可交接的產物，且交接物指得到具體對象。最常缺的是證據計畫與交接路由——其餘各欄的內容在設計討論中通常會被講到，而交接時點與具名負責人需要有人在會議上點名，否則輸入停在文件裡，沒有進到承接模組。

必連章節

• 7.8 模組路由：問題到服務實作
• 7.B1 防守控制面地圖
• 7.B3 資安控制驗證
• 7.22 資安風險如何進入 Release Gate