你的代码里，藏着黑客埋的"毒"：1300个 npm 包遭供应链投毒

ChainDrop 恶意软件感染超 1300 个 npm 包，月下载量达 20 亿次，窃取开发者 npm/GitHub/云凭证并自我传播。同期 Open VSX 发现 77 个伪装成合法工具的恶意扩展。软件供应链正在经历最严重的信任危机。 如果你在昨天更新了一个 npm 依赖包，你的开发凭证可能已经被传到了攻击者的服务器上。 这不是危言耸听。8 月第一周，安全圈连续拉响三个供应链安全警报。先说最严重的那个——ChainDrop。 01 ChainDrop：一场精心策划的 npm 大屠杀 ChainDrop 恶意软件的规模让最资深的供应链安全研究员都倒吸一口凉气。超过 1300 个 npm 包被感染，这些包的月下载量合计达到 20 亿次。 20 亿次，什么概念？这意味着地球上每四个人里，就有一个人”可能”间接使用了这些被投毒的包。当然会有重复下载，但这个数量级已经说明了一切——这不是一次对特定目标的攻击，而是一次对全球开发者生态的无差别扫射。 ChainDrop 的攻击链条设计精巧得让人不寒而栗。被感染的 npm 包并不会立即”爆炸”，而是静默地在开发环境中运行。它做了三件事： 第一步，收集 npm Token 。你在本地的 .npmrc 文件里的认证令牌，被它悄悄读取并发送到远程服务器。 第二步，窃取 GitHub 凭证。它扫描你的 SSH 密钥和 Git 配置，获取对代码仓库的访问权限。 第三步，自我传播。拿到你的 npm Token 之后，它不是就此收手——而是利用这个 Token 登录你的 npm 账号，向你的其他包也注入恶意代码。 攻击者的意图很明确：他们不只是想要一次性的数据窃取，而是在建立一个不断自我繁殖的恶意网络。每感染一个开发者，就能感染更多的包；每感染一个包，就能捕获更多的开发者。 02 77 个”孪生恶魔”：Open VSX 的伪装攻击 同一天，另一个让人头疼的消息从开源 IDE 扩展市场传来。 Open VSX 市场（VSCode 等编辑器的扩展商店）移除了 77 个恶意扩展。这些扩展玩的是一个”孪生”策略——取一个和知名开发者工具极为相似的名字，让用户以为自己在安装一个熟悉的工具。一旦安装，它们就开始收集主机名、仓库信息、CI 环境数据和开发凭证。 这 77 个恶意扩展总下载量超过百万次。攻击者把”鱼目混珠”玩到了极致：有的伪装成 Docker 集成工具，有的伪装成 Git 增强插件，还有的伪装成代码片段管理器——都是开发者日常开发离不开的功能。 03 HalluSquatting ：AI 幻觉成了帮凶 如果说上述两种攻击是对”人类信任”的利用，那么 HalluSquatting 则开辟了一个全新的战场：攻击 AI 的信任。 这种攻击手法的核心思路堪称天才：既然 AI 编程助手（如 GitHub Copilot、Cursor、Claude Code）会产生”幻觉”——推荐不存在的代码包——那攻击者要做的，就是把这些”幻觉”变成现实。 过程是这样的：AI 编程助手在生成代码时，可能会推荐一个实际不存在的包名（比如 security-checker-pro ）。这是 AI 根据训练数据中的命名模式”编”出来的。攻击者会定期扫描这些 AI 推荐的”幻觉包名”，一旦发现某个包名被高频推荐但不存在，就抢先注册它——里面的代码是恶意的。 然后你作为开发者，让 AI 帮你写了一段”安全检查”的代码，AI 自动 import security-checker-pro 。你安装了它，因为这是 “AI 推荐的”。攻击者的恶意代码就在你的生产环境中运行起来了。 这已经不是人类被欺骗。是 AI 被欺骗后，AI 再欺骗了你。 这三件事在同一天登上头条，不是偶然。它们指向了同一个残酷现实：软件供应链的每一个环节，都有可能成为攻击入口。 npm 生态有超过 300 万个包，每天有数万个新版本被发布。VSCode 扩展市场有数万个扩展，每个扩展都可能读取你的文件系统。AI 编程助手每天都在生成数百万行代码，其中包括大量第三方依赖的导入语句。 过去我们谈供应链安全，聚焦在”我直接依赖的包是否安全”。ChainDrop 和 HalluSquatting 告诉我们，这个思路已经彻底过时了。攻击面已经从”你依赖的包”，扩展到”生产你依赖产品的每一个 AI 工具和自动化环节”。 面对这波供应链攻击，三条防线迫在眉睫。 第一条防线：依赖锁定 + 子资源完整性。 不要信任任何一个自动更新的依赖。把直接依赖和间接依赖的版本、哈希值全部锁死在 lockfile 里。不要用 npm install 跳过 package-lock.json 。这不是什么新鲜建议，但看了ChainDrop 的规模之后，你应该知道这个建议有多重要了。 第二条防线：令牌权限最小化。 npm Token 不要给 publish 权限，除非你真的要发布包。GitHub Token 不要给 repo 全量权限，按仓库逐个授权。CI 环境的凭证不要和个人开发的凭证混用。每一次权限的过度授予，都是给攻击者留的门。 第三条防线：审查 AI 生成的代码依赖。 在 AI 帮你写了 import xxx 之后，去 npm 搜一下这个包是不是真实存在、最后一次更新是什么时候、维护者是谁。如果一个包的维护者是一串乱码邮箱、没有 README、上周刚注册——这就是一面巨大的红旗。 供应链攻击从”可能发生”到”正在发生”，只用了几年的功夫。从 ChainDrop 的 1300 个包，到 Open VSX 的 77 个假扩展，再到 HalluSquatting 的精确围猎——攻击者比你更了解你使用的每一个工具链条。 你的代码不是孤立的。它依赖着成千上万个”别人的代码”，而”别人的代码”来源可能是一个被 AI 幻觉生成的包名，然后被一个蹲点的攻击者抢注。任何一环断裂，整个链条都会崩塌。 这一次，1300 个包被污染。下次呢？