技能介绍

多语言依赖带来的安全盲区

现代项目几乎不可能只依赖少量包。一个典型的 Node.js 服务可能引入数百个传递依赖，Python 项目的依赖树同样复杂。当这些依赖中某个传递包被曝出 CVE，开发团队往往直到 CI 失败或安全通告发出后才发现。更棘手的是许可证合规问题——一个 GPL 许可证的传递依赖可能悄无声息地进入专有项目。

从清单到 SBOM 的完整扫描链路

此技能的工作流分为六个关键步骤：

识别生态系统 — 定位 package.json、requirements.txt、pom.xml、go.sum、Gemfile.lock 等清单文件，支持多语言单体仓库。
解析依赖树 — 从锁定文件构建完整的直接与传递依赖图，标记未声明的幻影依赖。
漏洞匹配 — 针对每个包和版本查询 NVD、GitHub Advisory、OSV，记录 CVE ID、CVSS 分数、严重级别和修复版本。
许可证审计 — 提取每个依赖的许可证声明，标记 copyleft 许可证（如 GPL、AGPL）和许可证冲突。
生成报告 — 输出 CycloneDX 或 SPDX 格式的 SBOM，以及按严重性排序的漏洞报告，包含依赖路径和修复建议。
推荐修复 — 建议满足修复要求的最小版本升级，尽可能自动生成更新后的清单和锁定文件。

适用边界与注意点

私有包需要自定义数据源 — 托管在私有 npm 或内部 PyPI 上的包不会出现在公共漏洞库中，需配合 Trivy 等支持自定义源的工具。
版本覆盖可能引入兼容性问题 — 通过 npm overrides 或 pip constraints 强制升级传递依赖后，务必运行完整测试套件。
未维护的包本身就是风险 — 即使没有已知 CVE，缺乏活跃维护者的包也应被视为供应链隐患。
混合仓库需独立扫描 — 包含多种语言服务的单体仓库应分别扫描后合并报告，避免清单解析混淆。