Axios npm 供应链事件后，开发团队如何重做依赖发布门禁

不少团队升级npm依赖时，往往只扫一眼小版本跨度就直接放行，根本没放在心上，没经过审核的陌生安装脚本，直接就在开发机和CI执行机上跑了起来。2026年3月爆出的Axios npm供应链事件就是非常典型的警示：开发团队的依赖管控不能停留在「这个包能不能装」的层面，得升级到「为什么允许这个包进入全发布链路」的校验标准。

依赖发布门禁至少要核对版本来源、锁文件变化、安装脚本和CI权限；发现异常版本时先冻结发布、撤销缓存，再判断是否需要处置runner和凭据。

这次事件暴露的不是一个单点漏洞

从Axios官方仓库公开的记录来看，axios@1.14.1 和 axios@0.30.4 被发布到npm之后，带入了恶意依赖 plain-crypto-js。OpenAI后续也披露，他们的macOS应用签名流水线曾经下载并执行过受污染的Axios版本，因此必须轮换签名证书，同步推动客户端更新。

这条攻击链路至少有四个风险节点：项目维护者账号、npm发布包、安装阶段脚本、持有敏感凭据的CI执行机。只在项目源代码里搜索 axios，基本找不到真正的入侵入口，因为恶意行为发生在依赖安装和 postinstall 执行阶段。

先冻结发布，再确定机器是否真的受影响

发现可疑版本的时候，不要一边继续发版一边回头补检查。第一步先冻结所有依赖升级操作和自动部署流程，完整留存锁文件、构建日志、npm缓存文件夹还有执行机的全量作业记录。第二步直接搜索精确版本号和恶意依赖名，不要只在业务代码的范围内检索。

rg -n 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js' \
  package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml .github node_modules

锁文件里命中异常版本，不等于机器已经执行过恶意脚本；只有在构建日志或者安装缓存里查到对应记录，才说明需要扩大排查范围。把「存在该版本」和「发生过安装执行」拆成两个独立的判定状态，后续处置会准确很多，不会做多余的无用功。

把依赖门禁放进日常发布路径

锁文件是安全管控的起点，绝非最终的安全保障。发布流程里至少要保留四个可追溯审计的检查环节：

面向高风险项目，可以把依赖安装改成离线缓存加哈希校验的模式；普通项目哪怕先落地锁文件人工审查、脚本变更告警和最小权限配置，也比每次直接安装最新版本要稳妥很多。

恢复发布时要重新建立信任边界

所有处置动作完成后，要在全新的干净执行机上完成依赖安装，重新生成合法锁文件，不要直接复用可能已经执行过恶意脚本的旧工作目录。如果之前的执行机本身有权限访问云密钥、npm令牌或者签名材料，直接按敏感凭据可能泄露的标准处置，做全量轮换。全部校验通过后再恢复流水线运行，并且把这次事件涉及的版本、影响时间窗和全量检查结果写入正式发布记录。

团队可以当天落地的清单

• 把依赖版本、锁文件、源站配置和安装脚本变更纳入合并检查环节。
• 禁止CI默认读取不必要的生产密钥。
• 为npm缓存设置清理和失效策略，异常构建保留全量原始证据。
• 遇到污染版本，按冻结、定位、清缓存、轮换凭据、干净重建的顺序处理。

相关问题

只看 npm audit 能发现这类事件吗？

不能。恶意发布可能先于漏洞数据库登记，版本来源、依赖树和安装脚本都需要单独走检查流程。

锁定版本后还需要审查源站吗？

需要。锁文件能降低版本漂移概率，但仍要确认下载来源、完整性和构建环境没有被替换。

什么时候必须轮换 CI 凭据？

只要受污染依赖在能读取令牌、云密钥或签名材料的执行机上完成过安装，就不应只删除node_modules草草处理，而应按可能暴露的标准走全量轮换流程。

信息来源

版本与事件线索以 Axios 官方仓库记录、OpenAI 事件说明 和 GitHub Advisory Database 为准。依赖处置时仍应以团队自己的锁文件、CI日志和凭据权限记录为最终证据。