在 AI、自动化开发和开源生态高度繁荣的今天，一次 npm 包更新，就足以把攻击者请进你的 CI/CD 和云账号。

最新曝光的 Sha1‑Hulud供应链攻击，再次把整个行业敲醒：

它不再满足于“顺手偷点凭证”，而是进化出了——

• 可以长期潜伏在开发机和 CI/CD 的 持久化后门

• 覆盖 AWS / GCP / Azure 的 多云凭证批量窃取

• 针对 Azure DevOps 的 特权提升与网络控制绕过

• 在偷不到东西时直接安全擦除整个用户目录的毁灭性“自毁”机制

這不是一場普通的安全事件，而是一場針對開發者與軟件供應鏈的全面戰爭。

在這樣的威脅面前，企業需要的已經不只是「看得見風險」，而是：

在攻擊發生前，就把惡意依賴擋在門外；在攻擊發生時，能在幾分鐘內回答——“我們到底有沒有中招？”

Mend 作為 AI 原生應用安全平台（AI‑Native AppSec），正是在這樣的背景下，為客戶提供三大關鍵價值。

---

三大核心價值：Mend 如何把一次供應鏈「零日夢魘」變成可控風險

核心價值一：把惡意包擋在門外——供應鏈攻擊的「預防性隔離」

Sha1‑Hulud 的可怕之處在於，它利用 npm 生態的正常更新節奏，自動修改並重新發佈合法包的微版本，在大量企業毫無察覺的情況下滲透進構建流程。

對大多數團隊來說，風險鏈條是這樣的：

1. Renovate / 自建 Bot / 手動更新拉取了「最新版本」

2. CI/CD 自動構建，把被植入後門的依賴打進鏡像或制品

3. 惡意 preinstall 腳本執行，開始安裝自託管 GitHub Actions runner、掃描雲憑證、三重編碼上傳敏感數據

4. 直到 GitHub 或社區披露，大多數團隊才發現：風險早已進入內網

Mend 在這裡帶來的第一個價值，是用策略而不是僥幸來對抗這類攻擊：

• 利用 Mend Renovate 與包管理器的 「最小發佈時間（minimum release age）」策略， 將所有新發佈或剛剛升級的版本，自動延後一段時間再允許進入生產構建。

• 在這個「冷卻期」內，一旦像 Sha1‑Hulud 這樣的惡意版本被社區或 Mend 威脅情報識別， Mend 會在你真正下載之前就把它標記為風險並阻斷升級路徑。

結果是什麼？

對沒有防護的團隊而言，每一次 npm update 都可能是一次賭博；

而對使用 Mend 的團隊來說，更新節奏仍然敏捷，但風險已被策略化地推遲和過濾。

---

核心價值二：一鍵回答「我們有沒有用到這些包？」——全棧可視化與精準排查

在供應鏈攻擊爆發後，安全團隊最害怕的不是技術細節，而是這一句：

「我們到底有沒有用到這批受影響的包？在哪些系統裡？影響到哪些業務線？」

Sha1‑Hulud 這次波及了 數百個 npm 包、跨多個頭部組織和生態，僅憑 Excel 和臨時腳本，

想要在短時間內盤點清楚，幾乎是不可能完成的任務。

Mend 提供的第二個關鍵價值，是基於 SBOM（軟件物料清單）與威脅情報的 全棧可視化能力：

• 平台可根據最新的攻擊情況與 MSC（Mend Security Center） 參考表， 自動標記所有受 Sha1‑Hulud 影響的版本與包名。

• 安全團隊可以在一個界面內，立刻看到： 「哪些應用、哪些服務、哪個版本、在哪個環境（開發 / 測試 / 生產）正在使用受影響依賴」。

• 不再需要手動 grep、問各個團隊拉清單，從天級響應縮短到分鐘級決策。

這種「一鍵回答關鍵問題」的能力，在真正的供應鏈事故中，決定的是：

• 你是在給 CEO 匯報「我們大概沒問題」， 還是能給出「我們精準識別到 3 個受影響服務，已完成封鎖與修復」的可核查結果。

---

核心價值三：從「事件應急」走向「策略化、持續性的供應鏈防禦」

Sha1‑Hulud 之所以被定義為一次質變，而不只是「又一個惡意 npm 包」，就在於它的攻擊鏈路完整且高度自動化：

• 先偵測是否處於 CI / CD / Azure DevOps 等高價值環境

• 再通過自託管 GitHub Actions runner 取得持久後門

• 隨後橫向移動、多雲憑證枚舉、三重編碼外帶敏感數據

• 最後在失敗時觸發「安全擦除」防取證

