依赖漏洞扫描

它解决什么问题

一次 npm install 背后可能拉进数百个直接和传递依赖，其中大部分并非你亲自选择。研究表明，超过 80% 的漏洞来自传递依赖，而多数团队只盯着自己写的代码。其他常被忽略的缺口包括：CI 未纳入锁文件扫描，扫描版本与线上部署版本不一致；缺少许可证合规检查，GPL/AGPL 依赖到法务评审阶段才暴露；没有 SBOM，安全事件发生时无法回答「我们到底用了什么」。

核心能力与工作流程

技能按六步执行：

1. 识别包生态与清单文件 — 自动探测 package.json / package-lock.json（Node.js）、requirements.txt / Pipfile.lock（Python）、pom.xml / build.gradle（Java）、go.sum（Go）、Gemfile.lock（Ruby），支持 monorepo 多清单结构。
2. 解析完整依赖树 — 从锁文件构建含传递依赖的完整依赖图，识别依赖深度、共享子依赖与版本约束，并标记代码中用到但清单未声明的「幽灵依赖」。
3. 比对漏洞数据库 — 针对每个包和版本查询 NVD、GitHub Advisory Database 与 OSV，按 CPE 或 PURL 匹配，记录 CVE ID、CVSS 评分、严重级别、受影响版本范围与修复版本。
4. 许可证合规检查 — 提取各依赖声明的许可证并与项目策略比对，标记 copyleft 许可证（GPL、AGPL）、无许可证声明的包，以及直接与传递依赖之间的许可证冲突。
5. 生成 SBOM 与漏洞报告 — 输出 CycloneDX 或 SPDX 格式的 SBOM；漏洞报告按严重级别排序，包含 CVE 标识、受影响依赖路径、可用修复版本，以及漏洞代码路径是否可达。
6. 推荐并应用修复 — 建议不破坏兼容性的最小升级版本，必要时自动生成更新后的清单与锁文件；无修复版本时标记出来，并给出替代包或绕过方案。

适用边界与注意点

• 私有源与内部包：私有 npm 或内部 PyPI 上的包不会出现在公开漏洞库中，需维护私有 advisory 数据源，或使用支持自定义数据源的工具。
• 无修复版本的 CVE：先评估漏洞代码路径在你的应用中是否可达，再决定替换依赖或打本地补丁。
• override 引入的冲突：通过 npm overrides 或 pip constraints 强制升级传递依赖可能引入运行时不兼容，应用自动修复后务必运行测试套件验证。
• 无人维护的包：没有已知 CVE 但无活跃维护者的包同样是供应链风险，应规划迁移到活跃维护的替代品。