根據 GitGuardian 的研究發現，名為 Shai-Hulud 的資訊竊取蠕蟲（Infostealer Worm）近期發生了顯著演進。這類惡意軟體專門在受感染的環境中搜尋憑證，以便將單次入侵擴展為更大規模的供應鏈攻擊。最令人擔憂的是，該蠕蟲掃描憑證的路徑已從早期的 189 個位置，大幅增加至 469 個位置，涵蓋範圍包括開發者環境、持續整合與持續部署（CI/CD）工具、雲端配置，甚至延伸至 AI 開發工具的設定檔。
這種掃描範圍的擴張揭示了一個關鍵的攻擊趨勢：攻擊者不再試圖攻破複雜的信任關係，而是直接尋找維持這些信任關係的憑證（Credentials）。在現代軟體供應鏈中，開發者信任套件倉庫，組織信任維護者，而 CI/CD 系統則依賴被賦予的身分憑證來運作。當攻擊者能直接獲取這些憑證時，他們便擁有了所謂的「可重複使用權限」（Reusable Authority），能輕而易舉地在不同系統間橫向移動。
憑證如何成為供應鏈攻擊的連動機制
Shai-Hulud 這類蠕蟲將竊取的憑證視為跳板。例如，在開發者工作站上發現的一個 Token（一種用於身分驗證的權杖）可能讓攻擊者進入原始碼庫；而原始碼中可能隱藏著雲端憑證，進而讓攻擊者掌控基礎設施。更危險的是，如果竊得的是套件發佈憑證（Package Publishing Credentials），攻擊者就能以受信任的通道發佈惡意軟體，使攻擊在整個生態系中自動傳播。
現代開發環境中的憑證分佈極其碎片化。除了常見的 .env 環境變數檔案或 Shell 歷史紀錄外，憑證還可能藏在命令列介面（CLI）快取、IDE 設定，以及新興的 AI 輔助開發工具配置中。攻擊者採取的是「先收集、後分類」的策略，他們並不預先知道哪個憑證最重要，而是盡可能擴大搜索半徑，將所有可用的權限悉數奪走。
從憑證偵測轉向憑證風險管理
面對這種威脅，傳統將安全劃分為原始碼安全、雲端安全或端點安全的管理模式已不足夠。因為憑證橫跨了所有部門：一名開發者在一天內可能會同時使用 GitHub、npm、AWS 與 Kubernetes 的憑證。這意味著在筆記型電腦上發現的一個秘密檔案，其影響範圍可能是整個生產環境的雲端資源。
因此，企業必須將「秘密偵測」（Secrets Detection）提升為「憑證風險管理」（Credential Risk Management）。單純列出 10 萬個洩漏的憑證並無意義，因為並非每個憑證的風險都相同。有效的修復策略應根據攻擊者的優先順序來排序，將風險分為三個等級：
首先是最高優先級的套件發佈憑證。這是停止蠕蟲傳播的核心，因為它直接影響軟體分發。企業應盡量消除長效的發佈 Token，轉而採用基於 OpenID Connect (OIDC) 的短效、經過驗證的身分驗證機制，例如 Docker 與 GitHub Actions 近期推動的信任發佈（Trusted Publishing）方案。
其次是生產環境的關鍵憑證。這包括存取生產雲端帳號、客戶資料庫、簽署基礎設施（Signing Infrastructure）以及 Kubernetes 叢集等權限。這類憑證的修復重點在於評估「爆炸半徑」（Blast Radius），即一旦被盜用會造成多大的實質損害。
最後才是其他低風險的洩漏憑證。在處理這類憑證時，應優先考量憑證是否仍然有效（Validity），以及它所對接的是開發、測試還是生產環境。
建立可重複的憑證防禦週期
對抗 Shai-Hulud 等蠕蟲的關鍵不在於記憶所有可能的掃描路徑，因為攻擊者會不斷增加新路徑，而在於消除「靜態且長效」的權限。企業需要建立一套可重複的循環流程：
第一步是全面可視化。建立一個包含原始碼、Git 歷史、CI/CD 系統及開發環境的單一憑證清單，找出所有存在於金庫（Vault）之外的明文憑證。
第二步是精準修復。依照前述的優先級（發佈權限 > 生產權限 > 其他），利用身分、權限與環境等上下文資訊，有計畫地撤銷或輪換（Rotate）憑證。
第三步是預防重建。透過阻擋新硬編碼憑證的提交、推動短效憑證化，防止攻擊路徑再次形成。
總結來說，憑證層應被視為一個獨立的安全問題。當我們能將「可重複使用的權限」從環境中移除，即便新一代的蠕蟲再次來襲，它們也將發現沒有可供利用的鑰匙。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。