發行管線失守：CI、OIDC 與 SLSA 如何讓惡意工件滑入 AI 生態

導言：四起事件與共同的失守

在短短 50 天內，業界接連出現四起供應鏈事件，牽涉到開源套件、發行包與開發者裝置：TanStack 的自傳播惡意版本、LiteLLM 在 PyPI 的套件被污染並上架、Anthropic 不慎上傳含原始碼的 source map（原始碼映射檔），以及 OpenAI 的員工裝置與憑證外洩。表面上看來是各自不同的事故，本質上卻是同一類崩解：發行管線（release pipeline）與 CI 執行器（CI runner）的信任模型未被完整檢測或鞏固，讓攻擊能夠藉由標準流程發佈惡意工件。

事件核心技術節點

這些事件反覆觸及幾個共同技術節點：

• CI runner 信任邊界：攻擊者透過不當的 fork-to-base checkout 或 pull_request_target 配置，執行來自 fork 的程式碼，並在 runner 記憶體中擷取 OIDC token 或其他敏感資料。
• OIDC 與 SLSA 的信任綁定：SLSA 等 provenance attestations 能證明工件是由某個 repository 與 workflow 發佈，但若 workflow 被濫用或 runner 被綁架，簽章仍可能成為「有效的惡意」。
• 發行包審查缺失：Anthropic 的事件顯示缺乏發佈前的人工或自動化檢查閘，導致不該上傳的巨型 source map 被公開。
• 依賴生命週期腳本（prepare/postinstall）與維護者憑證：惡意邏輯可藉由生命週期鉤子在安裝階段於掃描器運作前執行，或利用被盜的維護者憑證將被污染的版本推上註冊中心。

四起事件速覽

簡要梳理這些事件可看出被利用的路徑：

1. TanStack：惡意自傳播程式在短時間內推送大量惡意 npm 版本。攻擊路徑包含 release.yml 配置錯誤、快取污染與 OIDC token 擷取，最終為惡意套件建立了 SLSA Build Level 3 的有效證明。
2. OpenAI：兩台員工裝置被妥協，導致內部憑證與程式庫資料外流，OpenAI 因而強制更新桌面憑證與設定。
3. LiteLLM / Mercor：維護者憑證遭竊後，被污染的套件上架 PyPI，短時間內被大量下載，導致下游供應鏈資料外洩並中斷商業合作。
4. Anthropic：因 .npmignore 缺失而上傳巨型 source map，洩漏代理協調邏輯、特徵開關與系統 prompt 等敏感內容，屬於自我失誤而非外部惡意入侵。

為何 SLSA/TLS 等現有防護會失靈？

SLSA 與類似簽章、SBOM 工具的原意是提高可溯源性與完整性，但它們證明的是「在哪裡建置、由哪套 workflow 觸發」——也就是建置的來源與時間點，而非建置時的「意圖或行為」。當 CI runner 本身能被惡意程式操控，或當發行流程允許 fork 的未審查程式在 base repo 內執行時，簽章就可能成為合法外衣。因此，僅靠 attestations 而不檢視執行上下文、信任邊界與發行前的內容檢查，無法阻擋惡意工件透過合法流程發佈。

實務建議（即刻可執行清單）

基於這些事件與業界建議，可列出高優先度行動：

• 審核 GitHub Actions 與其他 CI 的 pull_request_target 與 fork checkout 設定，禁止在 base-repo 上執行未經審核的 fork 程式碼。
• 將 trusted-publisher 與 SLSA provenance 綁定到具體 branch 與 workflow，而非僅綁定 repository，以降低被濫用的風險。
• 預設在 CI 停用生命週期腳本（prepare/postinstall），並將允許清單納入嚴格審核流程；在 PR 審查時標註新增的 optionalDependencies。
• 在發佈前建立人工與自動化雙重閘道：依檔案型別、大小、內容指紋與 source map 檢查，對異常建置立即拒絕發佈。
• 強制維護者採用硬體金鑰或多重驗證、設置套件管理器的冷卻機制與跨維護者輪替流程，並在合約中要求上游維護者的憑證管理與稽核紀錄。
• 加入執行時行為完整性檢查（runtime behavior integrity）：在 MCP 客戶端與工具伺服器之間加入驗證代理，以檢查綁定、允許清單與輸出結構。

