7.R7.2 Supply Chain 類案例 on Tarragon

7.R7.2.1 SolarWinds 2020：更新鏈被濫用

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

2020 年公開的 SUNBURST 事件顯示，攻擊者透過供應鏈植入，將惡意行為包裹在合法更新流程中進入大量組織。

本案例的演示焦點：合法更新管道被植入後、依賴下游對「已簽章 artifact」的高度信任進行長期潛伏與橫向擴散，屬於 build / release pipeline 上游 compromise 類別。身分鏈接管、邊界零時差、資料外送速率壓力等 threat surface 由其他 case category 承擔。

攻擊路徑

滲透供應鏈節點。
在合法交付流程植入惡意內容。
依賴受害端對更新的高信任擴散。

失效控制面

更新來源信任過於單點。
行為監測難以區分合法元件與惡意利用。
供應鏈異常事件缺少快速隔離流程。

如果 workflow 少一步會發生什麼

若缺少「合法更新異常行為審查」，團隊會把事件視為一般系統活動，延長停留時間與清除成本。

可落地的 workflow 檢查點

發布前：供應鏈節點做分層信任與簽章驗證（build provenance / SBOM / 簽章不只驗發行者、還驗 build 環境一致性），mechanism 是讓「合法簽章」不等於「未被植入」。
日常：建立異常更新行為的 symptom-based alert（受信任元件的非典型網路行為 / 異常 process 子鏈、不依賴單一 IoC）。
事故中：切換受影響更新鏈、建立替代交付路徑與回復順序（前提是事先有 multi-source 更新策略、一鍵 cut-over 不能臨時設計）。

從本案例到實作的 chain

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

控制面：7.6 供應鏈完整性與 artifact 信任 + 7.5 工作負載身份與 federated trust —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Evidence chain pattern —— 把樣式轉成演練與控制欄位。
跨章交接：backend/05-deployment-platform 的交付與簽章治理、backend/08-incident-response 的供應鏈事件指揮流程。

供應鏈類事故的失效樣式不對應紅隊 problem-cards（後者集中於 tenant flow / identity flow 樣式），主要 chain 直接從控制面起步。

來源

來源	類型	可引用範圍
solarwinds.com	官方	受影響版本、植入時間軸、官方修補節奏
cisa.gov	政府/監管	受影響範圍、檢測指引、跨機構處置建議
mandiant.com	技術分析	UNC2452 TTP、後門行為特徵、long-dwell evasion telemetry

7.R7.2.2 GitHub OAuth 2022：第三方 token 供應鏈風險

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

2022 年 4 月，GitHub 公告指出攻擊者使用從第三方整合服務取得的 OAuth token 存取受影響組織資料。

本案例的演示焦點：第三方整合 OAuth token 被竊 → 跨組織下游存取的 federated trust supply-chain 風險。重點在 OAuth scope / lifetime / inventory 設計、跟身分鏈接管 (identity-access category) 形成互補視角。

攻擊路徑

攻擊第三方整合節點。
取得可用 OAuth token。
使用 token 存取下游客戶資產。

失效控制面

token 權限範圍過寬。
token 生命周期偏長，撤銷速度慢。
整合關係資產盤點與監控不足。

如果 workflow 少一步會發生什麼

若缺少「第三方 token 全域盤點與快速撤銷」，事件發生後仍會留下可用 token，形成二次入侵窗口。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：採最小權限 token 與明確用途分域（OAuth scope 不用 catch-all、按 audience 切），mechanism 是讓單個 token 接管不會通往無關資產。
日常：建立第三方整合清單與失效期限巡檢（含 token 上次使用時間、長期未用就主動失效）。
事故中：依清單自動化撤銷、輪替、補授權（前提是 token issuer 提供 bulk revocation API）。

從本案例到實作的 chain

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

控制面：7.5 工作負載身份與 federated trust + 7.8 secrets 與機器憑證治理 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Credential hygiene pattern —— 把樣式轉成 token 治理欄位與輪替演練。
跨章交接：backend/04-observability 的第三方整合監測、backend/05-deployment-platform 的部署 token 治理。

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

來源

來源	類型	可引用範圍
github.blog	官方	OAuth token 被竊起點、影響組織範圍、初步處置時序
github.blog	官方延伸	後續事件、跨整合影響評估
cisa.gov	政府/監管	跨組織 OAuth abuse / federated chain TTP

7.R7.2.3 CircleCI 2023：CI secrets 輪替壓力

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

2023 年 1 月，CircleCI 公告指出攻擊者透過員工端點入侵影響生產環境，並要求客戶輪替 secrets。

本案例的演示焦點：CI 平台側被入侵 → 客戶 secrets 整批暴露 → 下游全面輪替壓力的 secrets-blast-radius 事件。重點在 secrets 範圍 / 輪替成本與 inventory 的設計。

