快速回答： Npm 供應鏈攻擊是透過入侵受信任的維護者帳戶或 CI/CD 攻擊者利用令牌發布開發者已信任的惡意軟體包版本，並利用該軟體包的安裝腳本或蠕蟲邏輯完成後續操作。在 2025 年 8 月至 2026 年年中期間，這種模式引發了 npm 註冊表歷史上規模最大的軟體包供應鏈攻擊浪潮，其中包括 chalk/debug 劫持事件。 沙伊-胡魯德蟲以及隱藏在每週下載量高達 100 億次的軟體包中的國家級惡意軟體。解決之道並非在惡意軟體安裝後進行掃描，而是在惡意軟體安裝前將其擷取並監控。 pipeline 這些攻擊行為的共同點非常明顯。
每一次安裝都是一種信任行為，攻擊者深知這一點。
開發人員運行 npm安裝這條命令背後隱藏著一個龐大的依賴關係樹，其中包含成百上千個軟體包，其中大部分是由開發者永遠不會遇到的人編寫和維護的。沒有人會逐行審查這個依賴關係樹。也沒人有時間這麼做。
這種信任正是攻擊者的目標。對於攻擊者來說，攻擊一位每週下載量高達 2.6 億次的 npm 維護者比在財富 500 強企業的防火牆中找到零日漏洞便宜得多。 npm 供應鏈攻擊正是利用了這種不對稱性，而 2025-2026 年的攻擊浪潮表明，這種攻擊的規模已經擴大到何種程度： 從孤立的拼字錯誤到自我繁殖的蠕蟲 它們發布惡意軟體的速度比任何人的反應都快。
什麼才算是 npm 供應鏈攻擊
npm 供應鏈攻擊是指攻擊者將惡意程式碼插入 npm 發行版中的任何事件。 pipeline 惡意軟體不會直接侵入目標本身的程式碼庫，而是偽裝成例行依賴項更新。其入口點通常是以下三種情況之一：維護者的憑證被盜、發布權限被盜或 CI/CD 令牌，或被攻破的版本 pipeline 它被誘騙代表攻擊者發佈內容。由於 npm 套件會自動引入傳遞依賴項，因此一個被攻破的套件可以影響那些從未將其聲明為直接依賴項的應用程式。
時間軸：2025-2026 年 npm 供應鏈最大攻擊事件
每次 npm 包供應鏈攻擊背後的模式
拋開具體細節，上述幾乎所有事件都遵循相同的四個步驟：
- 損害的是個人身份，而不是系統。 被釣魚攻擊的維護者、洩漏的 npm 令牌、被盜的 GitHub PAT 或從其他來源取得的 OIDC 令牌 CI/CD 運行內存。攻擊者不會破壞註冊表，而是藉用他人的註冊表金鑰。
- 使用開發者已經信任的名稱發布。 當真正的軟體包名稱有效時，無需進行網域搶注。這正是這些攻擊對自動更新如此有效的原因。 pipelines：這次更新看起來完全合法。
- 趁別人還沒評論就趕快跑吧。 惡意安裝腳本、混淆的有效載荷或僅在特定條件下啟動的潛伏程式碼會在此時執行。 npm安裝 它通常會在開發人員的筆記型電腦上運行，遠早於計劃的安全掃描發現它。
- 持續存在，並且不斷傳播。 Shai-Hulud 及其後代利用竊取的憑證自動發布下一個被污染的軟體包，將一次入侵變成依賴關係圖中的連鎖反應。
為什麼常見的防禦措施會失效？
大多數應用安全工具的設計初衷是分析程式碼庫中已有的內容：已知的 CVE、靜態程式碼模式、授權問題等等。這固然必要，但對於這類攻擊來說，其作用機轉卻為時已晚。當掃描器發現依賴項時，安裝腳本可能已經在開發人員的機器上執行完畢。傳統的防毒軟體和 EDR 監控的是作業系統，而不是軟體包註冊表，因此它們無法將「新的 npm 版本」視為風險單元。正如 TanStack 和 Red Hat 事件所表明的那樣，即使是建立完整性證明也無法有效應對此類攻擊。 SLSA provenance 即使攻擊者合法地獲取了簽名者的身份，也無濟於事：簽名是有效的，但包裹仍然是惡意的。
這些 npm 供應鏈攻擊利用的漏洞具體存在於發布和安裝時，也就是在惡意軟體的特徵碼出現之前，以及軟體包在任何傳統掃描器會檢查的地方運行之前。
如何阻止下一次 npm 供應鏈攻擊
其中一些是每個工程團隊今天都可以採用的流程規格：
- 引腳依賴關係和 commit 鎖文件這樣一來，自動更新就不會悄悄地引入剛發布的惡意版本。
- 停用或沙盒隔離安裝後腳本。 預設情況下；大多數軟體包在安裝時不需要執行任意程式碼。
- 對 npm 發布帳戶強制執行硬體支援的 MFA封鎖了導致 chalk、debug 和 Qix 的帳戶被盜用的確切網路釣魚路徑。
- 範圍和旋轉 CI/CD 代幣積極並將運行器記憶體中的 OIDC 令牌視為值得保護的憑證，而不是實作細節。
- 注意解鎖-注入-重新鎖定模式 in CI/CD分支保護規則已停用 commit 推播操作、規則重新啟用，所有操作都在很短的時間內完成。這是一個反覆出現的特徵。 pipeline供應鏈層面的妥協。
流程紀律失效的地方
流程規範可以降低風險。它無法在惡意軟體發布的第一時間將其攔截，也無法攔截那些傳播速度遠超人工處理能力的蠕蟲病毒。而這正是 Xygeni 供應鏈安全解決方案的用武之地。
Xygeni 的 MEW（惡意軟體早期預警） 持續分析發佈到 npm、PyPI 和 Maven 的新軟體包，在惡意軟體特徵碼出現之前而非之後將其捕獲，並將已確認的威脅反饋給系統。 Xygeni 的 自帶檢測引擎。 依賴防火牆 即時掃描 npm、PyPI、Maven、NuGet 和 RubyGems，並在惡意安裝到達開發人員的機器或建置之前將其封鎖。 CI/CD 異常檢測 手錶 pipeline針對 TanStack 入侵等事件背後的行為模式，包括解鎖-注入-重新鎖定序列，以及完整的審計跟踪，Xygeni 能夠提供精準的分析。 人工智慧驅動的分類和補救 這也適用於第三方掃描器的結果，團隊不必為了彌補這一差距而放棄現有工具。
常見問題：npm 供應鏈攻擊
什麼是 npm 供應鏈攻擊？
這是一種惡意程式碼透過受信任的 npm 依賴項而非目標應用程式本身程式碼進入目標應用程式的攻擊，通常是因為攻擊者攻破了維護者的帳戶、發布令牌或… CI/CD pipeline的身份。
npm 供應鏈遭受的最大規模攻擊是什麼？
從影響範圍來看，2025 年 9 月的 chalk/debug 劫持事件規模最大：18 個軟體包，每週總下載量達 2.6 億次，均透過一個被釣魚攻擊的維護者帳戶遭到入侵。而從技術創新性來看，Shai-Hulud 是一個更重要的轉捩點，它是 npm 史上第一個能夠自我傳播的蠕蟲病毒。
npm 包供應鏈攻擊通常是如何開始的？
幾乎總是與身分盜竊有關：維護者被釣魚攻擊、發布令牌洩露或被盜用。 CI/CD 憑證（例如從運行器記憶體中提取的 OIDC 令牌）而不是對 npm 本身進行技術性入侵。
防毒軟體或 EDR 能否阻止 npm 供應鏈攻擊？
並非總是可靠。 EDR 監控作業系統，但無法理解軟體包註冊表；而防毒軟體基於特徵碼，無法抵禦在特徵碼出現之前發布的惡意軟體。要阻止此類攻擊，需要在惡意軟體發布和安裝的源頭進行監控，而不僅僅是在終端端。
是否 SLSA provenance 或建立證明機制來防止這種情況發生？
它證明了 pipeline 建置過程中，軟體包本身並未被竄改。但這並不能證明觸發建置的身份沒有洩露，因為 TanStack 和 Red Hat 事件都表明，惡意軟體包上都附加了有效的身份驗證資訊。
團隊如何在惡意 npm 套件安裝之前檢測到它？
透過對新發布的軟體包進行持續的、預簽名惡意軟體分析（這正是惡意軟體預警系統和依賴防火牆的設計目的），而不是僅依賴對儲存庫中已有的程式碼進行事後漏洞掃描。
從哪兒開始
npm 供應鏈攻擊並未放緩，而且自 Shai-Hulud 事件以來，趨勢顯示自動化程度正在提高，而不是降低。那些不再將每次 npm 安裝視為例行事件，而是開始監控註冊表的團隊，最有可能在下一次攻擊中佔據有利地位。 pipeline並將端點視為一個連結的攻擊面。
Xygeni 的開發者計畫包含 MEW 和依賴防火牆覆蓋範圍 最多可免費存取 25 個代碼倉庫。這是一個查看依賴關係樹中現有內容的理想場所。
