| 内容骨架 | 构建者身份、源码仓库与提交、构建命令/工作流、产物摘要 |
|---|---|
| 载体 | 签名后作为 OCI 制品附着镜像，或平台 attestation 能力 |
| 消费 | 验证签名 → 校验来源约束 → 才允许部署 |
验证思路（cosign）
验证思路（cosign）
cosign verify-attestation --type slsaprovenance \
registry.example.com/app@sha256:<digest>证明链的强度取决于验证点位：在准入控制处校验，效果直接。
构建证明（Attestation）实践
把「谁、用什么、怎么构建的」写成可验证声明（in-toto/证明规范），随制品发布并可被部署侧校验。
易错点
- 证明与制品分离存储：对应关系靠人工维护，附着到制品本身更稳
- 验证策略在平台间不一致：写清信任根与规则并纳入代码评审
数据来源与参考
- in-toto 规范（in-toto.io）
- Sigstore 文档