技能介绍

解决什么问题

现代软件的依赖关系早已不是几行 package.json 或 requirements.txt 能概括的。一个应用背后可能挂着数百个传递依赖，其中任何一个底层库被披露 CVE，都会让安全团队陷入「到底影不影响我们」的排查循环。人工维护依赖清单既容易遗漏，也无法在漏洞公开的第一时间给出答案。SBOM（Software Bill of Materials，软件物料清单）正是为这种场景而生：先把「软件由什么组成」变成结构化、可机器读取的记录，再让自动化工具基于这份清单做漏洞匹配，而不是靠猜。

技能如何工作

这个技能把两个成熟的开源工具串成一条流水线，并在结果层面做二次交叉验证：

SBOM 生成：调用 syft 扫描目标软件的组件，输出标准化的物料清单，覆盖语言生态中的直接与传递依赖。
漏洞扫描：拿到 SBOM 后，由 grype 对其中的每个组件执行 CVE 匹配，给出命中的漏洞条目及其严重度信息。
交叉对照：将扫描结果与 NVD（National Vulnerability Database）和 OSV（Open Source Vulnerabilities）两个漏洞库进行比对，避免单一数据源漏报或误报，提升检出结果的覆盖面。

整条链路的核心思路是「先盘点、再比对、最后复核」：Syft 负责事实（软件里有什么），Grype 负责匹配（这些东西有没有已知漏洞），NVD/OSV 负责验证（这些漏洞的记录是否一致）。

适用边界与注意点

SBOM 的准确性取决于扫描范围。如果目标仓库包含私有 registry 的组件或本地构建产物，需要确保 Syft 能访问到对应的源，否则清单会缺失条目，后续匹配也就无从谈起。
漏洞库的数据有延迟。NVD 与 OSV 收录 CVE 的时间并不同步，刚披露的漏洞可能暂时查不到，重要场景建议定期重跑扫描。
匹配结果不等于可利用性判断。一个 CVE 命中不代表当前版本一定受影响，修复建议仍需结合组件版本、许可证和实际调用路径确认。
该技能聚焦漏洞检测环节，不负责修复建议落地或补丁管理，后续流程需要与其他工具衔接。