文/王珮瑤|2026-06-15發表
軟體供應鏈安全框架SLSA（Supply-chain Levels for Software Artifacts）專案於5月15日發布文章，針對Mini Shai-Hulud NPM供應鏈攻擊，說明SLSA能協助驗證什麼，以及它無法單獨解決哪些問題。開源軟體安全基金會OpenSSF也於6月10日轉載這篇由Red Hat工程師Andrew McNamara撰寫的文章，提醒開源社群，即使NPM套件附有可驗證的來源證明（provenance），也不能因此認定其建置與發布流程未曾遭到攻擊者介入或濫用。
SLSA由OpenSSF推動，透過來源證明、建置流程驗證與分級安全要求，協助開發者與企業判斷軟體成品是否來自可信流程；撰文者Andrew McNamara是Red Hat軟體供應鏈架構師與SLSA維護者。
Mini Shai-Hulud攻擊於5月11日波及TanStack專案，攻擊者利用GitHub Actions工作流程設定缺陷，結合快取污染（Cache poisoning）與OIDC權杖擷取（OIDC token extraction）手法，透過合法CI/CD管線發布惡意NPM套件。SLSA指出，攻擊最初影響@tanstack命名空間下42個套件、共84個NPM成品，後續又以蠕蟲方式擴散至@mistralai、@uipath等命名空間，波及170多個套件。
外界先前有報導將這些惡意套件描述為具有「有效SLSA Build Level 3證明」，引發SLSA是否失效的討論。SLSA澄清，相關NPM套件確實帶有密碼學層面的有效證明（attestation），但這不等於建置流程安全。攻擊者從GitHub Actions runner記憶體擷取合法OIDC權杖，透過Sigstore與NPM可信發布機制（trusted publishing）完成簽署，使這些惡意套件的來源證明（provenance attestation）仍指向正確的儲存庫、工作流程與程式碼分支，從表面驗證結果來看，與合法套件難以區分。
SLSA說明，問題不在於attestation本身造假，而是產生attestation的建置平臺已被攻擊者利用。若要解決這樣的問題，須達到SLSA建置供應鏈安全模型的第三級（SLSA Build L3），因為這當中要求建置平臺具備隔離能力，防止一個建置流程污染另一個建置使用的快取，避免建置程序接觸簽署金鑰或其他平臺敏感資訊，也不能讓一個建置持續影響後續建置環境。TanStack事件正是違反這些要求：先前工作流程污染了共享快取，發布流程暴露OIDC簽署身分，攻擊者程式碼也透過共享快取延續到後續建置。
SLSA指出，NPM目前內建的provenance能力大致對應SLSA Build L2，可將套件綁定至正規來源儲存庫與建置系統，降低冒名發布、相依性混淆等攻擊風險；但Build L2不要求多租戶CI/CD服務的建置環境彼此隔離，也不要求將簽署使用的身分憑證與建置程序隔離。這些屬於Build L3要處理的問題，因此不能把「帶有簽章的軟體成品」（signed artifact）直接解讀為「套件建置流程安全」。
SLSA也提醒，「預期建置器」（expected builder）是用來檢查套件是否由預先信任的建置器與來源儲存庫產生的驗證條件，可協助發現非標準管線產生的套件；但在TanStack事件中，惡意套件的attestation仍準確標示預期的builder、repository與workflow，因此這類檢查仍會通過。真正異常的是，發布惡意套件的工作流程最後以失敗狀態結束，卻仍完成套件發布；若企業監控這類異常狀況，可能在數分鐘內偵測到問題。
資安業者Cloudsmith在分析後續Miasma變種時也引用McNamara的SLSA文章指出，若攻擊者濫用合法開發者憑證與GitHub OIDC權杖，惡意套件仍可能夾帶有效SLSA來源證明（valid SLSA provenance），使傳統掃描機制可能將其視為一般可信更新；Cloudsmith也提醒，具備有效維護者簽章（valid maintainer signature）不應被視為安全的絕對保證。
SLSA建議，開源專案與企業驗證軟體供應鏈安全時，不應只看NPM套件是否具備有效簽章（valid signature），也要確認建置平臺是否具有SLSA Build L3要求的隔離能力。專案維護者應控管GitHub Actions的pull_request_target觸發器、落實最小權限原則、將GitHub Actions動作固定至commit SHA，並監控工作流程失敗卻仍發布套件等異常行為。
線