npm供应链蠕虫400+投毒包，Node项目依赖安全自查流程
npm 供应链蠕虫事件再次给 Node 生态敲响警钟：短短几天内被披露的投毒包就超过 400 个，它们伪装成热门工具，伺机窃取环境变量、部署挖矿程序。
对普通开发者来说，最重要的不是等官方清理，而是学会自己动手完成一轮依赖安全自查。
下面这套流程以 npm 命令为主，不需要安全背景，照着执行即可确认当前项目是否受影响、哪些包需要处理。
先搞懂这次投毒包是怎么混进项目的
npm 投毒包通常不会直接以官方库名出现，而是采用两种路径：一种是把名字改成与原包高度相似，比如 lodahs 代替 lodash；
另一种是藏在某个被安装的传递依赖里，也就是你只安装了 acme-tool，它内部又悄悄引用了恶意包。
此外，这类蠕虫还有自我传播能力，会读取本机 .npmrc、.env 等文件，甚至尝试通过发布新包继续扩散。
所以自查范围不能只盯着 package.json 里直接写明的依赖，
还要覆盖 node_modules 里实际安装的每一个包，
以及锁文件 package-lock.json 或 npm-shrinkwrap.json 中的解析结果。
自查前先确认环境与项目状态
在跑命令之前，先确认以下三点：
- 本机已安装 Node.js 和 npm，终端输入
node -v与npm -v能看到版本号。 - 已经进入项目根目录，并且该目录下存在
package.json和锁文件。 - 有稳定的网络连接，必要时设置好 npm 镜像，避免审计请求超时。
建议先把当前依赖锁定版本再操作，避免 npm install 顺手升级到未知版本。
如果项目还没安装依赖，先执行 npm ci 而不是 npm install，因为 npm ci 会严格按照锁文件安装，不会静默改动依赖树。
三步完成依赖风险扫描与定位
第一步：用 npm audit 检查已知漏洞
npm 官方漏洞库已经收录了大部分披露的恶意包，直接运行：
npm audit输出结果会列出漏洞等级、受影响的包名称、版本和修复建议。
如果看到 high 或 critical 级别的 Malicious Package，说明当前项目命中了已知投毒包。
建议继续执行审计签名校验：
npm audit signatures该命令会验证已安装包是否与官方注册表签名一致，适合识别被篡改的包。
注意，npm audit 只能检查已知问题，没有进入漏洞库的新型投毒包它查不到，因此不能作为唯一依据。
第二步：核对锁文件中的实际来源
投毒包可能隐藏在深层传递依赖里，只看 package.json 完全发现不了。
这时需要把完整依赖树导出来：
npm ls --depth=9999如果项目很庞大，输出会非常长，可以配合过滤只找可疑项：
npm ls --depth=9999 2>/dev/null | grep -E "lodahs|nodemssql|discord-fetch|proxy-collector"更稳妥的做法是生成 JSON 快照，方便用编辑器搜索：
npm list --json > deps.json接着打开 deps.json，重点检查这些字段：resolved 是否为官方 registry 域名，integrity 是否为空，dev 标记是否符合预期。
如果发现某个包的下载地址不是 registry.npmjs.org，或者整个项目里出现大量相似度高、更新频率异常的小包，就要单独核实。
第三步：直接在 node_modules 里查脚本和文件
有些恶意包不会在审计库显示，但会在安装时执行 postinstall 脚本。
可以先看根项目里有哪些依赖带安装脚本：
npm ls --depth=0 --json | grep -E "postinstall|preinstall|install"然后手工查看可疑包的 package.json：
cat node_modules/恶意包名/package.json重点检查 scripts 字段里的 preinstall、install、postinstall 是否包含下载远程文件、访问环境变量、调用 curl / wget 等操作。
同时可以用以下命令扫描整个依赖目录里被修改过时间戳的配置文件：
find node_modules -name "package.json" -newermt "2025-01-01" -exec grep -l "postinstall" {} \;这条命令会列出近期创建且带 postinstall 的包，再逐个人工确认，比盲目删依赖更安全。
发现投毒包后的处理与避坑方法
如果自查确认某个包有问题，不要直接手动删除 node_modules 里的文件夹，那样可能破坏依赖关系。
正确流程是：在 package.json 中确认谁引用了它，然后对问题包做版本升级或替换，再执行 npm ci 重新安装。
如果来源不明且没有替代包，先移除引用它的上层依赖，再单独申请安全审核。
这里有几个常见坑容易让自查失效：
- 只看生产依赖，忽略 devDependencies。 投毒包同样可能存在于开发环境，CI 构建时一样会被执行。
- 锁文件不是最新就运行 npm install。 它会自动升级部分包，容易让恶意包混入；建议先
npm ci保持锁文件完全一致。 - 把私有包误判为恶意包。 企业在内部 npm 私服上的包会显示非官方域名，这时需要结合
.npmrc中的 registry 配置来判断，不能一刀切。 - npm audit 提示网络错误。 可以换镜像重试，例如
npm audit --registry=https://registry.npmjs.org，但注意镜像源自身也可能是风险点。
验证自查结果并建立持续防护
执行完上述检查后，最后再做一次纯净验证：删除现有依赖和锁文件缓存，重新安装并审计。
rm -rf node_modules package-lock.json
npm cache clean --force
npm ci
npm audit
npm audit signatures如果两次 npm audit 都只剩低风险项，且 npm ls --depth=9999 里没有可疑包名，基本可以确认当前项目干净。
想要后续不再被动，建议把下面几条养成习惯：
- 锁文件必须提交到 Git，并禁止在
package.json里使用*或latest范围。 - 每次
npm install之前，先看变更范围，尽量用npm ci部署。 - 在 CI 流水线里加入
npm audit --audit-level=high，一旦发现高危直接中断构建。 - 定期执行
npm outdated，并及时跟进官方安全公告。
这次 npm 供应链蠕虫事件提醒所有人：依赖安全不是装一个扫描工具就结束的工程，而是需要持续核对锁文件、关注脚本行为、控制依赖来源。
按照上面的自查流程走一遍，至少能把已知的 400+ 投毒包风险排除掉，也为后续的团队安全基线打下一个可执行的样本。
如果你正在处理同一类问题，建议先完成三步扫描，再根据实际命中的包名对症修复，遇到异常时回看避坑部分基本都能找到原因。