攻擊路徑

以端點路徑取得平台側存取能力。
觸及集中管理的 secrets。
把風險擴散到客戶部署環境。

失效控制面

CI secrets 集中化且缺少分域隔離。
輪替流程成本高，導致執行延遲。
客戶端難以快速判斷最小必要輪替範圍。

如果 workflow 少一步會發生什麼

若缺少「分批輪替與優先級排序」流程，團隊要在壓力下做全面輪替，容易造成服務中斷或遺漏。

可落地的 workflow 檢查點

發布前：定義 secrets 分級與依賴地圖（依 blast radius 分層、不只依名稱），mechanism 是讓事件期間的輪替能依風險排序、不靠 ad-hoc 判斷。
日常：定期演練 rollback strategy 與 secrets 更新（含「假設整個 CI vendor 受損」的 fire drill）。
事故中：按分級快速輪替、並記錄 MTTR（前提是事先有 secrets inventory 跟 owner mapping）。

從本案例到實作的 chain

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

控制面：7.8 secrets 與機器憑證治理 + 7.6 供應鏈完整性與 artifact 信任 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Credential hygiene pattern + Recovery readiness pattern —— 把樣式轉成輪替演練、credential 治理與回復欄位。
跨章交接：backend/05-deployment-platform 的 CI/CD 機制、backend/08-incident-response 的止血與回復順序。

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

來源

來源	類型	可引用範圍
circleci.com	官方	攻擊入口、影響範圍、初步輪替建議時序
circleci.com	官方延伸	post-incident 細節、root cause、跨客戶影響評估
cisa.gov	政府/監管	跨組織 social engineering / endpoint compromise TTP

7.R7.2.4 XZ Backdoor 2024：開源供應鏈長期滲透

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

2024 年 3 月，XZ Utils 事件揭露開源供應鏈可被長期滲透並在釋出流程埋入後門，對基礎設施信任鏈造成直接衝擊。

本案例的演示焦點：開源 maintainer 角色被長期社交滲透 → 釋出流程嵌入後門 → 跨 Linux 發行版下游擴散的 human-supply-chain 攻擊。重點在 maintainer trust governance、跟 build pipeline / artifact provenance 攻擊形成互補。

攻擊路徑

長期滲透維護流程。
在釋出包鏈條加入惡意邏輯。
透過下游發行與部署流程擴散風險。

失效控制面

開源維護與釋出治理缺少獨立覆核。
下游對上游釋出信任過高。
供應鏈檢測流程常延後辨識異常組件行為。

如果 workflow 少一步會發生什麼

若缺少「上游重大事件觸發的版本凍結與風險重評」，下游仍可能將高風險版本推進正式環境。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：關鍵依賴建立雙人覆核與來源驗證（不只 hash 比對、檢查 release-tarball 跟 git tag 的差異），mechanism 是讓 maintainer 單點失守不會直接通到下游。
日常：維護套件清單與影響面地圖（含 transitive 依賴、build-time vs runtime 區分）。
事故中：啟動版本凍結、替代版本切換與復測流程（前提是事先有「該套件 unavailable 也能 build」的 fallback 評估）。

從本案例到實作的 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 直接從控制面起步。

來源

來源	類型	可引用範圍
openwall.com	官方	第一手揭露、後門技術細節、發現時序
cisa.gov	政府/監管	受影響範圍、跨機構處置建議
nvd.nist.gov/CVE-2024-3094	技術分析	CVE 細節、build-time injection 機制

7.R7.2.5 TeamCity 2023：CI 入口漏洞與交付鏈風險

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

TeamCity CVE-2023-42793 事件顯示 CI 平台入口漏洞會直接衝擊建置與交付信任鏈。

本案例的演示焦點：CI 管理介面 auth bypass → build / artifact 接管 → 下游交付污染的 CI-entrypoint supply-chain 鏈。跟 2024 雙漏洞事件互補、共同說明 CI 平台暴露面治理。

攻擊路徑

掃描並利用 TeamCity 管理入口漏洞。
取得 CI 管理權限或執行能力。
影響 build artifact 與下游部署流程。

失效控制面

CI 管理介面暴露面過高。
建置輸出完整性驗證不足。
平台事件與下游部署凍結流程連動不足。

如果 workflow 少一步會發生什麼

若少了「CI 平台事件觸發部署凍結」步驟，受污染 artifact 可能持續流向正式環境。

可落地的 workflow 檢查點

發布前：建立 CI 管理入口隔離與最小存取權限（內網 only、強制 MFA），mechanism 是讓 entrypoint 漏洞先碰到網段邊界。
日常：對 build pipeline 建立 symptom-based alert（unauthorized config change、異常 build trigger）。
事故中：暫停發佈、驗證 artifact、按優先級恢復（前提是 artifact 有 build provenance、可追溯產生時間）。

