發版關卡上已經有功能測試、相容性檢查與 SLO 條件。資安條件要進到同一道關卡時，要先決定兩件事：哪些變更該被卡，以及卡下來的時候要求交出什麼。沒有這道關卡的團隊（推上 main 就部署）仍然用得上兩軸的判定——它產出的是「這次要不要先停下來補證據」，只是沒有一個流程節點可以掛，判定結果與收手條件寫進變更紀錄本身。這兩題答錯的方向相反——判準太寬會讓每次發版都要一輪人工審查，判準太窄會讓真正改變風險的變更沿著標準流程通過。

風險等級由變更動到哪一類資產決定

變更的風險等級由它動到哪一類資產決定。diff 的大小、涉及的檔案數與功能的商業重要性與資安風險沒有穩定關係——一行設定變更可以把管理端點開到公開網路，而一次數千行的內部重構可能完全不動任何邊界。可判定的判準因此是這張表：

命中的資產類別具體形態
認證與授權路徑誰能登入、角色與範圍的定義、會話的建立與失效
對外暴露面新端點、新入口、管理端點的可達來源、錯誤回應的詳細程度
秘密與憑證新增秘密、換發行方、改存放位置、改傳遞方式、以及既有憑證的輪替（同發行方同位置的例行輪替也算，理由見下段）
資料分級的流向把較高分級的資料送到新的儲存位置、新的接收方或新的區域，或在既有位置新增較高分級的欄位
供應鏈與部署路徑新依賴、依賴版本變動、新的 build 步驟、新的 artifact 來源、新的部署身分
既有控制的削弱關掉或放寬偵測規則、調高告警門檻、放寬限額、移除臨時的阻擋規則、移除必需的審查步驟、縮短或延長資料保留期

命中任一類就走高風險流程，而同時命中多類的變更要另外看一次：各類的證據分別通過不代表風險已經覆蓋，交互作用（新的授權範圍配上新的資料落點）不屬於任何單一類別，要在放行前明寫「這兩類交會的地方是什麼」。表中各類都沒命中的變更走標準流程。純文案與樣式是典型；內部重構要看它有沒有動到授權檢查的執行順序或錯誤處理路徑——介面不變不代表這兩者沒變，而它們落在第一類與第二類裡。判準寫成資產類別而不是變更類型，是因為讀者在發版前握有的資訊正好是「這次改了什麼」——把它對照這張表是機械動作（前提是那份對映存在，見下方預檢段），而估計「這次風險高不高」需要的是已經做完的判斷。

判定要看實際命中而不是團隊的意圖。一次「只是加一個內部用的除錯端點」的變更命中對外暴露面那一類，因為可達來源由部署位置與路由規則決定，不由命名決定。

前面幾類是加法（新增了什麼），削弱那一類是減法，而減法要靠對照上一版設定才判得出來、讀 diff 的新增行看不到——這一類最容易漏，因為它在版本控制裡看起來是變更變少。偵測與補償控制都落在這裡：關掉一條噪音大的規則會改善誤報率，而它涵蓋的攻擊路徑不會出現在任何指標上。

這張表是代理、不是機制本身。真正決定風險的是這次變更改了哪一條信任假設，而資產類別是它在發版前唯一可機械判定的代理——代價是它會過度觸發：在既有認證授權後面加一個不碰新資料的端點命中對外暴露面，而信任假設沒有變。命中而信任假設未變時可以降級成標準流程，而這個放寬有前置門檻：信任邊界清單要存在且有維護者（與下方預檢段對資產對映表的要求同一形式），降級時要指名清單上的哪一列沒有變動——指不到具體一列時降級不成立。理由寫在放行紀錄裡，而降級的次數與類別要進回寫（下方階段節奏的第五段）：某一類反覆被降級時，說明那一類的判定條件抓錯了對象，要改的是判準而不是每次都降。信任假設怎麼列舉見 7.21 的信任邊界欄。

例行輪替被放進秘密與憑證那一類的理由在這裡：輪替看起來是原地替換、沒有動到任何位置，但共用憑證牽涉的服務各自支援新舊憑證的時間窗不同，一次沒有分域的輪替會沿服務依賴擴散成控制面變更——形態與代價見 7.C9 憑證輪替未分作用域。

這一點決定了預檢要機械可判需要什麼前置資料：一份從路徑、設定檔與 manifest 欄位對映到資產類別的清單，而且發版前查得到。這份對映是一個交付物、要有維護者，內容面接 7.21 的資產分母欄（設計階段列出的清單就是它的第一版，兩處用的是同一套類別）、owner 由該章的交接路由欄指定。對映不存在時預檢退化成人工判斷（判準仍然可用，成本從對照變成討論）。這件事要留下痕跡而不是口頭承認：放行紀錄裡寫對映表的位置與維護者，寫不出來就等於宣告這次預檢是人工判斷、下方驗收條件的第一項不成立。

