Mandiant 警告 CI/CD 環境成為供應鏈攻擊新目標

核心要點

Mandiant 近日指出，攻擊者已將焦點從傳統的開源套件污染，擴散至企業的 CI/CD（持續整合/持續部署）環境。只憑套件的密碼學來源證明（provenance）已不足以保證安全，企業必須同步驗證來源程式碼與建置流程。

為何 CI/CD 成為高價值目標？

CI/CD 系統往往同時擁有以下權限：

存取程式碼儲存庫（Git）
連接套件儲存庫（npm、PyPI 等）
操控雲端建置與發布資源

一旦被入侵，攻擊者可在 軟體建置與發布鏈 中插入惡意程式碼，甚至利用 GitHub Actions 快取污染、OpenID Connect（OIDC）權杖竊取、Action 標籤變更 等手法，發布仍帶有合法來源證明的受污染套件。這意味著即使成品顯示「來源可信」，其背後的程式碼與建置流程可能已被竄改。

Mandiant 建議的防護措施

| 防護項目 | 具體作法 | |----------|----------| | 獨立執行環境 | 為每一次建置配置獨立的 runner，作業結束後即銷毀容器或 VM，防止同一環境被重複利用。 | | 短效憑證 | 以 OIDC 方式在工作流程中取得短期權杖，取代長效憑證，降低憑證被盜用的風險。 | | 存取限制 | 限制 runner 只能呼叫事先核准的套件儲存庫與程式碼儲存庫 API，避免被用來存取惡意資源。 | | 固定 Action 版本 | 第三方 GitHub Actions 必須鎖定完整的 commit hash，而非可變的標籤名稱，以防攻擊者替換程式碼。 | | 成品驗證 | 部署前檢查容器的密碼學簽章、執行權限與來源；阻擋缺乏有效簽章、要求不必要 root 權限或來自未受信任公開儲存庫的映像檔。 | | SBOM 署名 | 在建置時產生 SBOM（軟體物料清單），並以數位簽章綁定對應的成品摘要（digest），確保清單不被竄改且能追溯每個元件來源。 |

未來展望與讀者啟示

供應鏈攻擊的演變顯示，單一的來源證明已無法滿足安全需求。企業應將 程式碼、建置流程、執行環境 三者視為不可分割的安全鏈條，導入最小權限、短效憑證與可驗證的 SBOM，才能在攻擊者試圖滲透 CI/CD 時，保持可見性與阻斷能力。

對於開發團隊而言，除了落實上述技術防護，更需培養 安全開發文化：定期審查 Action 依賴、檢測 OIDC 權杖使用情形、並將安全測試納入 CI/CD 流程的每一個階段。唯有如此，才能在供應鏈威脅日益升級的環境中，維持軟體交付的完整性與信任度。