從本案例到實作的 chain

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

控制面：7.6 供應鏈完整性與 artifact 信任 + 7.3 入口與伺服端保護 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern —— 把樣式轉成 CI 凍結演練、漏洞處理欄位。
跨章交接：backend/05-deployment-platform 的 CI/CD 信任鏈、backend/08-incident-response 的凍結與回復流程。

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

來源

來源	類型	可引用範圍
blog.jetbrains.com	官方	受影響版本、漏洞細節、修補時序
cisa.gov	政府/監管	受影響範圍、跨機構處置建議
nvd.nist.gov/CVE-2023-42793	技術分析	CVE 細節、auth bypass 機制

7.R7.2.6 ScreenConnect 2024：RMM 平台入口與下游擴散

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

ConnectWise ScreenConnect CVE-2024-1709 事件突顯 RMM 平台事件會沿著維運供應鏈向多客戶擴散。

本案例的演示焦點：RMM 平台 auth bypass → 維運通道接管 → 客戶環境同時受影響的 fan-out 模式。跟 Kaseya 類似但 entrypoint 是 web admin 認證繞過、屬 entrypoint-side supply-chain 變體。

攻擊路徑

利用 RMM 平台漏洞取得管理能力。
接觸維運節點與客戶端連線能力。
透過既有信任路徑擴大影響範圍。

失效控制面

RMM 節點權限集中且邊界分離不足。
客戶環境缺少獨立限制與跳板治理。
事件時的連線停用與重授權流程準備度不足。

如果 workflow 少一步會發生什麼

若少了「RMM 事件後連線總開關」步驟，攻擊者可沿既有管理通道持續操作下游資產。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：將 RMM 權限與客戶域做嚴格分域（管理介面強制 MFA + 來源限制、客戶側端點不直連管理平面），mechanism 是讓平台漏洞不直接通到客戶資產。
日常：建立遠端管理連線基線與稽核節奏（哪個 operator 在哪個時段對哪個客戶進行哪類操作的 audit trail）。
事故中：先關閉高風險連線、再分批重啟授權（前提是事先有「總開關」設計、不臨時找)。

從本案例到實作的 chain

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

控制面：7.3 入口與伺服端保護 + 7.6 供應鏈完整性與 artifact 信任 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Control owner pattern —— 把樣式轉成漏洞處理、跨組織 owner 分工。
跨章交接：backend/08-incident-response 的跨團隊升級路由、backend/05-deployment-platform 的維運平台治理。

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

來源

來源	類型	可引用範圍
connectwise.com	官方	受影響版本、漏洞細節、修補節奏
cisa.gov	政府/監管	KEV 列入、跨機構處置建議
nvd.nist.gov/CVE-2024-1709	技術分析	CVE 細節、auth bypass 機制

7.R7.2.7 Log4Shell 2021：共用元件風險與修補鏈

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

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

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

攻擊路徑

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

失效控制面

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

如果 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 直接從控制面起步。

來源

來源	類型	可引用範圍
logging.apache.org	官方	受影響版本、修補節奏、緩解 / patch 區別
cisa.gov	政府/監管	跨機構處置建議、scanning 工具清單
nvd.nist.gov/CVE-2021-44228	技術分析	CVE 細節、JNDI lookup 利用機制

7.R7.2.8 3CX 2023：桌面軟體更新鏈攻擊

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

3CX 2023 事件展示桌面軟體更新鏈受攻擊後，企業端點會同步暴露於供應鏈風險。

本案例的演示焦點：桌面應用更新管道被植入 → 企業端點受信任安裝 → 端點成為後續控制節點的 build / release pipeline 上游 compromise。屬於跨平台桌面更新鏈類別、跟 server-side artifact 攻擊鏈互補。

攻擊路徑

攻擊者污染桌面應用程式交付流程。
受影響版本進入企業端點。
端點成為後續滲透與控制節點。

失效控制面

更新來源信任缺少多重驗證。
端點行為異常檢測與更新事件未連動。
事件時版本凍結與替代方案準備不足。

如果 workflow 少一步會發生什麼

若少了「供應鏈事件即凍結更新版本」步驟，受影響版本仍會在內部持續擴散。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：建立更新簽章與來源完整性檢查（簽章鏈到 build provenance、不只發行者公鑰），mechanism 是讓「合法簽章」不等於「未被植入」。
日常：將端點異常與更新事件關聯到同一告警流程（受信任應用 spawn 異常 process / 異常網路 callback）。
事故中：凍結版本、隔離端點、驗證恢復清單（前提是 endpoint inventory 可在事件期間快速 query 已安裝版本）。

從本案例到實作的 chain

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

控制面：7.6 供應鏈完整性與 artifact 信任 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Evidence chain pattern —— 把樣式轉成演練與控制欄位。
跨章交接：backend/05-deployment-platform 的交付鏈風險治理、backend/08-incident-response 的隔離與恢復協作。

