NPM 包漏洞扫描器

npm 依赖中的安全盲区

当项目依赖的 npm 包被报告存在已知漏洞时，团队往往面临两个问题：一是漏洞信息分散在多个来源，npm audit 的输出与 GitHub Advisory Database（GHSA）中的严重等级口径不一致；二是手动排查 package-lock.json 或 yarn.lock 中的传递依赖极其耗时，容易遗漏被多层嵌套引入的高危包。

扫描机制与数据链路

该技能通过两条数据源交叉验证漏洞信息：

• npm audit JSON API：直接读取当前项目的锁文件，返回 CVE 编号、受影响版本范围以及可达路径；
• OSV.dev REST API（api.osv.dev/v1/query）：提供跨生态系统的漏洞数据，弥补 npm 原生数据库覆盖不全的问题；
• 将两份结果与 GitHub Advisory Database 对齐，统一 severity 评分（如 CRITICAL、HIGH），避免因数据源差异导致的误报或漏报。

典型工作流为：解析锁文件 → 提取依赖树 → 并行查询两个 API → 按 GHSA 严重等级排序输出 → 生成可操作的修复建议。

适用边界与注意点

• 该扫描器仅覆盖 已公开且被收录 的漏洞，无法检测 0-day 或未上报的安全问题；
• 依赖 api.osv.dev 与 GitHub Advisory Database 的网络可达性，内网环境需配置代理或镜像；
• 对于 monorepo 或多锁文件项目，需分别对每个 package-lock.json 运行扫描，结果不会自动聚合；
• 建议将扫描结果接入 CI/CD 流水线，作为 npm ci 之后的门禁步骤，而不是依赖定期的人工检查。