10.3 制品签名与发布验证：从身份到准入策略

数字签名证明某个私钥持有者批准了一组字节。供应链系统还要回答：这个密钥代表谁、签署的是什么 digest、签署时身份是否有效、声明是否进入透明日志，以及当前环境为何信任它。

Keyless 签名缩短长期密钥暴露

Sigstore 风格流程简化为：

CI workload OIDC identity
  → CA issues short-lived signing certificate
  → sign artifact digest / attestation
  → record evidence in transparency log

Keyless 不等于没有密钥，而是签名密钥短期生成，身份通过 OIDC claim 绑定，证据可由透明日志审计。验证策略必须限制 issuer、repository、workflow、ref/environment 等 claim；只检查“证书由公共 CA 签发”过宽。

私有离线发布、固件和长期验证可能仍需要传统 HSM key。选择取决于在线身份、验证期限、撤销和灾难恢复，而不是统一追求 keyless。

Tag、Digest 与签名对象要一致

Mutable tag 可被重新指向：

registry/app:1.4 → sha256:AAA today
registry/app:1.4 → sha256:BBB tomorrow

签名、SBOM、provenance 和部署都应绑定 digest。用户界面可以显示 semver/tag，但策略决策使用不可变 digest，并验证所有证据 subject 相同。

透明日志提供可发现性，不决定信任

Append-only log 让签名事件更难被静默删除或回填，便于审计某身份签过哪些制品。日志中存在一条有效记录并不说明签名者被你的组织授权，也不说明制品安全。

离线验证要保存需要的 inclusion proof、certificate chain 和时间证据，明确透明日志不可用时是使用已缓存证据、暂缓发布还是 break-glass。

准入验证在每个信任边界执行

开发 registry → 发布 registry：验证构建和来源
发布 registry → staging：验证签名、SBOM、策略
staging → production：验证同一 digest 与环境审批
cluster admission：拒绝未验证 digest 与不允许配置
runtime：检测运行 digest 与批准记录漂移

只在 CI 签名但允许管理员直接部署任意镜像，控制链仍有缺口。Admission controller 自身要高可用、版本化和监控；fail-open 只应是明确、受限的可用性决策。

Policy 不是“必须有签名”这么简单：

trusted identity signed this exact digest
AND approved builder issued SLSA provenance
AND source revision satisfies branch/review policy
AND no expired exception blocks release
AND artifact configuration meets environment policy

TUF 保护更新分发

签名制品之外，更新系统还要防 rollback、freeze、mix-and-match 与 signing key compromise。The Update Framework（TUF）通过 root、targets、snapshot、timestamp 等分离角色和阈值签名，限制单个 key 失陷影响。

离线 root、在线短期 timestamp、版本单调与客户端过期检查共同工作。自制“下载文件 + 一个长期签名 key”通常缺少安全轮换与回滚保护。

供应链事件从图查询开始

当某 builder、dependency 或 signing identity 失陷：

1. 查询受影响 source revision、build run、artifact digest 和部署；
2. 暂停对应 identity/builder 的新发布；
3. 保存日志、provenance、SBOM 与 runner 证据；
4. 在干净平台从受信 revision 重建并比较；
5. 轮换凭据、修复平台、重签并分批替换；
6. 发布 VEX/advisory 与客户范围；
7. 更新验证策略，防止旧制品重新进入。

没有资产、SBOM 和 provenance 的统一查询，响应团队只能按标签猜测影响范围。

本卷收口清单

• 依赖是否固定来源、版本和完整性，并能持续更新？
• 最终制品是否生成并验证高质量 SBOM？
• Provenance 是否由受信平台产生且不能被 job 伪造？
• SLSA 声明是否引用当前 1.2 track，而非旧 L1–L4？
• 签名、SBOM、provenance 和部署是否绑定同一 digest？
• 每个发布边界是否验证身份、builder、source 与环境策略？
• Signing/build 平台失陷时能否查清、撤销、重建和阻止回滚？

参考资料

• Sigstore, Documentation
• The Update Framework, Specification
• in-toto, Framework
• SLSA, Verification