本篇的責任是說明資安決策如何避免過期。現實服務一定會有例外、凍結與暫時接受風險的時刻，成熟度在於每個決策都有期限、補償控制與重評估觸發器。

核心論點

Tripwire 的核心概念是「讓風險接受決策在條件改變時自動回到檯面」。Security Exception 與 Release Freeze 都需要 tripwire，因為它們本質上是有期限的治理狀態。

讀者入口

本篇適合銜接 7.12 供應鏈完整性與 Artifact 信任 與 7.14 資安治理例外與 Tripwire。它也會連到 Release Gate 與 incident workflow。

三種治理狀態與責任

資安決策在服務生命週期常見三種治理狀態：

狀態核心責任產出
Security Exception限制風險接受範圍與期限例外紀錄、補償控制、關閉條件
Release Freeze暫停高風險變更進入正式環境凍結範圍、放行條件、解除條件
Tripwire定義重評估觸發時機與升級路徑觸發條件、告警對象、回到決策會議流程

三者共同目標是維持「可追蹤、可關閉、可回寫」。

Exception 設計協議

Security exception 協議的責任是把暫時接受風險變成可管理狀態。每筆 exception 要填六欄，欄位的定義以那張卡為準、本節給填寫時的判準：

  1. Risk scope：接受風險的資產與範圍。
  2. Expiry：到期日與下次審查時間。
  3. Compensating controls：過渡期間的防護補強。
  4. Owner：業務 owner 與技術 owner。
  5. Exit criteria：例外關閉條件，要寫成可驗證的狀態而不是「風險已降低」。
  6. Write-back target：關閉後回寫的位置。

Release Freeze 設計協議

Release freeze 的責任是保護正式環境，直到關鍵風險收斂。freeze 設計至少要回答：

  1. Freeze scope：凍結哪些系統、哪些變更類型。
  2. Allowlist：哪些必要變更可以例外放行。
  3. Validation gate：放行前要通過哪些驗證。
  4. Unfreeze condition：什麼條件可以解除凍結。

freeze 與 exception 的關係是：exception 定義風險接受，freeze 定義變更節奏。兩者都是 tripwire 的觀察對象（方向是 tripwire 指向它們），而該不該掛看關閉條件的性質——依賴外部事件或時間不可預測的必須掛，判準見 security exception 卡。

Tripwire 設計協議

Tripwire 的責任是讓決策在條件改變時自動回到檯面。每個 tripwire 都要有：

  1. Trigger signal：可觀測且可量測的觸發訊號。
  2. Threshold：達到什麼門檻觸發。
  3. Escalation owner：誰負責啟動重評估。
  4. Decision route：觸發後回到哪個決策流程。

建議把 tripwire 拆成三層：

層級觸發來源例子
技術訊號監控、掃描、驗證結果artifact provenance 驗證失敗率超標
流程訊號發佈節奏、例外到期、審查逾期freeze 超過預設窗口仍未重評估
外部訊號公開漏洞、供應鏈公告、法規變更上游供應商通報高風險憑證事件

供應鏈情境下的連動設計

供應鏈情境的責任是把三種治理狀態串成閉環：

  1. Exception：在修復窗口內接受有限風險，限制到特定資產。
  2. Freeze：暫停高風險 artifact provenance 部署，僅 allowlist 放行。
  3. Tripwire：監測 artifact 驗證、secrets 輪替、版本恢復演練訊號。
  4. Close：條件達成後解除 exception / freeze，回寫到 problem cards 與 workflow。

這條路徑可以對應 發佈凍結缺少重評估觸發器 與 例外缺少期限與關閉條件。

判讀訊號、風險與下一步路由

判讀訊號代表風險下一步路由
Security exception 項目沒有到期日風險接受狀態失去關閉機制回到 7.14 補 expiry 與 exit criteria
Release freeze 已啟動但沒有 allowlist 契約關鍵修復與運維操作被一併阻斷補 freeze scope 與 allowlist
有 Tripwire 名稱但沒有量化門檻觸發條件不可驗證，決策回收不穩定補 threshold 與 escalation owner
Security exception 關閉後沒有回寫同類風險下次仍靠人工記憶回寫到 problem cards 與 incident workflow

可直接套用的決策模板

 1Decision ID:            # 這份紀錄的識別碼，沿用團隊既有的工單或文件編號即可
 2Risk scope:             # 接受風險的資產與邊界
 3Approved by:            # 批准這筆風險接受的人
 4Exception expiry:       # 失效日
 5Next review date:       # 到期前的審查日（依賴外部事件時，這一行才是有效的那個日期）
 6Compensating controls:  # 過渡期間的額外監測、限制或人工檢查
 7Exception owner（業務側）:
 8Exception owner（技術側）:
 9Exit criteria:          # 可驗證且可達成的關閉條件
10Write-back target:      # 關閉後知識要寫回哪份文件、哪張卡、哪個案例索引
11
12# 以下兩組視情況填，沒有就整行刪掉
13
14Freeze scope / allowlist:   # 這筆例外同時觸發發佈凍結時才填
15Unfreeze condition:         # 同上，解除凍結的條件
16Tripwire signal + threshold:  # 關閉依賴外部事件或時間不可預測時必填
17Tripwire escalation owner:    # 同上

模板責任是讓治理決策可重用，不讓每次事件都重頭設計欄位。空行以上是每筆例外都要填的，以下兩組視情況——沒有同時凍結發佈就刪掉 freeze 那兩行，關閉純粹依賴內部工期就刪掉 tripwire 那兩行。

三個物件各有自己的 owner，而它們不是同一個角色：例外的 owner 承擔關閉，tripwire 的升級對象承擔重評估的啟動，批准者承擔的是「同意接受這個風險」。一筆例外只填了 tripwire 的升級對象時，沒有人負責關閉它。

邊界與常見誤判

本篇邊界是治理決策協議，不替代 incident 指揮細節與修復 runbook。常見誤判如下：

  1. 把 freeze 當永久策略：正確做法是 freeze 有解除條件與評估節奏。
  2. 把 tripwire 當提醒文字：正確做法是有量化門檻與 owner。
  3. 把 exception 當成「管理層點頭就好」：正確做法是例外協議包含補償控制與關閉條件，批准本身只是其中一欄。

必連章節

完稿判準

完稿時要讓讀者能設計一個例外決策模板。模板至少包含風險接受條件、到期日、補償控制、tripwire、關閉條件與回寫位置。