SBOM 与构建来源证明怎样走向协同

我在梳理软件供应链资料时，最容易混淆的一组概念就是 SBOM 和构建来源证明：它们都会出现在发布附件或制品仓库附近，却回答着两类不同的问题。SBOM 主要说明“这个制品包含哪些组件、版本和依赖”，构建来源证明（provenance）则说明“这些输入由什么构建系统、以什么身份和参数生成了这个制品”。真正有用的方向不是二选一，而是把两份事实绑定到同一个交付对象上。

官方资料入口：https://tag-security.cncf.io/community/working-groups/supply-chain-security/supply-chain-security-paper-v2/sscbpv2/

SBOM 负责描述组成，provenance 负责描述来路。协同的最小单位不是“仓库里有两份文件”，而是“同一个制品摘要能够找到对应的组件清单、构建声明、签名身份和策略判断”。

SBOM 和 provenance 先要分工清楚

CNCF 供应链安全社区把 SBOM 生成、格式、存储和消费，与来源证明、SLSA、in-toto 和策略执行分别列为关注点。这种划分很实用：SBOM 是组成视图，provenance 是构建事实视图。一个能回答“有没有某个依赖”的清单，不能单独回答“它是不是由允许的构建器生成”；一份构建声明，也不能替代依赖清单去说明最终制品的内容。

为什么两份元数据要绑定到制品摘要

我会先把“关联对象”固定下来，再讨论格式。一个版本号或文件名可能在不同构建中重复出现，制品摘要则更适合作为元数据关联锚点。CNCF Secure Software Factory 资料把 SBOM、测试报告和漏洞报告视为某次构建的快照，并建议让这些元数据链接到最终交付制品；同一条原则也适用于 provenance。

因此，发布物至少应能沿着下面的关系回溯：制品摘要找到 SBOM，SBOM 说明组件与版本；制品摘要找到 provenance，provenance 说明源代码输入、构建器身份、构建参数和输出；签名与身份再为这些声明提供可验证的信任边界。不要把“同目录下有两个 JSON 文件”当成关联，因为文件名、上传时间或目录层级都不够稳定。

标准各自提供接口，不等于工具自动完成协同

SBOM 侧常见的是 SPDX 和 CycloneDX，它们解决组件清单的表达与交换；来源证明侧常见的是 SLSA provenance 和 in-toto 相关证明模型，它们关注构建输入、构建过程与可验证声明。它们可以组合，但并不意味着任意工具生成的两份文档天然兼容。真正的接口是稳定的制品标识、明确的字段语义、可验证的签名以及可被消费端找到的存储位置。

这也是我不建议一开始就追求“所有工具都接入”的原因。先确定团队要保护的制品类型，再决定清单格式、证明格式、签名和分发方式。格式转换可以解决表示差异，却不能补回生成阶段没有记录的输入、身份或时间信息。CNCF TAG Security 的资料也强调，构建时生成的 SBOM 因为能够看到实际依赖和构建上下文，通常比事后扫描更接近该次构建的事实。

把协同关系落到一次制品交付

如果只看标准名词，协同容易停留在架构图上。我会把一次发布拆成几个必须留证的对象：源代码提交、依赖解析结果、构建制品、SBOM 文档、Provenance 证明和签名身份。它们不要求存放在同一个系统里，但必须能通过制品摘要或其他稳定关联查到彼此。

1. 构建阶段：尽量在构建上下文中生成 SBOM，同时采集输入、输出、构建器身份和时间等 provenance 字段。
2. 签名阶段：让声明和交付对象都落在明确的身份边界内，消费端能知道谁签署、签署了什么以及签名如何验证。
3. 分发阶段：把制品、SBOM 和来源证明放到消费者可访问的仓库或元数据存储中，并保持版本、时间戳和不可变记录。
4. 消费阶段：把“组件是否符合要求”和“构建是否来自允许的来源”拆成两个条件，再用同一制品摘要汇合策略结果。

这个拆分还有一个好处：当新的漏洞信息出现时，SBOM 可以帮助定位受影响组件；当构建器或发布身份发生异常时，provenance 可以帮助回溯来源。两条复查路径最终都回到制品对象，而不是在脱离上下文的文档集合里猜测。

安全策略要同时看内容、来源和身份

单纯要求“必须有 SBOM”还不够，因为有清单不代表清单完整、来源可信或当前制品未被替换。更稳妥的策略可以分成三层：先检查 SBOM 是否与制品摘要关联，再检查 provenance 的构建器、输入和输出是否符合组织要求，最后验证签名身份和存储记录是否可追溯。

策略也不应该把所有失败都归为同一种风险。例如缺少 SBOM 可能是可见性问题，构建器不在允许列表可能是来源问题，签名无法验证则是信任链问题。不同证据缺失要映射到不同处置动作，才不会为了“门禁通过”而把元数据补成形式文件。

需要特别注意的是，SBOM 是某次构建的快照，漏洞信息还会随时间变化；来源证明能说明构建事实，也不等于证明代码本身没有漏洞。CNCF TAG Security 将 SBOM、attestation、VEX、签名和策略放在同一套供应链安全语境中，原因就在于它们解决的是相互连接但不相同的风险。

我会留下的审计记录和复查边界

最后我会把以下记录作为发布包的一部分：制品摘要、SBOM 格式与生成时间、provenance 格式与生成时间、签名身份、元数据存储位置、策略版本以及后续复查结果。记录时间不是装饰字段，它能帮助区分“这份清单对应哪次构建”和“后来发现的漏洞是否需要重新判断”。

从标准和基金会资料的共同方向看，SBOM 与 provenance 的协同并不是再创建一份更大的万能文档，而是让不同类型的事实围绕同一个制品形成可验证的关系。对于团队来说，最小可行路径是先选定制品标识和元数据存储，再逐步补齐构建身份、签名、策略和持续复查。

SBOM 能不能代替构建来源证明？

不能。SBOM 主要描述组件组成，不能单独证明源代码从哪里来、由哪个构建器生成，或构建参数是否符合策略。

provenance 能不能代替 SBOM？

也不能。来源证明可以说明输入、构建和输出关系，但不一定包含足够细的组件清单，不能代替依赖查询和漏洞影响分析。

两份文档一定要使用同一种格式吗？

不一定。更重要的是制品摘要、字段语义、签名身份和分发位置能够稳定关联；格式统一可以降低工具适配成本，但不能替代生成阶段的事实采集。

事后扫描生成的 SBOM 还有价值吗？

有价值，尤其适合遗留制品和消费侧复查，但它可能看不到构建工具链、手工安装内容或构建上下文。能在构建阶段采集时，应优先保留构建时证据，再用扫描作为补充。

官方资料：https://contribute.cncf.io/community/tcgs/software-supply-chain-security/；https://slsa.dev/spec/v1.0/provenance；https://in-toto.io/。