SBOM如何定位受漏洞影响的已发布镜像?

漏洞通报指向某个组件版本时，首先要回答的不是“哪个仓库用了它”，而是“哪些已经发布的镜像包含它”。仓库当前的锁文件只能反映当前依赖状态；旧镜像可能由更早的提交构建，不能用今天的扫描结果替它们排除风险。SBOM 的作用，是把组件及其版本与具体镜像关联起来，支持对存量产物反向检索。

定位时，应先根据漏洞信息确定受影响的组件和版本范围，再检索已发布镜像对应的 SBOM。命中的记录需要回到镜像身份核对，而不能仅凭镜像名称判断：同名镜像在不同构建后可能指向不同产物。随后结合发布记录，区分仍在运行、等待晋升和已下线的镜像，形成需要处置的清单。

这里有一道关键边界：依赖扫描依据清单和锁文件生成的 SBOM，未必足以证明最终镜像的全部内容。如果构建过程引入了其他组件，或解析结果与锁文件不一致，仅检索这份 SBOM 就可能漏报。因此，SBOM 应与实际交付的镜像保持可核对的关联；无法确认一致性的产物，应标记为待核查，而不是直接判定为安全。

命中漏洞也不等于漏洞一定可被利用。组件是否进入运行路径、服务是否暴露、是否需要认证，都会影响处置优先级，但这些判断不能替代版本匹配。修复后应重新构建镜像并生成相应 SBOM，确认新产物不再包含受影响版本；旧镜像只要仍可能被部署，就仍需留在追踪范围内。