如何验证 GitHub Actions 产物是由您构建的，而非攻击者

供应链攻击早已从理论变成了残酷的现实。假设用户从 GitHub 的 Releases 部分下载了一个预构建的二进制文件。他们如何验证该文件实际上是由 CI 服务器从特定提交的源代码构建的，而不是由获得开发者账户访问权限的黑客上传的？

为了解决这个问题，GitHub 推出了一个特殊的 action actions/attest-build-provenance。让我们深入了解它的工作原理、为什么需要 Sigstore 签名，以及在创建新管道时为什么需要使用稍微不同的工具。

在哪里绑定签名

来源签名的本质相当简单。每个完成的文件都需要一份数字护照。这份文档确认：具有特定哈希值的产物是在特定的工作流中、在特定的仓库中、在特定的提交上构建的。

该工具根据 in-toto 标准和 SLSA（Supply-chain Levels for Software Artifacts，软件制品供应链级别）规范生成清单。然后最有趣的部分发生了：对这份清单进行签名。

Sigstore 架构避免了强制开发者生成长期存在的 PGP 密钥并将其存储在仓库密钥中的麻烦。该 action 从 GitHub Actions 请求一个临时的 OIDC 令牌，并将其交换为一个短期有效的签名证书。

对于公开仓库，签名通过公共 Sigstore 服务生成，相关数据最终进入透明的 Rekor 日志。如果仓库是私有的，GitHub 使用其自己的私有 Sigstore 实例（此功能在 Enterprise Cloud 计划中可用）。

如果你打开该项目的官方仓库，你会在 README 的开头看到一个重要的说明。

从第四版开始，actions/attest-build-provenance变成了基础 action actions/attest的一个简单包装器。GitHub 开发者明确表示：如果你在维护旧的管道，可以保持原样。但对于新项目，你应该立即从 actions/attest开始。

为什么 GitHub 要添加额外的一层？最初，团队在构建一个仅用于构建来源的窄专业工具。后来，出现了对二进制文件、SBOM（依赖列表）或漏洞扫描结果进行签名的需求。这样就产生了更通用的 actions/attest，而旧 action 作为同义词被弃用。

在旧版本的 action 中，.github/workflows/build.yml中的逻辑被压缩到产物构建步骤之后的几行代码。

这里重要的是权限 id-token: write和 attestations: write。没有第一个选项，工作流将无法通过 Sigstore 获取用于无密码签名的 OIDC 令牌；没有第二个选项，它将不会把结果上传到 GitHub Attestations API。

在证明创建并绑定到仓库后，任何用户或验证脚本都可以在本地检查该文件。为此，使用官方的 GitHub CLI 工具。

验证命令如下：

gh attestation verify app.sh --owner my-organization

如果文件没有被修改且是在指定组织中构建的，CLI 将输出关于提交和签名证书的信息。但是，如果文件即使被最小程度地修改，验证也会失败并报错。

如果你在开发开源库或 CLI 工具，生成证明可以让用户轻松验证你发布版本的安全性。

另一方面，如果你有一个没有严格供应链安全要求的小型内部项目，在 CI 中添加额外步骤可能就过度了。

对于新的工作流，直接使用 actions/attest而不是 actions/attest-build-provenance。核心功能将保持不变，但你将使用一个没有弃用包装器的最新工具。