20分钟、317个 npm 包：开源供应链的风险账不能再外包

一个开发者账号被接管。约 20 分钟，317 个 npm 包，630 多个恶意版本。

这组数字比“又有开源包出事”更刺眼。攻击者没有逐个项目慢慢找洞，而是拿到发布权限后，直接沿供应链向下游扩散。很多团队的构建流程还没反应过来，恶意版本已经可能进入依赖链。

这轮攻击属于 Mini Shai-Hulud 行动的一部分。名字像科幻梗，打法很现实：攻账号，改包，偷凭据，再继续横向传播。问题不在某几个包倒霉，而在现代软件工业把太多信任压在少数账号、自动发布链和默认安装习惯上。

发生了什么：账号被拿下，发布链被借道

安全公司 SafeDep 称，攻击者接管了一个开发者账号，并在约 20 分钟内向 317 个 npm 包发布了 630 多个恶意版本。

这些恶意版本的目标包括窃取多类服务凭据，其中包括密码管理器相关凭据。拿到凭据后，攻击者可以进一步窃取数据，也可以继续传播恶意软件。

受影响包包括阿里巴巴 AntV 相关库。这里要说清楚：这不等于阿里云或阿里整体基础设施被攻破。它说明的是，流行前端可视化生态也可能成为下游项目的入口。

JFrog Security 还提到，部分恶意更新发布在 GitHub 上。风险不只停在 npm registry。它会顺着开发者日常工作流移动：代码托管、包管理、自动构建，哪里默认信任，哪里就可能被借道。

这也不是孤例。此前 Mini Shai-Hulud 的另一波攻击中，TanStack 被攻破，并波及 OpenAI 两名员工电脑。现有材料只能说明员工电脑受影响、OpenAI 是受害者之一；不能据此推断 OpenAI 核心系统或用户数据被攻破。

谁最受影响：开发者和企业安全负责人先动手

这件事最该盯的不是普通用户，而是两类人。

开发者和开源维护者要先检查自己是否使用了相关 npm 包、是否拉取过异常版本、是否有凭据暴露风险。尤其是本地开发环境里存过 token、云服务密钥、密码管理器访问凭据的人，不能只删包了事。该轮换的凭据要轮换，该撤销的 token 要撤销。

企业安全和工程管理者更麻烦。你们要看的是 CI/CD 有没有在事发时间窗口拉取过这些版本，构建日志里有没有异常网络请求，发布令牌是否长期有效，依赖是否锁版本。

受影响对象不是“所有 npm 生态”。现在能确定的是相关包、相关版本、相关链路存在风险。这个边界很重要。夸大范围会制造噪音，缩小问题又会放过真正的入口。

我更建议企业把这次当成一次依赖账本核对。不是所有团队都要立刻停工，但至少要知道：哪些项目用了相关包，哪些构建拉过新版本，哪些凭据暴露在开发机和 CI 环境里。

如果这些问题答不上来，风险就不在外部黑客手里，而在自己的资产表里。

真问题：开源免费，信任不免费

把锅甩给“开源不安全”很轻松，也很懒。

现代软件本来就不可能从零写起。一个普通 Web 项目依赖几十、几百个包，并不稀奇。一个包再依赖另一个包，维护者可能是公司团队，也可能是一个晚上抽空修 bug 的个人。

真正脆弱的是信任链太长，责任链太散。

企业享受开源带来的速度，却常常把安全当成社区附赠服务。依赖自动更新，CI/CD 自动拉包，发布账号靠个人维护，凭据散落在开发环境里。平时这叫效率。出事时，这叫攻击面。

“天下熙熙，皆为利来。”这句话放在这里，不只是说攻击者逐利，也是在说企业自己的激励。工程团队被要求更快上线、更少阻塞、更少流程摩擦，安全审计就会被排到后面。攻击者看见的，正是这套激励留下的缝。

开源供应链攻击厉害的地方，不在技术多玄。它利用的是工程组织最熟悉的动作：安装、构建、发布、同步。动作越自动，越要问一句：自动化到底在信谁？

铁路时代有轨距、信号、调度。云和开源时代，也要有账号、签名、审计、回滚。历史不完全一样，但结构很像：基础设施越集中，单点信任越值钱，也越危险。

接下来最该观察三件事。

一是相关恶意版本是否被完全下架，企业镜像和缓存里是否还有残留。很多风险不是来自公开仓库，而是来自内部缓存。

二是被盗凭据有没有继续引发二次传播。供应链攻击最怕的不是第一跳，而是凭据带来的第二跳、第三跳。

三是企业会不会把依赖安全放进正式成本表。没有预算、没有负责人、没有流程，最后就只能靠维护者的好运气。

这次攻击者测试的不是某个包，而是整个软件工业的默认信任。测试结果不好看。

开头那 20 分钟，像一次压力测试。它测出来的不是某个维护者疏忽，而是很多企业还在用“社区会兜底”的心态跑生产系统。

依赖不是小事。依赖就是供应链，供应链就是业务连续性。