SecTor 2025 | What If We Caught SUNBURST in CI/CD?
三句話摘要
以 SolarWinds Sunburst 供應鏈攻擊為案例，提出 AI 增強型 DevSecOps 2.0 架構，將 ML 模型嵌入 CI/CD 全流程以主動獵殺威脅。 簽章不等於安全——把 AI 嵌入 CI/CD 全流程、以零信任假設建置管線、並主動獵殺威脅，才是對抗現代供應鏈攻擊的正確姿態。 信任本身是漏洞：Sunburst 之所以成功，是因為建置管線完全信任輸入；在 2025 年的 NX 攻擊中同樣的「信任被濫用」模式再次出現，零信任已從選項變成強制要求。
重點整理
重點- 1
信任本身是漏洞：Sunburst 之所以成功，是因為建置管線完全信任輸入；在 2025 年的 NX 攻擊中同樣的「信任被濫用」模式再次出現，零信任已從選項變成強制要求。
- 2
攻擊速度的質變：Sunburst 是人工操作、耗時超過一年；現代供應鏈攻擊（如 NX）改以自動化驅動，目標從「隱匿」轉為「在最短時間造成最大損害」，防禦方若不引入 AI 速度根本跟不上。
- 3
CI/CD 管線即攻擊面：講者建議將 DevSecOps 所有權從傳統 SDLC 延伸至 Artifact Registry、Progressive Rollout、Runtime 及 Post-installation 客戶端防禦，並透過 Risk Fusion Engine 整合所有 ML 模型的輸出，做出單一「可部署 / 封鎖 / 待審」決策。
- 4
AI 不能替代所有環節：一般 LLM（如 GPT-4）僅適合做 Golden Build 異常偵測；PR 審查與 AST-to-CFG 二進位對齊因幻覺風險太高不建議用通用模型，需要針對特定數據集訓練或仍使用傳統統計方法。
實用技巧與重點
乾貨- 攻擊時間線：2019/09 植入 Sunspot → 2019/10 乾跑測試成功 → 2020/02 惡意程式碼注入 DLL → 2020/03-06 隨合法更新發佈 → 2020/06 反鑑識移除後門 → 2020/12 FireEye 公開揭露 → 一週後 Microsoft + FireEye 共同接管 C2 網域
- 休眠 payload 行為：潛伏 12–14 天後才啟動，依條件自毀或執行；建立 C2 連線、資料外洩
- 6 個 ML 控制點模型建議：
- Build 異常偵測：Unsupervised anomaly detection（對比 Golden Build）
- 來源驗證：RAG 模型訓練於 SLSA / SSDF 框架
- Binary-to-Source 一致性：AST vs CFG 對齊（仍屬研究原型，生產環境謹慎）
- 休眠 payload 偵測：傳統 ML 分類器（sleep patterns、timer 偵測）
- PR 高信心審查：兩階段——AI 初篩高信心風險 → 人工 AppSec 複審
- 第三方依賴風險：Graph Neural Network（GNN）偵測 squatting / dependency confusion
- Artifact Registry 階段：Risk Fusion Engine 整合所有模型風險分數 → Canary → Telemetry Tenant → 全量 Rollout；失敗自動回滾
- 運算成本警示：Binary diffing 為 CPU 密集作業，建議僅在 staging → master merge 時執行，而非每次 commit
- RACI 架構：將新 DevSecOps 控制區域分配給 AppSec、DART、SOC、Threat Intel、Offensive Security 各團隊
- ML 管線架構要點：Hermetic builds for ML models、Zero trust between model planes、Secure data lake with append-only store、Model registry 存放簽章與 attestation、Risk Fusion Engine 做最終 promote/block 決策
- 框架參考：SLSA、SSDF
結論
結論“簽章不等於安全——把 AI 嵌入 CI/CD 全流程、以零信任假設建置管線、並主動獵殺威脅，才是對抗現代供應鏈攻擊的正確姿態。”
完整解析
詳細SolarWinds Sunburst 攻擊發生於 2020 年，但其留下的教訓至今仍未被充分吸收。講者以「如果當時有能力偵測，我們應該怎麼做」為切入點，拒絕單純的事後復盤，而是以這起攻擊為藍本，推導出一套 AI 增強型 DevSecOps 2.0 架構。
Sunburst 的殺傷力在於其精心設計的隱匿性。AP29（Cozy Bear）在 2019 年 9 月入侵 SolarWinds 內網後，植入了 Sunspot——一個監控建置流程的工具，確認目標程序後才注入惡意程式碼。同年 10 月乾跑成功，確認惡意程式碼能被正常編譯、簽署並發佈。2020 年 2 月正式將後門注入合法 DLL 檔，隨後幾個月跟著官方更新一起被分送給數千家客戶。由於 build pipeline 隱式信任整個流程，沒有任何環節質疑「這段程式碼是否應該在這裡」。Payload 在部署後潛伏 12 到 14 天才啟動，並依環境條件決定自毀或執行 C2 連線與資料外洩，直到 2020 年 12 月才由 FireEye 公開揭露。相比之下，2025 年 9 月初的 NX 攻擊顯示攻擊者已從「慢速潛伏」轉向「全自動化、追求最大損傷」，速度提升帶來根本性的威脅型態改變。
面對這樣的攻擊，講者指出當時存在三大系統性缺口：缺乏控制流分析與反鑑識手法偵測能力、缺乏行為與網路層面的異常偵測、以及沒有持續性的安全態勢管理框架。所有訊號其實都已存在於管線中，只是沒有自動化與 AI 能及時反應。為此，講者提出將 DevSecOps 的所有權從傳統 SDLC 擴展至 Artifact Registry、Progressive Rollout、Runtime 行為監控，直到 Post-installation 客戶端防禦，並在最外圈加入威脅情報與偵測工程的閉環，讓 IOC 自動生成後回饋到 Source Control，形成真正的主動獵威脅（ThreatOps）循環。
在具體實作上，講者針對 Source Control 與 Build 階段提出六個 ML 控制點，包含以無監督學習比對 Golden Build 的異常偵測、基於 RAG 模型訓練 SLSA/SSDF 框架的來源驗證、用 GNN 做第三方依賴風險圖分析，以及兩階段 PR 審查（AI 初篩高信心風險，人工 AppSec 複審以降低誤報）。所有模型的輸出最終匯入 Risk Fusion Engine，產生單一風險評分，驅動 Canary → Telemetry Tenant → 全量發佈的 Progressive Delivery，失敗即自動回滾。整套 ML 管線採用 Hermetic Build、模型間零信任、Append-only Secure Data Lake 與模型簽章 Registry，確保供應鏈安全延伸到 AI 模型本身。在組織層面，講者以 RACI 矩陣明確劃分 AppSec、DART、SOC、Threat Intel 與 Offensive Security 各團隊的責任邊界，強調安全不是單一團隊的問題，而是全組織的啟動器。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
