核心論點

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

讀者入口

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

三種治理狀態與責任

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

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

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 設計協議

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

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

建議把 tripwire 拆成三層：

供應鏈情境下的連動設計

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

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

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

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

可直接套用的決策模板

1Decision ID:
2Risk scope:
3Exception expiry:
4Compensating controls:
5Freeze scope / allowlist:
6Tripwire signal + threshold:
7Escalation owner:
8Close criteria:
9Write-back target:

模板責任是讓治理決策可重用，不讓每次事件都重頭設計欄位。

邊界與常見誤判

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

1. 把 freeze 當永久策略：正確做法是 freeze 有解除條件與評估節奏。
2. 把 tripwire 當提醒文字：正確做法是有量化門檻與 owner。
3. 把 exception 當管理同意：正確做法是例外協議包含補償控制與關閉條件。

必連章節

• 7.9 服務生命週期的資安風險節奏
• 7.12 供應鏈完整性與 Artifact 信任
• 7.14 資安治理例外與 Tripwire
• 發佈凍結缺少重評估觸發器
• 例外缺少期限與關閉條件

完稿判準

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

概念位置

Security exception 位在 Release Gate、Release Freeze 與 Tripwire 之間。它承接治理層決策，並把決策資訊交給部署與 incident workflow。

可觀察訊號

系統需要 security exception 的訊號是：

• 修補窗口與業務時程暫時不一致
• 高風險項目需要短期過渡方案
• 團隊需要紀錄接受範圍與期限
• 關閉條件需要跨角色共識與可驗證證據

接近真實網路服務的例子

新漏洞公告後，某服務在修補完成前以例外方式允許受控上線，同步啟用補償控制（流量限制、額外審計、強化告警），並設定到期日與重評估會議時間。

設計責任

Security exception 要定義 risk scope、expiry、compensating controls、owner、close criteria 與 write-back target。例外成立的同時，也要同步設計關閉節奏與回寫路徑。

常見形成條件

• 例外申請缺少量化關閉條件。
• 例外期間缺少補償控制與監測 runbook。
• 重大事件發生後沒有觸發例外重審。

判讀訊號

• 例外決策長期存續且無重評估記錄。
• 例外到期後仍自動延長。
• 關鍵風險指標變化時例外狀態沒有同步調整與 incident timeline 回寫。

案例觸發參考

• PAN-OS 2024
• XZ 2024
• Uber 2022

來源流程卡

• 方案升降級流程濫用

下一步路由

本失效樣式對應的實作 chain：

控制面（mitigation 在這裡定義）：

• 7.13 安全事件路由

演練 / 控制落地（轉成欄位）：

• Exercise write-back pattern