事故摘要

Log4Shell 事件說明共用元件漏洞可在短時間內跨服務擴散，形成大規模修補與驗證壓力。

本案例的演示焦點：共用元件 zero-day → 跨服務同時暴露 → SBOM / 依賴 inventory 緊急檢索 → 大規模分批修補的 transitive-dependency 危機。重點在依賴可見性與分批修補節奏。

攻擊路徑

1. 攻擊者偵測含漏洞元件的可達服務。
2. 透過日誌處理路徑觸發遠端執行。
3. 沿著相依資產清單擴大利用範圍。

失效控制面

• 相依套件盤點與版本可見性不足。
• 修補節奏缺少業務優先級路由。
• 修補完成後驗證流程覆蓋不足。

如果 workflow 少一步會發生什麼

若少了「修補後主動復測」步驟，團隊會把版本更新等同風險關閉，留下可利用殘餘面。

可落地的 workflow 檢查點

• 發布前：維護關鍵套件 SBOM 與影響面對照（含 transitive 依賴、不只直接 import），mechanism 是讓事件期間能在分鐘級回答「我們有沒有在用」。
• 日常：對高風險元件建立固定巡檢節奏（component criticality + reachability 分層、不全面平均掃）。
• 事故中：按服務層級修補並追蹤 MTTR（前提是修補後有 functional + security 雙重 verify、不只 build pass）。

從本案例到實作的 chain

本案例是事故敘事 layer，沿三步 chain 進入 implementation：

• 控制面：7.6 供應鏈完整性與 artifact 信任 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
• 演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Recovery readiness pattern —— 把樣式轉成 SBOM 演練、漏洞分批處理欄位。
• 跨章交接：backend/05-deployment-platform 的依賴治理與版本策略、backend/06-reliability 的回復與驗證節奏。

供應鏈類事故不對應紅隊 problem-cards，主要 chain 直接從控制面起步。

來源