保护 build

本文档介绍了保护 build 的最佳实践。 构建代码可以引用不同类型的操作，例如：

  • 优化或混淆代码：例如，Google 开源工具 Closure Compiler 可解析和分析 JavaScript、移除死代码，以及重写并最大限度地减少剩余代码。此外，还会检查代码中是否存在常见的 JavaScript 问题。
  • 将代码编译为中间代码：例如，您可以将 Java 代码编译到 Java 类文件 (.class) 中，或将 C++ 代码编译到对象文件 (.obj) 中。
  • 编译代码和链接，创建库或可执行文件：例如，将 C++ 代码编译到共享库 (.so) 或 Windows 可执行文件 (.exe) 中。
  • 将代码打包为可分发或可部署的格式：例如，从 Java 类文件创建 Java WAR (.war) 文件、创建 Docker 映像或创建 Python 构建的发行版 (.whl)。

根据您的所用编程语言和部署到的环境，您的 build 可能包含这些操作的不同组合。例如，build 可能会将 Python 代码打包到构建的发行版中，并将其上传到 Artifact Registry 或 PyPI 等工件存储区，以便您将其用作 Cloud Functions 中的依赖项。您还可以将 Python 代码容器化，并将容器映像部署到 Cloud Run 或 Google Kubernetes Engine。

本文档中的做法侧重于构建代码，用于打包代码或部署到运行时环境，而不是编译代码。

使用自动构建

自动构建或脚本构建在构建脚本或 build 配置中定义所有构建步骤，包括检索源代码的步骤和构建代码的步骤。唯一的手动命令（如果有）是运行构建的命令。

例如，构建脚本可以是：

  • Cloud Build cloudbuild.yaml。
  • 使用 make 工具运行的 Makefile。
  • YAML 格式的 GitHub Actions 工作流文件，存储在 .github/workflows/ 目录中。

自动构建可在构建步骤中提供一致性。但是，在一致且可信的环境中运行构建也很重要。

虽然本地 build 可能有助于进行调试，但从本地 build 发布软件可能会给构建流程带来许多安全问题、不一致性和低效问题。

  • 允许本地构建可以为带有恶意的攻击者提供一种方法来修改构建流程。
  • 开发者本地环境和开发者实践中的不一致会导致难以重现 build 和诊断 build 问题。

手动构建会利用计算、存储和网络等更多基础架构资源，降低该过程的效率。在 SLSA 框架的要求中，SLSA 级别 1 要求使用自动构建，而 SLSA 级别 2 要求使用构建服务（而非开发环境）。

Cloud Build 是 Google Cloud 上的代管式构建服务。它使用构建配置文件为 Cloud Build 提供构建步骤。您可以配置 build 以获取依赖项，运行单元测试、静态分析和集成测试，并使用构建工具（如 Docker、Gradle、Maven、Go 和 Python）创建工件。Cloud Build 与 Google Cloud 上的其他 CI/CD 服务（例如 Artifact Registry 和 Cloud Deploy）以及运行时环境（例如 GKE 和 Cloud Run）完全集成。它还支持与 GitHub 和 Bitbucket 等主要源代码管理系统的集成。

生成构建出处

build 出处是有关 build 的可验证数据的集合。

出处元数据包含已构建映像的摘要、输入源位置、构建工具链和构建时长等详细信息。

生成构建出处有助于您：

  • 验证构建工件是否是从可信的源代码位置以及由可信的构建系统创建的。
  • 找出从不受信任的来源位置或构建系统注入的代码。

您可以使用提醒和政策机制主动使用构建出处数据。例如，您可以创建仅允许部署从已验证来源构建的代码的政策。

对于 SLSA 级别 1，构建出处必须可供构建工件的使用者使用。对于 SLSA 级别 2，构建出处数据还必须：

  • 由构建服务生成或直接从构建服务读取。
  • 可由消费者验证，以确保真实性和完整性。为此，应使用由创建 build 源数据的服务生成的数字签名。

对于 SLSA 级别 3，出处内容还必须包括：

  • 构建定义的入口点。
  • 用户控制的所有构建参数。

Cloud Build 可以为提供 SLSA 级别 3 构建保证的容器映像生成构建来源。如需了解详情，请参阅查看构建出处。

使用临时构建环境

临时环境是专为单次构建调用持续有效的临时环境。构建后，环境将被擦除或删除。临时构建可确保构建服务和构建步骤在容器或虚拟机等临时环境中运行。构建服务不会重复使用现有的构建环境，而是会为每个构建预配一个新的环境，然后在构建流程完成后将其销毁。

临时环境可确保构建干净，因为先前 build 中没有会干扰构建流程的残留文件或环境设置。非临时环境为攻击者提供了注入恶意文件和内容的机会。临时环境还可以降低维护开销并减少构建环境中的不一致问题。

