保护构建系统的最佳实践

有关如何保护供应链末端（您用于构建和分发构件的系统）的指南。

本文内容

关于本指南

本指南描述了您可以进行的提高构建系统安全性的影响最大的更改。每个部分概述了您可以对流程进行的更改以提高安全性。影响最大的更改将首先列出。

风险是什么？

某些针对软件供应链的攻击直接针对构建系统。如果攻击者可以修改构建过程，则他们可以利用您的系统，而无需花费精力来入侵个人帐户或代码。务必确保您不要忘记保护构建系统以及个人帐户和代码。

保护您的构建系统

构建系统应该具有一些安全功能

  1. 构建步骤应清晰且可重复。

  2. 您应该确切地知道在构建过程中运行的内容。

  3. 每次构建都应在一个新的环境中启动，因此受感染的构建不会持续存在以影响未来的构建。

GitHub Actions 可以帮助您满足这些功能。构建说明存储在您的存储库中，与您的代码一起。您可以选择构建运行的环境，包括 Windows、Mac、Linux 或您自己托管的运行器。每次构建都从一个新的运行器映像开始，这使得攻击难以持续存在于您的构建环境中。

除了安全优势外，GitHub Actions 还允许您手动、定期或在存储库中的 Git 事件上触发构建，以实现频繁且快速的构建。

GitHub Actions 是一个很大的话题，但一个好的起点是“了解 GitHub Actions”以及“GitHub Actions 的工作流语法”和“触发工作流”。

为您的构建生成构件证明

构件证明使您能够为构建的软件创建不可伪造的来源和完整性保证。反过来，使用您软件的人员可以验证您的软件在哪里以及如何构建。

当您使用软件生成构件证明时，您会创建加密签名的声明，这些声明建立了构建的来源并包含以下信息

  • 与构件关联的工作流的链接。
  • 构件的存储库、组织、环境、提交 SHA 和触发事件。
  • 用于建立来源的 OIDC 令牌中的其他信息。有关更多信息，请参阅“关于使用 OpenID Connect 增强安全性”。

您还可以生成包含关联软件物料清单 (SBOM) 的构件证明。将构建与其中使用的开源依赖项列表相关联，可以提高透明度并使用户能够遵守数据保护标准。

构件证明包括对构建构件的签名，以及对源代码和构建说明的链接。如果您使用构件证明签署构建，则不必管理自己的签名密钥材料。GitHub 为您处理了这一点，并使用我们运营的签名颁发机构。

有关更多信息，请参阅“使用构件证明为构建建立来源”。

签署您的构建

在构建过程安全之后，您希望防止有人篡改构建过程的最终结果。一个很好的方法是签署您的构建。在公开分发软件时，这通常使用公钥/私钥加密密钥对完成。您使用私钥签署构建，并发布您的公钥，以便您的软件用户在使用构建之前验证构建上的签名。如果构建的字节被修改，则签名将无法验证。

如何对构建进行签名将取决于您编写的代码类型以及您的用户是谁。通常，很难知道如何安全地存储私钥。这里一个基本的选择是使用 GitHub Actions 加密密钥，但您需要小心限制谁可以访问这些 GitHub Actions 工作流。如果您的私钥存储在可以通过公共互联网访问的另一个系统中（例如 Microsoft Azure 或 HashiCorp Vault），则更高级的选择是使用 OpenID Connect 进行身份验证，这样您就不必在系统之间共享密钥。如果您的私钥只能从私有网络访问，则另一个选择是为 GitHub Actions 使用自托管运行器。

有关更多信息，请参阅“在 GitHub Actions 中使用密钥”、“关于使用 OpenID Connect 加固安全”和“关于自托管运行器”。

增强 GitHub Actions 的安全性

您可以采取许多其他步骤来进一步增强 GitHub Actions 的安全性。特别是，在评估第三方工作流时要小心，并考虑使用CODEOWNERS来限制谁可以更改您的工作流。

有关更多信息，请参阅“GitHub Actions 的安全加固”和“使用 GitHub 的安全功能来保护您对 GitHub Actions 的使用”。

后续步骤