关于本指南
本指南描述了可对构建系统安全性产生最高影响的更改。每个章节概述了您可以在流程中进行的改进措施，以提升安全性。影响最大的更改放在最前面。
风险是什么？
对软件供应链的某些攻击直接针对构建系统。如果攻击者能够修改构建过程，他们可以在无需入侵个人账户或代码的情况下利用您的系统。重要的是要确保既保护个人账户和代码，也不忘保护构建系统。
保护您的构建系统
构建系统应具备多项安全能力
-
构建步骤应清晰且可重复。
-
您应准确了解构建过程期间运行了哪些内容。
-
每次构建都应在全新的环境中开始，以防止受损的构建持续影响后续构建。
GitHub Actions 可以帮助您满足这些能力。构建指令存储在仓库中，与代码一起。您可以选择构建运行的环境，包括 Windows、macOS、Linux，或自行托管的运行器。每次构建都会使用全新的运行器镜像，使攻击难以在构建环境中持久化。
除了安全优势外，GitHub Actions 还能让您手动、定期或在仓库的 git 事件触发下进行构建，实现频繁且快速的构建。
GitHub Actions 是一个庞大的主题，但入门的好地方是 了解 GitHub Actions，以及 GitHub Actions 的工作流语法，和 触发工作流。
为您的构建生成构件证明
制品证明使您能够为所构建的软件创建不可伪造的来源和完整性保证。随后，使用您软件的用户可以验证软件的构建位置和方式。
当您为软件生成制品证明时，您会创建加密签名的声明，以确立构建的来源，并包含以下信息
- 与制品关联的工作流链接
- 制品对应的仓库、组织、环境、提交 SHA 以及触发事件
- 用于建立来源的 OIDC 令牌中的其他信息。欲了解更多，请参阅 OpenID Connect（开放式身份认证）。
您还可以生成包含关联软件物料清单（SBOM）的制品证明。将构建与所使用的开源依赖列表关联，可提供透明度并帮助使用者遵守数据保护标准。
构件证明包括对已构建构件的签名以及指向源代码和构建指令的链接。如果您使用构件证明对构建进行签名，则无需自行管理签名密钥材料。GitHub 通过我们运行的签名权威为您处理这些工作。
欲了解更多信息，请参阅 使用构件证明来建立构建的来源。
对构建进行签名
在确保构建过程安全后，您需要防止他人篡改构建的最终产物。一个很好的方法是对构建进行签名。对外发布软件时，通常使用公钥/私钥密码学对。您使用私钥对构建进行签名，并公开您的公钥，以便软件使用者在使用前验证签名。如果构建的字节被修改，签名将无法验证。
具体的签名方式取决于您所编写的代码类型以及用户群体。通常很难知道如何安全地存储私钥。一个基本的做法是使用 GitHub Actions 加密的 secret，但您需要谨慎限制对这些工作流的访问权限。如果您的私钥存放在可通过公共互联网访问的其他系统（如 Microsoft Azure 或 HashiCorp Vault），可以采用 OpenID Connect 进行身份验证，这样无需在系统间共享 secret。如果私钥只能在私有网络中访问，则可以使用自托管的 GitHub Actions 运行器。
欲了解更多信息，请参阅 在 GitHub Actions 中使用 secret、OpenID Connect，以及 自托管运行器。
使用不可变发行版
如果您在构建系统中使用其他项目的发行资产，或为自己的工作创建发行版，应通过确保这些发行版是不可变的来降低安全风险，即发布后不可更改。不可变发行版有助于防止供应链攻击和意外的破坏性变更。欲了解更多信息，请参阅 不可变发行版。
加强 GitHub Actions 的安全性
还有许多进一步的措施可以进一步保护 GitHub Actions。尤其是在评估第三方工作流时要谨慎，并考虑使用 CODEOWNERS 限制谁可以更改您的工作流。