快速回答： 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 个代码仓库。这是一个查看依赖关系树中现有内容的理想场所。
