npm依赖还敢随便装吗？最近那波供应链攻击，连开源大佬都翻车了

事情是这样的

上周四的凌晨，npm生态又出大事了。

安全公司StepSecurity和SafeDep接连发出警报——有人在npm上搞了一场大规模的供应链攻击，时间大概在5月19号左右。攻击者黑进了好几个热门开源项目维护者的账号，然后在大概20分钟的时间里，往一堆流行包里塞了恶意代码。

说实话，看到这个消息的时候我第一反应不是震惊，而是"又来了"。

这已经是今年第几次了？GitHub被黑过，PyPI被搞过，现在轮到npm。搞开源的朋友应该都懂那种感觉——你小心翼翼地从社区拉了个包，结果它背后可能藏着个定时炸弹。

跟以前那些小打小闹不一样，这次攻击者选择的入侵方式相当高明。不是暴力破解，也不是0day漏洞，而是瞄准了维护者账号的安全盲区——那些没有开双因素认证的老账户。

调查显示，至少有十几个包的维护者账号被入侵，攻击者在这些包里植入了窃取环境变量和敏感信息的后门代码。一旦你装了被污染的包，服务器上的密钥、数据库密码、云服务的AccessKey这些东西，就相当于白送给人家了。

更坑的是，攻击者还留了个心眼。他们把恶意代码藏在了构建流程里，而不是直接写在源码里。这意味着即使你review了源码也未必能发现问题，因为你看到的是"干净"的，但npm publish上去的包却是"脏"的。

这种手法在业内叫"依赖混淆攻击"的进阶版，防不胜防。

根据StepSecurity的统计，受影响的包周下载量加起来超过500万次。也就是说，你公司的Node.js项目里，可能早就中招了。

我以前在上一家公司也踩过类似的坑。有一次CI/CD突然报了个奇怪的错误，排查了两天才发现是一个三个月前装的npm包发了个更新版本，自动更新直接把测试环境搞挂了。那次之后我就学乖了——package-lock.json必须锁定，而且每次发包之前都要用npm audit扫一遍。

但说真的，npm audit能扫出来的只是已知漏洞。像这种供应链攻击，它不在CVE列表里，audit也发现不了。

聊点实际的。经过这次事件，我觉得这几个习惯真的得养成：

第一，能锁版本就锁版本。package.json里别写"^1.0.0"这种宽松版本号，改成精确的"1.0.0"。npm ci比npm install更靠谱，它会严格遵守lock文件。

第二，装新包之前查查它的底细。看看GitHub星数、维护频率、最近一次提交时间。一个一万星的包突然很久没更新了，那得警惕。

第三，开双因素认证。这次攻击能得手，很大原因就是维护者没开2FA。如果你有开源项目并且是小团队在维护，这点特别重要。

第四，可以用一些工具做运行时监控。比如Socket.dev这类工具能在你装包之前就分析它有没有可疑行为。虽然不是百分百保险，但多一层防护总比裸奔强。

开源这么多年发展下来，依赖第三方包已经成了行业习惯。你不可能什么轮子都自己造，但也不可能完全信任所有人。这个矛盾本质上是无解的。

我自己的做法是：核心业务逻辑尽量少依赖外部包，工具类的随便装。不同的场景，不同的安全等级。

这次npm攻击事件应该还没完，安全公司还在进一步调查。建议各位这两天先别急着更新npm包，等风波过去再说。