軟體供應鏈攻擊出現新動向。資安團隊Mandiant近期觀察發現，攻擊者不再只污染開源套件，已把目標擴大到企業的CI/CD建置流程，連開發人員工作站與安全掃描工具都成為下手對象。
Mandiant指出，攻擊者鎖定的目標包括企業信任的安全掃描工具、公用函式庫，以及AI程式開發工具。由於CI/CD環境通常擁有存取程式碼儲存庫、套件儲存庫和雲端環境的權限，一旦遭到入侵，攻擊者可能進一步介入軟體的建置與發布流程。
攻擊者已採取多種手法操弄建置流程，包括污染GitHub Actions快取、擷取OpenID Connect權杖，以及操弄可變更的Action標籤。更值得注意的是，攻擊者甚至可能發布仍帶有合法密碼學來源證明的污染套件，讓成品看起來一切正常。
這意味著即使軟體成品具有來源證明，企業仍需確認成品對應的來源程式碼版本及建置流程是否可信。單靠來源證明，已不足以保證軟體供應鏈的安全。
針對建置環境的防護，Mandiant建議企業為每項建置工作配置獨立的runner，並在工作完成後立即銷毀執行環境。如此一來，即使單一建置環境遭到入侵，也不會波及其他建置工作。
在憑證管理上，企業應減少使用長效憑證，改由CI/CD工作流程透過OIDC取得短效權杖。同時限制runner只能連線至事先核准的套件儲存庫及程式碼儲存庫API，降低runner遭控制後的影響範圍。
第三方GitHub Actions的使用方式也需要調整。Mandiant建議將其固定至完整的commit hash，避免攻擊者在標籤名稱不變的情況下，偷偷替換實際使用的程式碼。
即使建置流程已遭污染，企業仍可在軟體進入正式環境前阻擋有問題的成品。做法包括檢查容器的密碼學簽章、執行權限及來源，例如阻擋缺乏有效簽章、要求非必要root權限，或來自不受信任公開容器儲存庫的成品。
企業也可在建置時產生軟體物料清單（SBOM）並加上數位簽章，再將SBOM與對應軟體成品的摘要值綁定。這樣既能避免SBOM遭到竄改，也能確認特定軟體成品究竟包含哪些元件。
回顧近年資安事件，軟體供應鏈攻擊屢屢登上新聞版面，過去多半聚焦在遭污染的開源套件。這次Mandiant的觀察顯示，攻擊面已進一步擴大到開發流程本身，防護思維必須跟著升級。
隨著企業加速導入DevOps與AI開發工具，建置流程的權限與複雜度同步提高，成為攻擊者眼中的高價值目標。企業若只顧成品掃描而忽略建置環境安全，防線將出現明顯缺口。
Mandiant建議企業重新盤點CI/CD環境的權限配置與憑證管理，並把建置流程納入資安監控範圍，才能因應這波鎖定開發流程的攻擊手法。
