CNCF供应链签名在CI产物验收中的接入方案

我第一次把“镜像已经推到仓库”当成发布前置条件时，真正容易漏掉的不是构建，而是验收对象已经变了：流水线前面用的是 tag，后面的扫描器却可能拉到另一个 digest。比较稳妥的接入方式是把制品摘要作为主键，再把签名者身份、OIDC issuer、SBOM/来源证明和最终验收结果绑定到同一个摘要上。

官方入口：https://docs.sigstore.dev/

Cosign 项目地址：https://github.com/sigstore/cosign

先把“验收通过”拆成四个可检查条件

CNCF 供应链安全实践把签名、attestation 和后续验证放在制品生命周期的多个阶段。落到 CI 里，可以先固定四个条件：第一，构建输出的 digest 与待发布对象一致；第二，签名来自预期的工作流身份；第三，签名使用了预期的 OIDC issuer；第四，SBOM 或来源证明的内容满足组织策略。这样做的好处是，验收失败时能知道是“对象变了”还是“身份不对”，而不是只看到一个笼统的签名错误。

构建完成后按 digest 签名，不要按可变 tag 签名

Cosign 文档明确建议以 digest 而不是 :latest 作为签名输入。下面的片段是假定构建步骤已经输出了镜像摘要；它展示接入边界，不把示例执行结果冒充为本机运行证据。GitHub Actions 中需要给签名任务配置 id-token: write，否则无法取得用于 keyless 签名的 OIDC 身份令牌。

name: sign-and-accept

on:
  push:
    branches: [ main ]

permissions:
  contents: read
  packages: write
  id-token: write # 中文说明：允许工作流向 Sigstore 请求短期身份

jobs:
  sign:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false # 中文说明：避免把 CI 凭据留在 git 配置中

      - name: Install Cosign
        uses: sigstore/cosign-installer@v4.0.0

      - name: Sign immutable image
        env:
          IMAGE_DIGEST: ghcr.io/example/demo@sha256:REPLACE_WITH_BUILD_DIGEST
        run: |
          # 中文说明：签名输入必须是构建后锁定的 digest，不能重新解析 latest
          cosign sign --yes "$IMAGE_DIGEST"

      - name: Attach SBOM
        env:
          IMAGE_DIGEST: ghcr.io/example/demo@sha256:REPLACE_WITH_BUILD_DIGEST
        run: |
          # 中文说明：把 SBOM 绑定到同一个 digest，供后续验收策略读取
          cosign attest --yes \
            --predicate ./sbom.spdx.json \
            --type spdxjson \
            "$IMAGE_DIGEST"

这里的 keyless 不是“没有信任关系”，而是把短期证书、工作流身份和透明日志组合起来。签名服务仍需要先约束哪些工作流可以发布，仓库权限也应与签名权限分开。

把签名验证变成发布前的硬门禁

只执行 cosign verify 还不够。验收端至少要传入预期的证书身份和 issuer，并把镜像地址写成同一个 digest。工作流身份可以精确到仓库、工作流文件和分支；如果组织确实需要多条发布流水线，再使用受控的正则，而不是放宽为任意身份。

#!/usr/bin/env bash
set -euo pipefail

# 中文说明：所有变量都来自已审核的构建输出或仓库级配置
IMAGE_DIGEST="ghcr.io/example/demo@sha256:REPLACE_WITH_BUILD_DIGEST"
EXPECTED_IDENTITY="https://github.com/ORG/REPO/.github/workflows/release.yml@refs/heads/main"
EXPECTED_ISSUER="https://token.actions.githubusercontent.com"

# 中文说明：失败立即退出，防止未验收的摘要继续流向发布步骤
cosign verify "$IMAGE_DIGEST" \
  --certificate-identity "$EXPECTED_IDENTITY" \
  --certificate-oidc-issuer "$EXPECTED_ISSUER"

# 中文说明：只有上一步成功，才允许把摘要交给部署或发布系统
echo "signature and identity accepted for $IMAGE_DIGEST"

验证结果证明的是“这个摘要有符合条件的签名”，不是镜像已经安全无漏洞。后面仍可接漏洞扫描、许可证检查和部署策略；这些检查通过后，再由验收服务写入一个独立的“允许发布”标记，避免把构建签名误当成最终放行签名。

用 attestation 补上来源和 SBOM 的验收证据

镜像签名解决的是对象完整性与签名者约束，来源证明和 SBOM 还需要单独验证。实践中可以把 attestation 的 predicate 类型、构建工作流、源码提交和扫描结论列入策略。尤其要注意：attestation 本身也应验证签名，内容还要对照组织策略，不能因为它存在于仓库旁边就默认可信。

我更建议把策略写成一张小表，而不是散落在多个脚本里：

发布前的验收顺序和边界

一个容易维护的顺序是：构建并推送 → 固定 digest → 签名 → 附加 SBOM/来源证明 → 验证身份与 digest → 执行安全和合规检查 → 生成验收标记 → 部署。任何一步拿到的引用都应继续传递同一个 digest。若使用 air-gapped 环境，则还要提前准备镜像、签名和 Sigstore bundle，并维护可信根的更新机制；离线验证不是简单断网后再跑一次命令。

常见问题

为什么已经签名还要验证 digest？

签名覆盖的是具体制品摘要。若验收和部署使用不同 digest，即使两者都带有合法签名，也不能证明部署对象就是验收对象。

keyless 签名是否意味着不需要权限管理？

不是。它减少了长期私钥的保管负担，但仍要限制哪些 CI 工作流能获取 OIDC 身份、哪些仓库能推送，以及验证端允许哪些身份。

SBOM attestation 能代替漏洞扫描吗？

不能。attestation 记录来源或元数据，漏洞扫描回答组件是否命中风险；两者都应绑定当前 digest，并分别纳入验收策略。

如果只准备做一件事，先把 tag 改成 digest 传递，再把身份和 issuer 写进验证命令。这样供应链签名才真正从“构建时动作”变成“发布前可复核的验收条件”。