供應鏈類事故不對應紅隊 problem-cards（後者集中於 tenant flow / identity flow），主要 chain 直接從控制面起步。

來源

來源	類型	可引用範圍
3cx.com	官方	受影響版本、植入時間軸、官方修補節奏
cisa.gov	政府/監管	受影響範圍、檢測指引
sentinelone.com	技術分析	SmoothOperator campaign TTP、後門行為特徵 telemetry

7.R7.2.9 Kaseya VSA 2021：MSP 供應鏈擴散路徑

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

Kaseya VSA 2021 事件指出 MSP 管理平台若失守，攻擊可沿著託管關係快速擴展到多個客戶環境。

本案例的演示焦點：MSP / RMM 管理平面被入侵 → 透過自動化能力批次下發 → 多客戶同時感染的 fan-out 供應鏈擴散。重點在「管理平面權限範圍」與「客戶分域隔離」設計。

攻擊路徑

攻擊管理平台入口。
透過自動化管理能力下發惡意行為。
連鎖影響多個下游客戶系統。

失效控制面

管理平面與客戶環境隔離不足。
自動化任務缺少高風險動作保護。
多租戶事件協調流程準備不足。

如果 workflow 少一步會發生什麼

若少了「跨客戶分批隔離」步驟，事件會在同一時間窗內形成大規模連鎖衝擊。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：限制管理平面高風險任務範圍（破壞性動作要求 multi-party approval / 批次上限），mechanism 是讓單點接管不會立刻 fan-out 到所有客戶。
日常：建立多租戶事件通知與處置模板（含跨時區、跨法域的客戶通報路由）。
事故中：先分域隔離、再啟動客戶側回復計畫（前提是事先有客戶分組與隔離開關）。

從本案例到實作的 chain

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

控制面：7.6 供應鏈完整性與 artifact 信任 + 7.5 工作負載身份與 federated trust —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Recovery readiness pattern + Vulnerability response pattern —— 把樣式轉成多租戶演練、回復欄位與漏洞處理流程。
跨章交接：backend/08-incident-response 的跨組織通訊節奏、backend/05-deployment-platform 的多租戶部署治理。

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

來源

來源	類型	可引用範圍
helpdesk.kaseya.com	官方	受影響版本、修補時序、客戶通報節奏
cisa.gov	政府/監管	受影響範圍、檢測指引、跨機構處置建議
nvd.nist.gov/CVE-2021-30116	技術分析	CVE 細節、authenticated bypass 機制

7.R7.2.10 TeamCity 2024：CVE-2024-27198/27199 入口鏈

Fri, 24 Apr 2026 00:00:00 +0000

事故摘要

TeamCity 2024 事件顯示 CI 平台在認證繞過與路徑穿越漏洞同時存在時，交付鏈風險會被快速放大。

本案例的演示焦點：CI 管理介面 auth bypass + path traversal 雙漏洞 → build pipeline 接管 → artifact 污染擴散下游。屬 CI-platform entrypoint 漏洞鏈、跟 SolarWinds 類 build-time 植入互補。

攻擊路徑

攻擊者鎖定可達 TeamCity 管理入口。
利用 CVE-2024-27198 或 CVE-2024-27199 取得未授權能力。
觸及 build 任務與 artifact 交付路徑。

失效控制面

CI 管理介面隔離與存取控制不足。
交付鏈完整性驗證節奏不足。
事件時部署凍結與回退流程聯動不足。

如果 workflow 少一步會發生什麼

若少了「CI 事件即凍結交付」步驟，受影響 artifact 仍可能持續流向正式環境。

可落地的 workflow 檢查點

共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
發布前：管理入口採最小權限與網段隔離（VPN-only / 內網 only、不直接外網可達），mechanism 是讓 entrypoint 漏洞先碰到網段邊界。
日常：建立 build 異常行為與 pipeline 變更告警（unauthorized build trigger / 異常 build script 變更）。
事故中：凍結部署、驗證 artifact、分批恢復發佈（前提是 artifact 有 provenance 可追溯 build 是否在事件窗口內產生）。

從本案例到實作的 chain

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

控制面：7.6 供應鏈完整性與 artifact 信任 + 7.3 入口與伺服端保護 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Evidence chain pattern —— 把樣式轉成 CI 凍結演練、artifact 證據鏈。
跨章交接：backend/05-deployment-platform 的 CI/CD 交付信任鏈、backend/08-incident-response 的凍結與回復節奏。

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

來源

來源	類型	可引用範圍
blog.jetbrains.com	官方	受影響版本、雙漏洞細節、修補節奏
cisa.gov	政府/監管	KEV 列入、跨機構處置建議
nvd.nist.gov/CVE-2024-27199	技術分析	CVE 細節、auth bypass + path traversal 機制