SLSA provenance 被濫用：Mini Shai‑Hulud 如何突破 CI/CD 防線並竊取憑證

Mini Shai‑Hulud：一個憑證偷取與持久化的供應鏈蠕蟲

自 5 月 11 日起，安全社群發現名為「Mini Shai‑Hulud」的供應鏈蠕蟲在 npm 與 PyPI 上傳播。起初集中在若干 @tanstack/* 套件，短時間內擴及更多套件與版本。這一波攻擊的關鍵，不在於偽造簽章，而是濫用既有的 CI/CD 信任範圍，使帶有合法 SLSA 構建來源證明的惡意版本仍能發佈到套件註冊中心。

攻擊手法與技術細節

攻擊者將多種技術串接成一條可運作的殺鏈：首先利用 fork 與孤立提交（orphaned commit）避開一般的分支檢索，觸發含有 pull_request_target 的工作流程，讓 runner 執行不受信任的 fork 程式碼；其後汙染 GitHub Actions 的快取，令後續合併與 release 工作流程還原到被汙染的狀態。

在 CI runner 上，惡意二進位讀取執行中程序的記憶體（例如透過 /proc/<pid>/mem），提取 OIDC id token 等機密，並直接向註冊中心提交已簽章的惡意發行。重要的是，每個惡意版本都帶有真實的 SLSA Build Level 3 provenance attest，因此傳統以 provenance 認定發行來源安全的做法在此失效。

被攻擊的目標與資料竊取範圍

被植入的惡意程式會在受影響的開發者主機或 CI 內蒐集大量敏感資料，包括但不限於 AWS 金鑰、SSH 私鑰、npm token、GitHub 個人存取權杖、HashiCorp Vault token、Kubernetes service account、Docker 設定、Shell 歷史以及加密貨幣錢包。值得注意的是，這一波也開始直接竊取 AI 編碼代理（如 Claude、Kiro）相關的設定檔與 MCP 伺服器認證，將 AI 代理納入可信執行環境的攻擊面。

攻擊還採用持久化機制：惡意程式在專案樹中建立持久化檔案（例如 .claude/settings.json 與 .vscode/tasks.json），並設定在每次開啟專案時執行，另外還會安裝系統層級的守護進程（macOS LaunchAgent、Linux systemd），可在重啟後存活。移除被感染的套件並不會刪除這些痕跡。

跨生態的橫向擴散

在短時間內，攻擊從 npm 橫向跨入 PyPI。不同於 npm 的安裝腳本，部分 Python 套件在 import 時即會執行惡意程式碼（而非僅在安裝時），使得 npm 的一些緩解措施（如 lockfile 強制或 --ignore-scripts）無法覆蓋 Python 的載入時風險。受影響名單包含 mistralai 等 PyPI 套件。

殺鏈回顧（關鍵弱點）

• OIDC 發行權限的範圍設置過寬：許多專案在 repository 級別或整個工作流程都允許 id-token: write，使任一工作流程都可請求發行憑證。
• 過度信任 provenance：SLSA provenance 證明了建構來源，但不能保證建構行為是否經授權；攻擊者取得簽章後仍能發布惡意版本。
• 工作流程快取與 fork code 執行：pull_request_target 檢出 fork 程式碼並執行，且快取命名空間被共享，導致汙染延續到正式 release。
• 鎖檔與可選依賴的忽略：optionalDependencies 指向 github:commit 的情況常被檢測器忽視，安裝過程中可能先執行準備腳本。
• 跨語言供應鏈差異：Python import-time 執行使得對 JavaScript 的緩解手段無效。
• 錯誤的事件回應順序：立刻撤銷憑證會觸發惡意守護程式的破壞性行為，必須先隔離與取證再逐步更換。

實務檢查與緊急應變步驟

針對現場應變，研究者建議先隔離並映像可疑主機，再按序旋轉憑證（建議先旋轉 npm token、再旋轉 GitHub PAT、接著替換雲端金鑰），同時搜尋專案樹中的持久化檔案。研究人員提供了一個快速檢查範例：

find . -name 'router_init.js' -size +1M && grep -r '79ac49eedf774dd4b0cfa308722bc463cfe5885c' package-lock.json

若發現相關痕跡，應立即將主機隔離並進行取證，避免先行撤銷 token 導致惡意守護程式自毀或刪除家目錄。事後建議全面檢查並旋轉在受影響主機可存取的所有憑證。

npm config set min-release-age=7d

與現有方案的對比分析

傳統防護往往強調來源證明（provenance）與簽章，並仰仰賴 2FA 與受信任的發行流程。然而本次事件顯示，若 OIDC 或工作流程範圍過寬、快取隔離不足，攻擊仍可借由合法簽章通過管控。相較之下，行為式分析（在安裝或匯入時檢測不尋常行為）能在 provenance 無法揭露授權風險時補強防護。此外，針對 Python import-time 的監控與對 AI 代理設定的存取管控，是現有以 npm 為主的防護體系未能充分涵蓋的薄弱面。

對開發者生態與 AI 產業的影響預測

這次攻擊把 AI 編碼代理列入高價值目標，未來攻擊者很可能繼續瞄準代理設定與自動化 CI/CD 流水線。短期內，開方專案與企業可能會調整發行流程：更嚴格的 OIDC 工作流程綁定、快取隔離、以及在註冊中心層面加入行為檢測。長期來看，採購決策若僅以 provenance 作為信任門檻將被視為不足，供應鏈安全工具與 CI/CD 安全審計服務需求會顯著上升，開發者也需把 AI 代理的存取與設定視為機密資產來治理。

治理與政策建議（分期執行）

短期（今日到本週）：搜尋並隔離受感染主機，按照優先順序旋轉憑證。中期（本月）：審核所有 GitHub Actions 工作流程，將 OIDC 發行權限針對特定工作與受保護分支綁定，對快取命名空間做隔離，並針對 AI/ML 管線審查 Python 套件匯入行為。長期（季度／董事會層級）：把行為式分析納入註冊中心或採購流程，以 provenance 為必要但不充分的條件，並把 AI 編碼代理的設定檔納入企業機密治理範疇。

結語

Mini Shai‑Hulud 的一次成功，來自於把多個看似不同的弱點串接起來：快取、OIDC 範圍、provenance 的的誤解、以及跨語言的執行時差異。單靠簽章或兩步驗證無法堵住這類攻擊；系統性的 CI/CD 審計、行為式檢測與把 AI 代理視為可信執行環境的一部分，才是防禦此類進進階供應鏈攻擊的要點。

來源：TanStack postmortem、StepSecurity、Socket、Snyk、Wiz、Microsoft Threat Intelligence、Mend、Endor Labs。

延伸閱讀

• elementary-data 套件遭供應鏈攻擊：惡意 0.23.3 利用 GitHub Actions 竊取憑證
• 從 Trivy 到 Checkmarx/Bitwarden：access-broker 利用憑證散佈惡意套件的攻擊鏈分析
• Model Context Protocol (MCP) STDIO 傳輸層缺陷：逾二十萬伺服器面臨任意指令執行風險

代理人點評

Mini Shai‑Hulud 事件暴露出供應鏈防護的一個根本矛盾：我們把信任建立在可驗證的建構證明上，卻忽略了授權與範圍的細節。這次攻擊不是靠偽造簽章，而是濫用了 CI/CD 的信任邊界，並把 AI 編碼代理當作可讀寫敏感資源的目標。治理上要把發行權限最小化、隔離快取、以及在註冊中心加入行為分析，才能把 provenance 的價值變成真正的安全提升。

原始來源：VentureBeat

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