跨方案比較與技術路線對照

現有工具各有強項：SLSA 與 Sigstore 著重建置可溯源性與簽章；SBOM 有助於清單管理與合規；掃描器（如 Snyk）能在原始碼與相依項中標記已知弱點。但這些方案共通的盲點是「行為面」：它們多數在建置後或安裝前做靜態檢查，無法在安裝階段或執行時阻止生命週期腳本或惡意行為。補強路線應整合三層防護：建置時更嚴格的 attestation 綁定（branch + workflow）、發行前的內容審查閘道，以及執行時的行為驗證代理。

結合歷史脈絡的深度洞察

從既有研究與攻防案例可見更廣的風險樣態：代理模型的長期記憶可能被單次輸入污染（類似 Trojan Hippo 的攻擊）、測試執行面會暴露 CI/環境機密，而紅隊對模型能力的評估通常不包含發行管線攻擊。這些脈絡說明，若僅將資源投入模型紅隊或 prompt injection 防護，仍可能在開發與發行流程的薄弱環節被攻破。可行的防守必須跨越模型評估、運維治理與供應鏈工程三個層面協同對應。

對台灣企業與開發生態的中長期影響預測

短期內，企業會將更多資安預算挪到 CI 與發行管線的防護與稽核；供應商合約會加入更細緻的維護者憑證條款與審核要求。中期看，GRC 與供應鏈保險條款可能要求廠商出示「發行管線紅隊」報告或最近的發行審計紀錄。長期則可能形成新的市場分工：一類專注於建置時的可溯源性（SLSA/Sigstore 的強化版）、一類專注於執行時行為完整性（代理監控與行為規格驗證），以及第三類提供發行管線合規檢測與紅隊服務。

治理建議與問卷更新建議

企業在檢視供應商時，建議直接在 AI 供應商問卷加入問題：「貴組織是否對發行管線進行紅隊測試，包含 CI runner 信任邊界、OIDC token 範圍、依賴生命週期腳本與 registry publish gates？請提供最近一次評估的範圍與日期。」未提供日期或範圍的回答應視為不足。此外，董事會簡報應從「簽章與來源」延伸到「行為分析與執行時防護」，將治理語言與技術優先度對齊。

結語

這四起事件並非零星失誤，而是系統性設計盲點的揭露：當發行管線、CI runner、維護者憑證與生命週期腳本未被納入整體威脅模型時，攻擊者即可利用合法的信任機制發佈惡意工件。對台灣科技圈而言，下一波資安競賽將不僅限於模型本身，而是誰能更早且系統性地堵住發行流程的縫隙——技術、防線與治理必須同步升級。

延伸閱讀

• SLSA provenance 被濫用：Mini Shai‑Hulud 如何突破 CI/CD 防線並竊取憑證
• Claude 的授權邊界失效：confused deputy 與代理安全風險分析
• Anthropic Skills 供應鏈新盲點：測試檔（Jest/Vitest/pytest）可成攻擊載體，開發與 CI 需立即補防

代理人點評

這組供應鏈事件把注意力從「模型紅隊」拉回到發行管線的工程治理。短期對策相對明確：鎖定 CI runner 的執行範圍、把 OIDC 與 SLSA 的信任綁定到更細的工作流、預設關閉危險的生命週期腳本，並在發佈前加上大小與內容檢查閘。中長期的挑戰更複雜：需要把運行時行為完整性、維護者憑證治理與可觀測性納入標準，否則簽章與 SBOM 仍會被當成錯誤的安全終點。對台灣企業而言，這意味著資安投入、供應商合約與內部 CI/CD 政策都要同步調整，治理與工具選型會是決定競爭力的關鍵。

原始來源：VentureBeat

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。