回退收不回來的風險要在放行前驗證

功能風險的處置有一條標準退路：出事就回退。資安風險的可逆性不同——回退還原的是系統行為，不還原已經發生的暴露。

把一個內部端點誤開到公開網路的變更，回退會把端點關掉，而這段窗口內被列舉出的資源與被取走的資料不會隨之回收；把秘密寫進映像檔的變更，回退部署不會讓那個秘密回到未外流狀態，止血動作是撤銷與替換。撤銷與替換的責任分工與生命週期見 7.6 秘密管理與機器憑證治理，而「多久算太久」那一題該章目前只提出、沒有給判準——所以放行前要自己定一個時限並確認做得到，定不出來時這個變更就是不可逆的那一類。

這一軸要問三件事，而後兩件在只問可逆性的判定裡不會浮現。機制上收得回來嗎——這次變更若判斷錯了，回退能不能把風險收回來。誰有權執行——回退權在甲方、監理機關或平台方那一側時，本地的 rollback condition 觸發了也沒有人能按下去。要多久——強制前置期（合約規定的書面申請、外部核准排隊、供應商維護窗口）會讓回退的實際延遲遠大於技術上的回退時間。後兩件任一項確認不了時，這個變更要當成不可逆處理。

有一類變更連第一件都要小心：回退到舊憑證等於把一條已經被判定為風險來源的信任路徑放回生產環境，7.C9 的處置是先分域隔離、恢復雙憑證窗口再逐批收斂，而不是回放。

第一件的判準是：收得回來的那類可以把驗證放在放行後的觀察窗口，用 rollback condition 定義收手的條件；收不回來的那類要在放行前驗證完，「出事再回退」對它不成立。兩條軸的組合決定 gate 上要求的強度：命中任一類且回退收不回風險時，證據要在放行前補齊；命中而回退收得回來的那類，可以把一部分驗證移到放行後的觀察窗口，條件是收手的門檻與觀察者都已經指定。分割的判準是驗證對象：暴露面本身（開了什麼、誰可達）留在放行前，因為它一旦開放就已經被看見；控制效果的持續性（限流有沒有持續生效、輪替有沒有跑完）才可以移到窗口內觀察。

必備控制與證據由命中的類別導出

同一份檢查表套在所有高風險變更上，會同時檢查不相關的控制而漏掉該檢查的那些。命中的類別決定要驗哪幾項：

命中的類別放行前要驗的項目
認證與授權路徑授權邊界（新的角色或範圍拿得到哪些既有資源）、高權限操作路徑、會話失效是否跟著生效
對外暴露面新端點的可達來源、認證是否掛上、錯誤回應洩不洩露內部結構
秘密與憑證秘密不在映像檔與版本控制裡、輪替的作用域切得開、撤銷路徑走得通
資料分級的流向新落點的存取控制與保留期、遮罩規則是否跟著資料走
供應鏈與部署路徑artifact 來源可驗、部署身分的權限範圍、build 步驟沒有引入未登記的外部輸入
既有控制的削弱被削弱的那條控制原本擋的是什麼、補償措施是什麼、什麼條件下恢復

每一列的項目是起點而不是完整清單：驗證方式與證據來源由該控制面自己的章節承接，分類與主責見 7.B1 防守控制面地圖、驗證分類見 7.B3 資安控制驗證。

證據的形式由 evidence package 規格化，欄位清單以那張卡為準。gate 上最容易通過而實際沒有驗到的形態是證據對應的是欄位而不是機制——這一點在下方的兩條 chain 展開。

放行決策要寫成可回放的紀錄

事故當天要回答「當時憑什麼放行」時，只有通過標記的紀錄提供不了範圍。Gate decision 的規格是同時寫出允許前進的範圍與被擋住的風險面，資安側的形態是「允許在只對內部網段開放的條件下上線，公開開放留待傳輸驗證完成」——這句話比「security review 通過」可操作，因為它讓下一個接手的人知道現在的狀態是什麼、以及什麼條件解除限制。

帶範圍限制的放行本身就是一筆風險例外。例外要填哪六個欄位、每一欄的判準是什麼，定義處是 security exception 卡；填寫時的判準與可直接複製的模板在 7.17 例外、凍結與 Tripwire；例外累積之後怎麼治理、誰負責重評估，看 7.14 資安治理例外與 Tripwire。事件驅動的回收機制見 tripwire；本章的責任只到一條時點要求：例外要在放行決策的同一刻建立，不是放行之後補登記。補登記的形態下，補償控制的生效時點晚於風險的生效時點，而那段落差不會出現在任何一份紀錄上。

