npm依赖安全漏洞怎么排查？package-lock.json与Node.js供应链安全指南

随着 Node.js 项目依赖越来越多，安全问题已经不只是业务代码本身。一个看似普通的 npm 包可能继续依赖几十个甚至上百个第三方模块，其中任何一个依赖存在漏洞，都可能影响整个项目。因此，定期检查 npm 依赖、锁定版本并建立供应链安全机制，是前端和 Node.js 项目维护的重要工作。

使用 npm audit 排查依赖漏洞

npm 官方提供了 npm audit 命令，可以根据项目依赖树检查已知安全漏洞。进入项目目录后直接执行：

npm audit

如果希望获取更详细的 JSON 数据，可以执行：

npm audit --json

npm audit 会检查 dependencies、devDependencies、optionalDependencies 等依赖，并在结果中给出漏洞等级、受影响的软件包、依赖路径以及修复版本等信息。

对于 CI/CD 环境，可以设置最低漏洞等级，例如：

npm audit --audit-level=high

这样当项目存在 High 或 Critical 级别漏洞时，让构建流程直接失败，避免存在严重风险的代码继续发布。

很多开发者只关注 package.json，但真正决定项目安装哪些具体依赖版本的，通常还包括 package-lock.json。

例如：

"lodash": "^4.17.21"

^ 允许 npm 在符合版本范围的情况下安装更新版本，而 package-lock.json 会记录实际解析出来的依赖版本和依赖树。

npm 官方文档建议将 package-lock.json 提交到代码仓库，它能够让开发环境、测试环境和生产环境按照相同的依赖树进行安装，同时也方便通过 Git diff 发现依赖变化。

生产环境安装依赖时，可以优先使用：

npm ci

它会根据锁定文件安装依赖，更适合持续集成和生产部署。

如果项目没有 package-lock.json，npm audit 可能无法按照固定依赖树进行审计。可以使用：

npm install --package-lock-only

生成锁定文件。

发现漏洞后，可以先执行：

npm audit fix

它会尝试安装兼容的修复版本。

但不要看到漏洞就直接使用：

npm audit fix --force

因为部分修复可能涉及主版本升级，从而产生 API 或行为变化。npm 官方也提示，涉及 SemVer major 版本的升级需要进行人工检查。

更稳妥的处理流程是先查看：

npm audit

确认漏洞来自哪个包，再检查依赖关系：

npm ls 包名

如果是直接依赖，可以主动升级。如果属于间接依赖，则需要升级上层依赖，或者等待上游发布修复版本。

供应链风险经常来自间接依赖。

例如项目直接安装：

A
└── B
    └── C
        └── D

你的 package.json 中可能只有 A，但 D 同样属于项目实际运行环境的一部分。

因此排查漏洞时需要关注完整依赖树，而不是只查看 package.json 中列出的几个包。npm audit 返回结果中的 Dependency of 和 Path 字段，可以帮助定位漏洞究竟是由哪个依赖链引入的。

安全检查不能只停留在漏洞数据库。安装第三方 npm 包之前，可以查看它的维护情况、版本发布记录、GitHub 仓库以及依赖情况。对于来源不明、长期无人维护或者近期突然出现异常更新的包，需要提高警惕。

npm 目前还支持包签名和 provenance 验证，可以使用：

npm audit signatures

检查下载包的注册表签名以及 provenance 信息。

对于自己维护并发布 npm 包的开发者，还可以使用 Trusted Publishing，通过 OIDC 连接 npm 与 CI/CD 平台，减少长期 npm Token 暴露风险。npm 官方目前支持通过可信发布建立 CI/CD 发布信任关系。

对于长期维护的 Node.js 项目，可以把依赖安全检查纳入日常开发流程：

提交代码
   ↓
npm ci
   ↓
npm audit
   ↓
发现漏洞
   ↓
确认影响范围
   ↓
升级依赖
   ↓
运行测试
   ↓
重新npm audit
   ↓
发布

同时建议定期更新依赖，而不是几年后一次性大版本升级。package-lock.json 提交 Git，生产环境使用 npm ci，CI 中设置 npm audit --audit-level，高风险项目再增加签名和 provenance 检查。

npm 依赖安全的核心并不是看到漏洞后简单执行一次 npm audit fix，而是持续掌握项目实际依赖树、锁定版本、追踪漏洞来源，并对第三方包的来源和发布过程进行验证。这样才能从依赖管理、漏洞修复和供应链三个层面降低 Node.js 项目的安全风险。

网友点评

提交

概要