協作與軟體開發工具供應商 Atlassian 的產品安全經理 Deepam Kanjani，日前在資安專業認證組織 ISC2 於美國丹佛舉行的 ISC2 Security Congress 2026 議程中，分享一起改編自真實事件的「
Shai-Hulud」蠕蟲供應鏈攻擊。事件中，資安團隊查詢軟體物料清單（Software Bill of Materials，SBOM）時，結果顯示環境乾淨，但這份 SBOM 其實已落後兩個開發衝刺（sprint），團隊當時並未察覺。Kanjani 指出，企業應以正式環境實際執行的內容，作為事件應變的依據。
看似合法的套件，第三層深處藏有惡意相依套件
Kanjani 說明，為保護機密，他已調整所有可識別的細節、數據與事件順序；不過，攻擊手法與應變挑戰都取自某個大型軟體即服務（SaaS）環境的真實事件。
涉事套件的雜湊值（hash）相符，GitHub 上累積超過 3400 顆星，儲存庫看似可信，公司資安工具也未起疑。然而，套件內部第三層深處藏有一個名為 shai-hulud 的惡意間接相依套件（transitive dependency）；由於它不是直接相依套件，頂層的相依套件稽核（dependency audit）不會列出。
最早的線索來自行為掃描工具：它標示該套件執行了不該執行的動作。由於雜湊值相符，也沒有其他明顯跡象，應變人員起初研判這是誤報。團隊隨後查詢 SBOM，結果同樣顯示環境乾淨。
缺乏執行期遙測，只能人工比對超過 400 個服務的日誌
調查展開後，團隊遲遲無法確定哪些服務用到該套件。入侵指標（IOC）僅能提供初步線索，難以確認受影響的服務與擴散範圍；要判斷哪些程式碼實際被執行過、又能存取哪些資源，仍得靠執行期（runtime）證據。
由於缺乏執行期遙測（telemetry），團隊只能人工比對超過 400 個服務的日誌，影響範圍始終無法釐清。雪上加霜的是，事件應變負責人最初發給企業利害關係人的 Slack 訊息過於籠統，引發多組人馬同時展開調查，讓局面更加混亂。
追查攻擊者身分的努力同樣走入死胡同。團隊檢視了登錄庫（registry）擁有者、npm 維護者紀錄、發布者身分與 GitHub 紀錄，卻發現該儲存庫是從合法專案複製而來，發布者的身分與帳號歷史也像是捏造的。報導指出，研究人員後來將部分後續的 Shai-Hulud 攻擊，歸因於追蹤代號 TeamPCP 的威脅行動者。
以正式環境實際執行的內容為依據
Kanjani 認為，
企業不能只看 SBOM 與相依套件清單，事件應變應以正式環境實際執行的內容為核心，讓資安團隊能辨識問題、界定範圍、排定優先順序並圍堵事件，同時即時掌握受影響的服務與可能的衝擊範圍。他說：「你要處理的是執行期圖譜，不是相依套件檔案，工具必須反映這一點。」
資安團隊可參考的防護建議
Kanjani 強調，下列數字是各組織應依自身環境校準的目標，並非通用基準：
- 已部署的 SBOM 應維持在 72 小時內，且超過 98% 的正式環境服務須符合此標準
- 啟用執行期偵測能力，於 90 秒內發現未知模組載入
- 每日檢查登錄庫，於套件發布後 24 小時內找出與內部套件名稱相似的仿冒套件
- 偵測重點應放在蠕蟲運作時非做不可的事，而非攻擊者身分：身分訊號會輪替，運作需求卻不會
- 事件溝通應直接明確，以對方能理解的語言誠實說明，避免製造恐慌
本文轉載自 DarkReading。