Cloud Build 会为每个构建设置一个新的虚拟机环境，并在构建后销毁该环境。

限制对构建服务的访问权限

遵循最小权限安全原则，向构建服务和构建资源授予所需的最低权限。您还应使用非真人身份运行 build，并代表该 build 与其他服务交互。

如果您使用 Cloud Build：

  • 向组织成员授予所需的最低权限。
  • 自定义代表 Cloud Build 执行操作的服务帐号的权限，以使其仅包含您的使用所需的权限。修改默认 Cloud Build 服务帐号的权限，或考虑改用自定义服务帐号。
  • 使用 Cloud Build 允许的集成组织政策来控制允许调用构建触发器的外部服务。

  • 使用 VPC Service Controls 将 Cloud Build 放置在服务边界内。边界允许边界内的 Google Cloud 服务之间免费通信，但会根据您指定的规则限制跨边界的通信。该边界还可以降低数据渗漏的风险。

    对于在专用池中运行的构建，Cloud Build 仅支持使用 VPC Service Controls。

保护凭据

构建通常包括与版本控制、工件存储区和部署环境等其他系统的连接。保护您在 build 中使用的凭据有助于防止对软件供应链中的系统进行未经授权的访问和数据渗漏。

避免将硬编码凭据直接存储在版本控制或 build 配置中。请改为将凭据存储在安全的密钥库中。

在 Google Cloud 中，Secret Manager 会安全地存储 API 密钥、密码和其他敏感数据。您可以将 Cloud Build 配置为使用存储在 Secret Manager 中的 Secret。

管理依赖项

应用的完整性取决于您开发的代码和使用的任何依赖项的完整性。您还需要考虑发布依赖项的位置、谁可以对工件代码库执行读写操作，以及部署到运行时环境的构建工件的可信来源的政策。

如需详细了解依赖项管理，请参阅管理依赖项。

在 Cloud Build 中，使用 Cloud Builder 运行命令。构建器是安装有常用语言和工具的容器映像。您可以使用公共注册表（例如 Docker Hub、Cloud Build 提供的构建器、社区提供的构建器，以及您创建的自定义构建器）中的公共容器映像。您还可以使用 buildpack 作为构建器，包括 Google Cloud 的 Buildpack。

查看您在 Cloud Build 构建中使用的构建器，确定提供它们的人员，并决定是否信任您的软件供应链。为了更好地控制构建器中的代码，您可以创建自定义构建器，而不是使用公共源代码中的构建器。

减少更改构建的机会

还有其他各种因素可能会影响构建，包括：

  • 并发运行并能够相互影响的构建作业，或者持续运行并影响后续 build 的构建作业。
  • 接受除 build 入口点和顶级源位置以外的用户参数的 build。
  • 使用可变范围或依赖项指定依赖项的 build（例如，使用带有 latest 标记的映像）。这些方法会给构建带来使用不良或不需要的依赖项版本的风险。

以下做法有助于降低这些风险：

  • 在临时环境中运行每个构建。
  • 避免运行带有额外参数的 build，这样用户就无法影响在 build 脚本中定义的变量。
  • 限制对构建服务和构建资源的访问。
  • 引用依赖项的不可变版本，而不是标识符，例如将来可以指向其他工件版本的标记。如需详细了解依赖项，请参阅依赖项管理。

遵循构建容器的最佳做法

查看构建容器的最佳实践，了解构建更可靠且更不易受到攻击的容器映像的方法，包括：

  • 打包单个应用
  • 处理进程
  • 优化 Docker 构建缓存
  • 移除不必要的工具并尽可能缩减图片大小
  • 使用 Artifact Analysis 扫描漏洞。您可以扫描存储在 Artifact Registry 中的映像，也可以在存储映像之前在本地扫描这些映像。
  • 添加代码的最佳实践
  • 使用公共映像的安全注意事项

Software Delivery Shield

Software Delivery Shield 是一种全代管式端到端软件供应链安全解决方案。它为 Google Cloud 服务提供了一套全面的模块化功能和工具，开发者、DevOps 和安全团队可以使用它们来改善软件供应链的安全状况。它会在 Google Cloud 控制台的 Cloud Build 界面中显示已构建应用的安全数据分析。其中包括：

  • SLSA 级别，用于确定软件供应链安全性的成熟度级别。
  • 针对 build 工件的漏洞、软件物料清单 (SBOM) 和漏洞可利用性交流 (Vulnerability Exploitability eXchange, VEX) 语句。
  • build 出处，这是关于 build 的可验证元数据的集合。其中包括已构建映像的摘要、输入来源位置、构建工具链、构建步骤和构建时长等详细信息。

如需了解如何查看已构建的应用的安全性数据分析，请参阅构建应用并查看安全性数据分析。

后续步骤