SBOM 扫描能否替代人工漏洞定位?

SBOM 扫描不能替代人工漏洞定位。软件物料清单（SBOM）回答的是“交付物中识别出了哪些组件”，漏洞扫描则尝试将这些组件与漏洞信息匹配；人工定位还要确认组件是否真实存在、是否受到影响，以及业务执行路径能否触及缺陷。三者关注的问题不同，扫描结果更适合作为调查入口，而不是风险结论。

扫描命中不等于实际暴露

以 CI 镜像中的 libcurl 为例，扫描发现相关组件后，还需核对它来自系统包、构建阶段残留，还是独立分发的内部工具。最终运行镜像中的组件、构建任务实际使用的组件，可能不是同一个对象。如果只查看宿主机上的版本，容易遗漏流水线内部真正调用的库。

版本匹配也需要结合补丁状态判断。发行版可能对维护分支反向移植修复，因此不能仅凭上游版本号认定组件一定存在漏洞；反过来，扫描未命中也不能证明风险不存在，静态链接的库可能没有被完整识别。对于独立 CLI，需要结合构建信息、二进制线索和实际依赖关系进一步核查；单一版本字符串本身也不足以证明组件的完整状态。

定位要追到执行路径

风险判断还取决于漏洞的触发条件。对于资料中描述的 libcurl 缺陷，调查重点不只是“是否安装了 curl”，还包括相关任务是否执行数据上传、连接是否协商 HTTP/2，以及实际调用的库是否处于受影响状态。满足前两项说明路径具备进一步核查的价值，并不单独证明漏洞已经触发或一定可以被利用。

因此，合理分工是让 SBOM 扫描持续发现候选组件，再由分析人员核对来源、补丁、链接方式和业务路径。修复后也应重新检查交付物与实际运行环境，避免只更新了系统包，却留下静态链接工具或构建阶段使用的旧组件。