本篇的責任是說明公開事故如何從故事材料轉成工程工作流。案例的工程價值是指出少了哪個控制面、哪個檢查點與哪條回寫路徑；當成「恐懼素材」會偏離工程目標。

核心論點

事故案例的核心價值是提供反向驗證。團隊可以從攻擊路徑回推控制面失效，再把缺口寫回 problem cards、主章判讀訊號與 incident workflow。

讀者入口

本篇適合銜接 7.R7 事故案例庫 與 案例引用地圖。讀者讀完後、應該知道如何把案例引用成工程訊號、避免讓案例停在背景故事層。

案例回寫的責任邊界

案例回寫的責任是把「已發生事件」轉成「下次可先判讀的工作流」。回寫產物用控制面失效語言表達、留在新聞整理層會失去工程訊號。每個案例至少要回答三件事：

1. 哪個攻擊步驟成立了。
2. 哪個控制面在當時缺位或失效。
3. 哪個 workflow 檢查點可以提前阻斷。

Case-to-Workflow 步驟

第一步：拆事件路徑

事件拆解的責任是把故事拆成工程可驗證步驟。建議欄位：

1Entry：入口條件
2Privilege：權限提升或橫向移動條件
3Action：資料外送 / 破壞 / 勒索
4Detection：哪些訊號原本可見、哪些訊號缺失

第二步：映射控制面

控制面映射的責任是找主失效點。

第三步：抽失效樣式

失效樣式的責任是讓多個案例共用同一個改進語言。回寫位置：

1. 7.R8 控制面失效樣式
2. 7.R11 流程濫用問題卡片

抽象判準是「同類失效是否會在不同產品或不同時段重複出現」。答案是會，就要抽成 problem card。

第四步：交接 incident workflow

交接的責任是把抽象失效變成具體檢查點。每個 workflow 交接任務都要包含：

1. Trigger：何時進入這條流程。
2. Owner：誰負責做判讀與執行。
3. Evidence：收集哪些證據。
4. Exit：什麼條件代表本階段完成。

第五步：回寫主章訊號

主章回寫的責任是讓 7.x 章節更快指向問題。新增內容至少包含：

1. 判讀訊號：案例出現前的前兆。
2. 風險邊界：這輪處理先收斂到哪裡。
3. 下一步路由：收斂後交給 05/06/08 哪個模組。

三條示範回寫路徑

路徑一：身份事件

1. 案例拆解：token 濫用與權限擴散。
2. 控制面映射：7.2（主）+ 7.13（補）。
3. 問題卡片：新增或更新身份擴散類 card。
4. Workflow 交接：新增 token 失效化與 session 收斂檢查點。

路徑二：邊界入口事件

1. 案例拆解：管理面暴露與修補窗口過長。
2. 控制面映射：7.3（主）+ 7.9（生命週期節奏補）。
3. 問題卡片：入口暴露缺少分級管理樣式。
4. Workflow 交接：新增緊急修補與凍結策略。

路徑三：供應鏈事件

1. 案例拆解：artifact 來源不明、簽章驗證缺位。
2. 控制面映射：7.12（主）+ 7.14（Security Exception 與 Tripwire 補）。
3. 問題卡片：artifact provenance 缺口樣式。
4. Workflow 交接：新增 artifact 驗證、輪替、版本恢復演練檢查點。

判讀訊號與風險

邊界與常見誤判

Case-to-workflow 流程的邊界是「從案例抽控制面與流程」。它不替代 root cause 分析工具，也不替代完整 incident 指揮手冊。常見誤判如下：

1. 把案例當唯一真相：正確做法是案例提供反向驗證，不取代現場證據。
2. 只補技術控制不補流程控制：正確做法是技術控制與 workflow 檢查點同步更新。
3. 只更新 case 庫不更新主章：正確做法是回寫 7.x 判讀訊號與路由規則。

必連章節

• 7.R6 事故故事：按攻擊流程拆解弱點
• 7.R7 事故案例庫
• 7.R8 控制面失效樣式
• 7.R11 流程濫用問題卡片
• 8.8 事故報告轉 workflow

完稿判準

完稿時要至少示範三種案例回寫路徑：身份事件、邊界入口事件、供應鏈事件。每條路徑都要回答案例如何轉成控制面、problem card 與 workflow 檢查點。