這類攻擊不是靠一次臨時掃描就能解決的，而是需要 把安全規則變成持續運行的“守門員”。

Mend 在這一點上為客戶提供的是第三個價值：

• 將供應鏈安全策略（如「最小發佈時間」「高風險作者封鎖」「關鍵組件必須有人審核」） 以 策略即代碼（Policy‑as‑Code） 的形式持續執行在 CI/CD pipeline 中。

• 結合 Mend 的威脅情報與 MSC 更新，在未來類似事件爆發時，自動更新風險規則， 而不是每次都重新「拉戰時群、手工發通知」。

• 讓安全團隊從疲於奔命的 “一次性救火”，轉變為可以持續優化的 “策略設計者”。

最終，企業得到的不僅僅是「躲過這次 Sha1‑Hulud」，

而是一套可以面對下一個未知供應鏈攻擊的長期防禦框架。

---

客戶案例：一家 SaaS 頭部企業如何在 Sha1‑Hulud 事件中「零中斷躲過一劫」

以下案例根據 Mend 觀察到的實際客戶部署情況進行整理，出於保密要求隱去公司名稱與具體指標，但技術路徑與事件經過均來自真實場景。

情境

這是一家為全球客戶提供線上服務的 SaaS 頭部企業，核心產品高度依賴：

• 大量 npm 開源庫

• 自動化依賴升級（內部與 Renovate 類工具）

• 高頻率部署的 CI/CD 流程

在過去幾年中，他們已多次因為：

• 依賴被惡意刪除或下線

• 依賴突然引入破壞性變更

• 供應鏈漏洞（如 Log4Shell 類事件）

而被迫緊急回滾、開「全公司戰情會」，對供應鏈風險極度敏感。

任務

在不犧牲發布節奏與開發效率的前提下，他們希望達到兩個目標：

1. 任何供應鏈事件發生時，都可以在 30 分鐘內回答：我們是否受影響？

2. 最大限度降低把惡意或有問題版本拉進生產的概率。

行動

在引入 Mend 之後，該企業與 Mend 團隊一起完成了三件關鍵的事：

1. 接入 MSC 與 SBOM 全棧可視化

   1. 對所有核心服務生成並持續更新 SBOM，

   2. 與 Mend Security Center 的供應鏈威脅情報對接，

   3. 形成「一鍵查詢：某個包 / 某個版本在哪些服務被使用」的能力。

2. 在 Renovate 中啟用「最小發佈時間」+ 風險標記規則

   1. 對高風險生態（如 npm）統一設置版本冷卻期，

   2. 所有新版本必須「經過一段時間的社區觀察 + 情報校驗」後，才會自動進入升級候選列表。

3. 將關鍵策略寫入 CI/CD Pipeline

   1. 對標記為高風險來源、存在可疑行為的包直接在 pipeline 中阻斷，

   2. 高敏感服務的依賴升級必須經過安全與架構團隊的聯合審核。

結果

當 Sha1‑Hulud「二次來襲」時，這家企業的實際經歷是：

• 從社區與 Mend 情報渠道獲悉事件後， 安全團隊登錄 Mend 控制台，在幾分鐘內確認：生產環境沒有使用任何受影響版本。

• 部分開發環境曾經將某些受影響包列入升級候選，但因為 「最小發佈時間」策略尚未到期， 這些惡意版本從未真正進入構建產物。

• 安全團隊的工作重心，不再是疲於奔命地排查影響範圍，而是：

  • 更新內部風險通告

  • 進一步調整策略，將相關維護者與包加入更嚴格的審查列表

整個過程中，沒有任何業務中斷、沒有生產回滾、也沒有深夜緊急「拉通各團隊開會」的戰時場景。

這就是供應鏈安全從「靠運氣」到「靠體系」之間的本質差異。

---

結語：在下一個 Sha1‑Hulud 之前，把防線築好

Sha1‑Hulud「第二次來臨」向整個行業釋放了幾個殘酷現實：

• 攻擊者已經非常熟悉我們的開發與 CI/CD 生態， 他們知道 GitHub Actions、Azure DevOps、npm 的每一個細節。

• 單靠「代碼掃描」與「事後補救」已經遠遠不夠， 真正決定損失大小的是：你能否在惡意版本進入系統之前，就讓它止步門外。

Mend 給企業帶來的，不只是一組工具，而是一套面向未來供應鏈攻擊的長期策略：

• 預防性隔離：用策略和自動化流程替代人肉判斷，降低惡意依賴進入生產的概率

• 精準可視化：在任何一場供應鏈事件中，都能在幾分鐘內回答「我們是否受影響」

• 策略化防禦：把一次次事故中的教訓，沉澱為可以長期運行的安全策略與規則