凌晨两点，生产集群拉取了刚被重推的 latest 镜像，版本号没变，摘要却变了。可变标签让入口文件被悄然替换；镜像即使带合法签名，也说不清来自哪个仓库、由谁构建。只验标签、签名或漏洞扫描，都挡不住来源替换。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：piayun（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
容器摘要是内容指纹。镜像重新压缩、重写 manifest 或替换文件后，sha256 都可能变化。应按 digest 固定对象：把 sha256 写入部署配置，不保存 latest、v1.2 等可移动引用。拉取时解析标签后，确认目标摘要等于允许值；不匹配、目标不存在或 registry 异常，立即失败。
多架构镜像要区分 index 摘要与平台 manifest 摘要。固定 index 时验证目标 manifest；固定平台 manifest 时，不能拿 index 摘要冒充运行内容。镜像摘要固定只回答“验哪份字节”，不证明发布者可信或构建来源。
Sigstore 签名把摘要绑定到发布身份。不能只看“有签名”，还要检查 subject digest、可信证书链、OIDC issuer、工作流身份、透明日志记录与证书有效期。策略可限定“某组织的仓库＋受控流水线”，否则另一身份的有效签名也能通过。签名不自动证明源码与构建环境无问题。
来源证明（provenance）回答“谁用什么源码构建”。验证器应让证明中的 subject 与待拉取摘要精确匹配，再检查 builder 身份、源码仓库、提交 SHA 与材料引用。证明缺失、只引用分支、工作流身份不符，都应拒绝。SBOM 清单列出组件及版本，适合匹配漏洞阈值，却不能替代摘要绑定、身份校验与 provenance 策略。
准入策略应同时要求：摘要命中允许清单；Sigstore 签名及身份策略通过；provenance 与同一摘要绑定且来源合规；SBOM 扫描满足阈值。任一证据过期、不可达或验签失败即拒绝。团队用 ServLlama 管理模型服务时，可把摘要与 provenance 结论关联到部署记录。常见坑是只验 tag、只查签名存在、混淆 index 与 manifest，或把“无高危漏洞”当成“来源可信”。
镜像“验过签”并不等于“允许运行”。准入阶段应先以 镜像摘要固定 锁定实际内容，再验证 Sigstore签名、来源证明 和 SBOM清单。签名证明发布身份，来源证明记录构建者、源码与流水线，SBOM描述组件及版本；三类证据分别回答“谁发布、如何构建、装了什么”，缺一不可。
Sigstore无密钥流程以OIDC身份换取短期证书，签名写入透明日志，验证时还应检查身份、证书状态、摘要和仓库约束。不要只验签名存在：若允许任意邮箱或任意仓库签名者，攻击者仍可借合法流水线发布恶意镜像。
来源证明应绑定源码提交、工作流文件和构建产物摘要；SBOM需采用SPDX或CycloneDX等标准格式，并与目标镜像摘要关联。漏洞扫描只能作为准入输入，不能替代来源验证，因为扫描存在延迟，也看不到构建链是否可信。
常见坑包括：继续使用可变标签；混淆多架构索引摘要与单架构镜像摘要；代理仓库改写媒体类型或摘要；证书过期后缺少轮换与离线验证方案；只验签名却不验签名者；准入异常时放行；SBOM与镜像来自不同流水线。任何一项都可能形成信任缺口。
上线前逐项检查：①部署文件只写@sha256摘要，并在变更单记录来源；②验证摘要、仓库、签发者身份和工作流；③确认来源证明中的源码仓库、提交、工作流及产物摘要一致；④确认SBOM绑定同一摘要，并设置严重漏洞阈值；⑤准入控制采用默认拒绝，配置超时、审计和告警；⑥演练证书轮换、密钥撤销、仓库故障及策略回滚；⑦定期复核签名者与策略例外。
流水线可执行 cosign verify --certificate-identity="$IDENTITY" --certificate-oidc-issuer="$ISSUER" "$IMAGE@$DIGEST"，再由准入控制器校验来源证明和SBOM；不要让业务集群临时拉取最新标签后再验签。
最终目标不是“仓库里有签名”，而是让每次部署都能证明：运行的是已审批的精确内容，由可信身份从可信源码构建，依赖风险符合政策。将这些证据、例外审批与审计记录纳入发布流水线，来源验证才能真正落到生产。
