产品发布后的 SBOM 维护

Sytance · 更新于 2026-09-15

每份 SBOM 都需要明确对应的软件版本。软件更新可能改变组件组成，清单修订则可能只是更正信息，软件本身并未变化。分别记录软件版本和清单修订号，才能确认客户收到的软件及其准确的组件清单。

清单对应的软件

在构建或发布流程中的固定阶段生成 SBOM，并保留源代码版本、实际使用的依赖、构建配置和交付文件的标识。这些信息用于复现构建，或调查清单与软件之间的差异。

CycloneDX 指南区分从源码、构建过程和运行环境生成的清单。不同阶段包含的软件可能不同。标明生成阶段后，接收方才能知道清单描述的是声明的依赖、构建结果，还是实际部署的软件。

对于网关，需要结合应用构建、基础镜像和外购固件组件的信息，保留与供应商 SBOM 的关联。网关使用的云端服务可能需要独立清单，并按照自己的发布节奏维护。

版本比较需要说明哪些组件新增、删除、升级或重新构建，以及依赖路径发生了什么变化。例如，删除一个库再加入另一个库，组件总数没有变化，但软件组成已经不同。

比较时可以统一标识格式，但需要保留原始版本号和标识符。如果工具新识别出此前未知的软件包，还需要确认这是识别结果改善，还是软件确实发生了变化。

按照声明的格式版本校验文件，再检查信息含义。确认每个引用均可解析，根产品对应本次发布，接收方能够访问引用的组件 SBOM。

对候选版本执行漏洞和许可证检查，并将结果关联到该版本。新增的高优先级问题需要有处理决定；此前允许暂不处置的问题，如果组件版本或运行条件发生变化，也需要重新评估。

将批准发布的软件、SBOM、构建记录和评审结果一起归档。采用签名时，需要验证签名，并确认签名者是预期发布者。

2026 年联合 SBOM 指导建议为每次软件版本或更新提供对应 SBOM，发现错误或获得新的组件细节时发布清单修订，并区分未知信息与有意不提供的信息。

例如，供应商更正组件生产方，但固件文件内容没有变化。此时应保留原有固件标识，发布新的 SBOM 修订，说明更正内容，并保留此前文档。接收方才能区分资料更正与软件更新。

通过约定渠道提供更新。固定入口可以指向当前修订，历史文件保留原始内容。同时确认接收方能够判断新修订替代了哪一份旧清单。

收到新公告后，在各受支持版本中查找相关组件，再结合实际构建和使用方式判断影响。组件组成保持不变时，新的漏洞信息仍可能使影响判断发生变化，因此清单和漏洞评估需要分别保留修订记录。

如果网关 1.0 包含受影响库，而 1.1 已删除该库，新版本发布不会改变已经安装的 1.0 设备。团队仍需确定这些旧版本设备的处置方案，并准确记录公告或 VEX 声明涵盖的版本。

明确谁负责跟进供应商更新、分析影响、批准处置方案，以及通知相关人员。根据产品支持义务及新信息的严重程度安排复核时点，不能只等待下一次计划发布。

支持结束时，保留产品版本与 SBOM 的对应关系，以及与历史交付有关的处置决定及其依据。按需限制敏感记录访问，同时保证获授权接收方能够取得已约定的信息。

维护交接时，接手人员需要能够按产品版本找到清单、定位组件并查看最新影响分析。用一个仍在支持期内的版本核对这些资料，有助于发现缺失记录或访问权限问题。