开源项目推荐｜Sigstore Cosign：给 AI 服务镜像和模型产物加可验证签名

开源项目推荐｜Sigstore Cosign：给 AI 服务镜像和模型产物加可验证签名

AI 服务会拉取基础镜像、推理运行时、模型权重和插件。扫描能发现已知漏洞，却不能回答制品是否来自预期流水线。Sigstore 的 Cosign 签名并验证制品，Fulcio 将短期证书绑定 OIDC 身份，Rekor 记录签名事件。

签名验证回答什么

校验摘要只能确认文件与某个 hash 一致；签名进一步证明拥有对应身份或密钥的主体认可了该摘要。验证策略还要指定允许的签名身份和 OIDC issuer，否则“签名有效”可能只是陌生账号给恶意镜像签了名。

签名不证明软件没有漏洞、模型没有后门或数据来源合规。它建立的是来源与完整性证据。安全发布仍需代码审查、镜像扫描、SBOM、测试和运行时限制。Cosign 与 Trivy 是互补关系。

Keyless 不等于没有信任根

Cosign 的 keyless 流程使用临时密钥，并通过 OIDC 身份向 Fulcio 申请短期证书；签名记录进入 Rekor。团队不必分发长期私钥，但仍要信任身份提供商、Fulcio、Rekor 和 Sigstore 信任根，并保护 CI 身份。

验证要固定工作流身份与 issuer，只接受受控仓库和环境。若攻击者控制可签名的 CI，即使密码学验证成功，恶意制品仍会被认可，因此发布权限和 OIDC 最小权限同样重要。

镜像必须按 digest 部署

标签可以移动，latest 随时可能指向不同镜像。签名与验证围绕不可变 digest 建立，部署也应引用 digest。若生产继续按浮动标签拉取，只在构建阶段验证一次仍不安全。

Kubernetes 环境可以在准入阶段拒绝没有合格签名的镜像。策略需要规定受信身份、仓库范围、签名数量和例外期限。紧急绕过必须可审计并自动过期，不能留下永久的 skip verify 开关。

模型权重和配置同样需要签名

Cosign 也可对普通 blob 签名并生成验证 bundle。模型权重、量化文件、Prompt、MCP Server 包和评测集都能计算摘要并关联发布版本。加载前应验证 bundle、身份、issuer 与摘要。

Attestation 让发布证据可验证

除了“谁签了这个镜像”，团队还想确认它通过了哪些测试、使用什么源代码构建、包含什么 SBOM。Cosign 可以签署 attestation，验证端根据策略检查声明。声明必须由可信流水线产生；把未经验证的自报 JSON 签起来，并不会自动让内容可信。

透明日志需要被监控

Rekor 是追加式、可验证的签名透明日志，使签名事件能够被发现和审计。透明并不等于自动阻止身份被盗用；项目方需要监控自己的身份是否出现意外签名，并为异常准备撤销信任、停止部署和重新发布流程。

在 AnyAIS 交付链中落地

AnyAIS 统一模型与工具调用，平台侧可把服务镜像 digest、模型制品版本和部署记录关联。构建完成后由 CI 使用工作负载身份签名，发布环节验证身份和 attestation，运行环境只接受通过策略的摘要。这样一次异常模型响应可以追溯到具体代码、镜像与制品。

独立模型可辅助审阅发布声明和策略差异，但身份、摘要和准入结果必须由确定性工具验证。关键不是“有个签名”，而是身份、不可变制品、策略与审计闭环同时成立。

参考资料

• [Sigstore 工作原理](https://docs.sigstore.dev/)
• [Cosign 容器签名](https://docs.sigstore.dev/cosign/signing/signing_with_containers/)
• [Cosign 验证签名](https://docs.sigstore.dev/cosign/verifying/verify/)
• [Sigstore 安全模型](https://docs.sigstore.dev/about/security/)

如果你在 AnyAIS 周边部署自建模型或 MCP 服务，可以先为 CI 镜像建立 keyless 签名与部署前验证，再逐步覆盖模型权重和发布声明。