经常和 npm、PyPI 打交道的 DevOps，这个 8 月应该过得不太平静。
8 月 4 日，常用 npm 包 keyv 的维护者账号被攻破，恶意版本随后像蠕虫一样向更多包扩散。石臻说AI不到四个小时，攻击者就毒化了超过 12 个受害组织中的 444 个包和 2212 个版本。安全玻璃盒
这个月被盯上的不止 npm。8 月 11 日，CloudSEK 与 Hudson Rock 联合公开了 3 月 LiteLLM 投毒事件的完整复盘，暴露面覆盖全球 43.4 万条 CI/CD 流水线、2500 余家企业的生产构建环境。知乎8 月 20 日，Socket 又披露了一起针对阿里巴巴开发环境的 npm 供应链攻击。前端开发爱好者
我把 Socket、Aikido、Wiz、火绒等安全厂商的复盘完整读了一遍，浓缩成一句话：对每天跑 install、维护流水线的我们来说，比攻击本身更容易踩进去的，是三个误区。
误区一：「我没用 keyv，跟我没关系」
这次蠕虫攻击最狡猾的地方，是 keyv 很少是直接依赖。常见链路是 eslint→file-entry-cache→flat-cache→keyv，全是二级、三级间接依赖，Wiz 的客户环境统计里，file-entry-cache、flat-cache 和 keyv 的出现率都在 46% 左右。石臻说AI也就是说，差不多一半的 Node 项目，依赖树里都埋着它们。
更麻烦的是，带毒的 keyv@6.0.0 还带着通过验证的 provenance 签名。因为它确实是官方 GitHub Actions 工作流构建出来的，问题只在于工作流拿到的源代码已经被污染——签名能证明「是谁、用哪条流水线构建」，不能证明源代码本身安全。石臻说AI所以「有签名就安全」这次也不成立了。
误区二：「官方已经下架，我也升级了，就没事了」
npm 官方后续确实下架了恶意版本。但 lock 文件、旧的 CI 缓存和私有镜像源会持续保留恶意版本，下架不等于风险消失，很多企业内网的私有 npm 镜像不会自动同步官方的删除操作，毒包会长期驻留。知乎
3 月的 LiteLLM 事件就是同一套剧本：恶意版本从上架到下架只存活了约 40 分钟，但 7×24 小时不间断构建的自动化流水线，足够在这个窗口期里完成批量拉取，最终暴露的流水线达到 43.4 万条。知乎更让人意外的是，这次攻击的上游入口是大家都默认信任的安全扫描工具 Trivy，攻击者篡改了 Trivy 的 GitHub Action，借它偷走了维护者的 PyPI 凭证。量子位连安全工具本身都不能默认信任，这是这件事给 DevOps 圈最大的认知刷新。
而且这不是一次孤立事件：火绒安全实验室在监测中发现的新一轮高危 npm 供应链投毒攻击，经确认仍由 TeamPCP 组织发起。火绒安全从第一代 Shai-Hulud 蠕虫到这次的演化版本，持久化目标已经延伸到 Claude Code、VS Code 和 GitHub Copilot 工作流。安全玻璃盒把两代蠕虫的机制放在一起对比，就能看清该防什么、该查哪些版本。
误区三：「发现中招，赶紧把所有密钥换一遍」
这是最危险的一步。Socket 发现，这轮恶意程序会每 60 秒检查被盗的 GitHub token 是否仍然有效，一旦收到 4xx——也就是你撤销或轮换了 token——它可能执行远程下发的处理命令。石臻说AI密钥一定要换，但顺序不能乱：没有事件响应经验的团队，最安全的动作是先把疑似主机断网隔离，由安全人员清除持久化项，最后再轮转凭证，别在生产环境里试着触发它。
自查清单（直接照做）
查 lock 文件：全库检索 keyv@6.0.0、flat-cache@6.1.24、file-entry-cache@11.1.6、cacheable-request@13.0.20 这几个已确认的恶意版本，仅 keyv 一个包每周下载量就超过 1.5 亿次。安全玻璃盒Python 项目再加 litellm 1.82.7 和 1.82.8，这两个版本携带的 litellm_init.pth 文件，不需要业务代码 import，只要 Python 进程启动就会自动执行。量子位别只翻 package.json，间接依赖只会出现在 lock 文件里。
查执行记录：翻 8 月 4 日之后的开发机与 CI 构建日志，确认有没有安装过上述版本、安装脚本有没有真正执行过。
按场景分级：只在个人开发机出现、且不掌握生产凭证的，清理环境、更新版本即可；CI runner 或生产环境命中的，按「主机失陷」处理——断网隔离、清除持久化、全量轮转凭证（云 AK、Git token、大模型 API Key、K8s Secret），重建构建缓存，并审计权限操作日志。
查私有镜像：确认公司内部的 npm、PyPI 私有源是否还缓存着恶意版本，手动同步下架。
最后说句判断
这波攻击的重心，已经从「你的代码有没有漏洞」彻底转向「你的自动化信任了什么」。GitHub 在 7 月底为 Dependabot 默认开启了 72 小时的版本更新冷却期。知乎npm 也上线了发布环节的自动恶意软件检测，可疑版本还会进入人工审核。前端开发爱好者它们本质上都在做同一件事：给自动化买时间，别让恶意版本在「即时自动更新」的窗口期里扩散全网。
对普通 DevOps 来说，此刻最值得做的，不是恐慌性换密钥，而是把 lock 文件翻出来查一遍——「我中招没有」的答案就在那里。后续值得盯两个信号：公司私有镜像有没有同步下架恶意版本，以及 npm 新发布审核机制的实际拦截效果。再出现变种蠕虫时，先查 lock 文件，再决定动作。
