npm供应链投毒400+包，AI项目依赖包安全审计流程
近期披露的 npm 供应链投毒事件涉及 400 多个恶意包，不少伪装成 AI 工具或常用依赖被大量下载。
对于依赖密度极高的 AI 项目，npm 依赖包安全审计不能再只靠“感觉没问题”。
本文按零基础也能直接照做的顺序，从锁定依赖、自动扫描到人工复核，完整讲清一套可落地的审计流程，并给出可直接运行的命令。
为什么 AI 项目更容易被供应链投毒盯上
AI 项目通常重度依赖 npm 生态，像模型转换工具、向量数据库 SDK、API 封装库等，安装时会执行大量 install 或 postinstall 脚本。
攻击者常用两种手法：
- 包名仿冒：把恶意包命名成知名包的相似名，比如将
transformers改成transformers-ai或transfomers，拼写差一位，肉眼很难分辨。 - 脚本投毒：在正常功能代码里插入
postinstall脚本，安装时自动下载木马或窃取环境变量。
AI 项目里还有 .env、API Key、训练数据路径等敏感内容，一旦依赖被污染，泄露面比普通 Web 应用更大。
审计前准备：先锁死依赖版本和来源
很多供应链攻击利用的是“版本漂移”。
没有锁版本时，npm install 会拉取最新版，而恶意包可能刚被发布到某个新版本上。
先确认当前仓库是否已生成锁文件：
ls -l package-lock.json如果不存在，先执行：
npm install生成后提交到 Git，后续安装一律使用：
npm cinpm ci 严格按 package-lock.json 安装，不会改动依赖版本，是审计和部署时更安全的选择。
接着确认 registry 来源，防止指向被篡改的私有源：
npm config get registry正常输出应为 https://registry.npmjs.org/ 或你公司自建的可信镜像。
三步完成 AI 项目依赖包安全审计
第一步：用 npm audit 扫描已知漏洞
npm audit 会对比当前依赖和已知漏洞库，直接可跑：
npm audit如果只想看高危及以上问题，并输出 JSON 便于分析：
npm audit --json > audit.json注意：npm audit 只能发现已收录漏洞，对刚投放的恶意包基本无能为力。
所以不能把它当作唯一审计手段。
第二步：检查每个包的安装脚本
恶意行为常藏在 postinstall、preinstall 等脚本里。
逐个检查 node_modules 太重，可以直接看锁文件里的 hasInstallScript 字段：
npm ls --json | grep -B 5 "hasInstallScript": true更直观的做法是检查项目所有依赖的 package.json 中 scripts 部分，挑出非必要却存在的 install 脚本。
发现可疑脚本后，用下面命令查它的来源：
npm view <包名> --json对比安装后的版本、发布时间、维护者信息是否与官方一致。
第三步：核对锁文件中的下载地址和完整性
打开 package-lock.json，重点看 resolved 字段：
"resolved": "https://registry.npmjs.org/xxx/-/xxx-1.0.0.tgz"如果某个包的下载地址不是官方 registry，而是私有 IP、奇怪域名或带 http://，立刻标记为高危。
同时检查 integrity 字段，正常应为 sha512- 或 sha1- 开头的哈希值，缺失或为空说明校验可能被绕过。
常见误区和避坑提醒
- 只跑 npm audit 就完事：
npm audit对 0day 恶意包基本无感，必须结合脚本检查和来源核对。 - 忽略 lock 文件：不提交 lock 文件，等于每次安装都在碰运气。
- 随意安装带
latest的依赖：AI 项目迭代快，很多人喜欢装最新版，但这正是投毒窗口。建议固定精确版本，如"axios": "1.7.9"。 - 发现恶意包只删 node_modules：删除后如果 lock 文件没更新，重新
npm ci还会拉回问题包。正确做法是：先移除相关包，再删除node_modules和package-lock.json后重新生成，或者手动修改 lock 再跑npm install。
验证审计结果是否到位
完成上述操作后，建议逐条确认：
npm audit --audit-level=high无输出或显示 found 0 vulnerabilities，说明已知漏洞已处理。
再执行：
npm ls --depth=0检查顶层依赖列表，确认没有多出陌生包。
最后抽查一个关键依赖的安装脚本：
npm view <包名> scripts --json如果脚本干净、来源正规，整个审计流程就算走通了。
对 AI 项目而言，依赖包安全审计不是一次性任务，建议每次引入新依赖或每两周跑一遍上述流程。
如果条件允许，可以在 CI 中加入 npm audit 和脚本扫描步骤，让投毒包在进入代码库之前就被拦住。
你现在就可以按这套流程，先把你最常用的 AI 项目依赖全部过一遍。