高風險變更的階段節奏

高風險變更的流程分成以下幾段，每段的產出是下一段的輸入：

  1. 預檢：對照資產類別表判定是否命中、以及回退能不能收回風險。產出是風險等級與需要的證據清單。
  2. 驗證：依控制面執行對應的驗證，驗證分類（設計、技術、流程、放行、復盤）見 7.B3 資安控制驗證。產出是證據本身。
  3. 審查：檢查證據對應的是機制而不是欄位。產出是通過、退回補證據、或縮小放行範圍三者之一。
  4. 放行：寫成 gate decision，帶範圍、擋住的風險面、owner 與收手條件。範圍有限制時同步建立例外紀錄。
  5. 回寫：把這次的判定回寫到判準本身，並把放行結果交給執行層——部署流程、回退策略與事故準備度分別由 05 部署平台、06 可靠性的發布關卡 與 08 事故處理 承接。放行後出現的事故若屬於預檢判定為不命中的類別，缺的是判準的一列，回寫目標見 7.24 資安事故如何回寫產品與架構。

回寫這一段最容易被省略，因為前面各段都有明確的產出物而它沒有。省略的後果是判準停在建立當時的形態，而變更的形態會持續長出新的類別。

從關卡通過到控制實際生效

Gate 通過代表流程跑完（風險等級、必備控制、證據與例外都有填），控制是否真在生產環境生效要靠兩條 chain：

  • Evidence chain：證據列出的內容要對應到控制的實際機制，不是對應到欄位有沒有填。要證明哪些項目由控制意圖反推——把效果陳述拆成「要讓這個效果成立，有哪幾個條件必須同時成立」，每個條件各要一份證據。傳輸加密套進這條規則會得到三項，各自對應一個獨立的失效方式：通道存在（連得上 HTTPS）不含協商強度，而弱的加密套件在通道存在的前提下仍可被降級協商；協商強度不含身分有效性，過期或被撤銷的憑證照樣能完成一次加密交握；兩者都不含降級路徑有沒有封住，而 HSTS preload 的作用就是讓瀏覽器在第一次連線之前就拒絕明文（沒有它，攻擊者把使用者的第一個請求降級到 HTTP 即可繞過前兩項）。所以「連得上 HTTPS」只覆蓋第一項。憑證有效期那一項的輪替與覆蓋率機制見 7.5 傳輸信任與憑證生命週期；加密套件與 HSTS 的設定面本站尚無專章，已列入模組 backlog。
  • Re-evaluation chain：tripwire 觸發、例外到期或外部事件都會讓上一次的判定過期，回到 7.14 資安治理例外與 Tripwire 與對應主章重評估。

兩條 chain 都跑通，放行才是一次降低風險的決策。Gate 與控制的關係是關卡層對生產環境的實際狀態（模組首頁與 7.8 講的「實作層」指的是下游模組承接，不是這裡的兩層），兩層由證據的內容連起來——證據只證明欄位填了，兩層之間就是斷開的。

判讀訊號與下一步

判讀訊號代表的缺口下一步
發版條件只檢查功能測試與 SLOgate 上沒有資安證據欄位，動到邊界的變更沿標準流程通過依本章的資產類別表建立預檢；證據形式見 evidence package、驗證分類見 7.B3
例外的期限過了、放行狀態仍在生效重評估觸發器缺席，例外退化成永久狀態補 tripwire 的訊號與門檻；治理節奏與重評估責任見 7.14、欄位模板見 7.17
高風險變更的放行紀錄只有一個通過標記，查不到當時的依據放行寫成布林值而不是 gate decision，事後無法回放判斷依 gate decision 的欄位補範圍、擋住的風險面與 owner；部署側的承接見 05 部署平台
放行後發生的資安事故，屬於預檢判定為不命中的類別判準的資產類別清單缺一列，而下一次同型變更仍會判成不命中回寫判準，路徑見 7.24 資安事故如何回寫產品與架構

驗收條件

gate 上的資安條件可用的驗收是三件事同時成立：預檢能用機械對照完成（對照資產類別表判命中，不需要一輪人工風險討論；降級要寫理由，那是判斷但它有固定的問法與留痕）、必備控制由命中的類別導出（不是通用清單）、放行紀錄能讓事後的人重建當時的判斷依據。三者缺任一項時，gate 仍會產生通過紀錄，但那份紀錄無法在事故當天回答「當時憑什麼放行」。

必連章節