10.2 构建 Provenance 与 SLSA 1.2

Provenance 描述制品怎样产生：哪个 builder、使用什么 build definition、哪些顶层输入、输出 digest 是什么。它与 SBOM 互补：SBOM 是“里面有什么”，provenance 是“从哪里、怎样构建”。

Attestation 把声明绑定到主体

subject: artifact sha256:abc...
predicateType: SLSA provenance
predicate:
  builder identity
  build type and parameters
  source revision and dependencies
  invocation/environment metadata
signature / transparency evidence

消费者必须验证签名主体和声明内容，而不是只确认“有一个 attestation”。攻击者给恶意制品生成自己的合法签名毫无困难，关键是策略是否信任这个 builder 为这个 repository/build type 生产该制品。

SLSA 1.2 采用多个 Track

旧版资料常写单一 SLSA L1–L4；当前正式版 1.2 已拆成独立 tracks。

Build track：

L0：无保证
L1：存在 provenance
L2：由 hosted build platform 生成并签名 provenance
L3：hardened build platform，进一步抵抗构建中篡改

Source track 关注源码 revision 的产生与控制，包含版本控制、历史/provenance、持续技术控制和双人评审等渐进级别。一个 artifact 的 Build level 不会自动证明依赖同等级，也不自动证明源码没有恶意逻辑。

不要继续引用旧的“Build L4 必须可复现/两人评审”作为现行 1.2 要求；这些性质仍有价值，但应按当前 track 和组织策略单独表达。

Builder 是信任根的一部分

如果项目自己的构建脚本能伪造 provenance signing key，证明就失去意义。高等级构建要求 provenance 由平台控制面产生，build job 无法任意伪造，并在不同租户/构建间隔离。

Self-hosted runner 是否满足要求取决于谁生成 provenance、谁持有签名能力，以及 runner 是否能影响这些声明。不能因为界面显示“hosted CI”就自动宣称某级别。

构建平台应：

• 临时、隔离、任务后销毁；
• 固定并验证 build image 与工具链；
• 对网络依赖、缓存和 secret 有明确策略；
• 平台生成不可伪造 provenance；
• 将 source revision 与 build definition 固定；
• 记录平台与策略版本并支持审计。

Hermetic 与 Reproducible 回答不同问题

Hermetic build 的输入全部声明并受控，构建时不从未知网络/主机状态获取材料。Reproducible build 指相同输入可独立得到相同输出。前者改善输入完整性，后者提供交叉验证能力；可复现不保证源码无恶意，hermetic 也不自动得到字节一致。

时间戳、路径、随机种子、压缩顺序和工具链差异都会破坏可复现。应从关键制品开始消除非确定性，并由独立 builder 比较 digest。

消费端必须形成期望

验证策略示例：

artifact digest matches attestation subject
AND source repository == expected repo
AND source revision is protected and reviewed
AND builder identity in approved builders
AND build type/parameters match release workflow
AND provenance signature/transparency evidence valid

只存 provenance 而不在发布/部署时验证，事故时只能做取证，无法阻止篡改。下一课把签名、透明日志和 admission policy 接成真正的接受决策。

参考资料

• SLSA, Specification v1.2
• SLSA, Build Track
• SLSA, Source Requirements
• in-toto, Attestation Framework