为发布产物附加构建来源证明

概述

构建来源证明回答一个范围很窄的问题：哪个工作流、哪个仓库、哪个提交产生了这个确切摘要？它不扫描镜像，也不评价代码质量。但这个保证足以阻断一类供应链攻击：攻击者推送一个看起来像正式发布、实际在别处构建的镜像。

步骤

1. 按摘要构建并推送镜像，然后在同一工作流中为该摘要生成证明：

permissions:
  contents: read
  id-token: write
  attestations: write
  packages: write
steps:
  - uses: actions/checkout@v4
  - uses: docker/build-push-action@v6
    id: build
    with:
      push: true
      tags: ghcr.io/acme/payments-api:${{ github.sha }}
  - uses: actions/attest-build-provenance@v2
    with:
      subject-name: ghcr.io/acme/payments-api
      subject-digest: ${{ steps.build.outputs.digest }}
      push-to-registry: true

2. 部署前执行 gh attestation verify oci://ghcr.io/acme/payments-api:latest --owner acme。
3. 把验证写入部署任务，失败即停止，不允许跳过。
4. 用未经过工作流构建的镜像做负向测试，确认验证返回非零。

验证

预期验证成功时输出工作流、仓库和提交信息；未附加证明的镜像返回非零并提示 no attestations found。部署记录中应保存已验证的镜像摘要，跨环境晋级时传递摘要而不是重新构建。

注意事项

• 来源证明只说明构建位置与方式，不代表代码没有漏洞。
• 标签可变而摘要不可变，必须对摘要做证明和部署。
• 第三方 Action 应固定到提交 SHA，主分支需保护，否则工作流本身可被篡改。
• 验证依赖 GitHub API 与 OIDC 身份，离线环境需提前设计替代信任链。