本文档介绍了管理软件源代码的最佳实践。
软件团队管理源代码的基本步骤是采用版本控制系统 (VCS)。版本控制系统提供更改历史记录和可审核性。GitHub 等托管版本控制系统还提供其他优势，例如可用性、稳定性、安全控制、集成代码审核工具以及与其他云服务的集成。
虽然大多数团队目前都在使用版本控制，但配置版本控制系统及其与 CI/CD 流水线其他部分的集成的方式有很多种。
本文档探讨了配置版本控制系统时需要考虑的软件供应链安全性问题。它介绍了 软件工件的供应链 (SLSA)（ 一个用于保护软件供应链的框架）中的最佳实践。该框架包含 多个级别的要求，可帮助您以增量方式实现更改， 包括源代码要求。
具有更改历史记录和不可变修订的版本控制系统是 SLSA 2 级要求。我们建议将 SLSA 2 级作为软件供应链的初始基准级别。
在 SLSA 3 级，源代码和构建平台遵循更严格的安全 要求，包括经过验证的源代码历史记录和源代码保留政策。 SLSA 4 级在源代码要求中添加了双人审核。
版本控制不仅适用于应用源代码
如果需要历史记录审核和审计，将应用源代码存储在版本控制中是一种成熟的做法。不过，还有其他类型的源代码也受益于版本控制，包括配置、政策和数据。这包括以下任何文件：
- 影响计算基础架构的可用性和安全性
- 需要协作才能最终确定
- 需要可重复的审批流程
- 需要更改历史记录
以下是一些示例：
- 基础架构即代码：希望以可伸缩且安全的方式管理其 基础架构的组织使用基础架构即代码作为 关键方法。例如，您可以将创建 Artifact Registry 代码库的 Terraform 模块存储在版本 控制中，。
- 配置管理：配置管理与 基础架构即代码类似，但侧重于使用 Ansible、Puppet 和 Chef 等工具管理应用配置。您可以在版本控制系统中存储和管理应用配置文件。
- 数据库配置和迁移脚本：存储产品数据库以及分析或日志记录 数据库的配置 和脚本。
- Jupyter 笔记本：您可以通过多种方式使用存储在 GitHub 中的笔记本，包括 JupyterLab 的扩展程序、Colaboratory 和 Vertex AI Workbench
- 安全政策：存储用于自动执行政策的政策文件。 例如，您可以存储允许或拒绝 GKE 中部署行为的 Gatekeeper 政策 ，或者阻止 Terraform 预配违反政策的基础架构的 Sentinel 政策 。
版本控制是 技术能力 之一， DORA DevOps 研究 确定这些能力可提高软件交付表现和 组织绩效。将脚本、源代码和配置文件存储在版本控制中可帮助您重现和恢复环境、跟踪和审核更改，以及快速响应缺陷。
代码库配置
代码库是组织代码以及相关角色、权限、集成和审批的基本逻辑单元。
代码库配置可能会出现以下问题：
- 代码库配置未标准化，因此很难确保代码库安全性适合其所代表的应用，尤其是在组织拥有数百或数千个代码库的常见情况下。
- 创建代码库的任何人都会成为拥有完整管理权限的所有者，包括无需其他审核者即可执行合并的能力。
- 将代码库与代码分析、构建服务器、问题跟踪器、通知服务和 CI/CD 基础架构的其他部分集成可能需要大量工作。采用标准方式创建和设置代码库可以节省重复性工作并支持最佳实践。
为解决这些问题，最佳实践包括
- 通过自动化、可重复且注重安全性的流程设置代码库。例如，您可以设置 Terraform 模块，其中包含代码库所针对的应用的安全要求。 与安全性较低的应用相比，安全性较高的应用需要更多不同的合并审批者。
- 为代码库管理员提供一种从一组代码库配置模板中进行选择的方式，以便驱动新代码库设置，而不是从头开始配置每个代码库。这些模板应反映应用的不同安全级别，并与每个安全级别所需的用户身份同步。在实践中，这通常意味着使用分层 身份和访问权限控制 (IAM) 系统 该系统反映了组织中的应用和基础架构以及 负责这些应用和基础架构的用户。
- 要求代码库用户采用集中式身份管理和多重身份验证。
- 集中式身份管理可确保用户离开组织或调到新团队时，您仍能保持对源代码管理的最小权限。
- 多重身份验证可显著降低源代码遭受网络钓鱼和其他类型攻击的风险。双重身份验证是 SLSA 4 级对代码审批者的要求之一。
- 将代码库所有者限制为少数受信任的员工。这可能需要将版本控制与身份管理系统集成，并将设置政策的能力提升到组织中的更高层级。如果可能，请移除代码库所有者在没有第二位审核者的情况下执行合并的能力。
代码审核
代码审核是组织维护软件质量和安全性的主要方式。代码审核旨在解决各种故障模式，例如：
- 引入存在软件缺陷或设计不灵活的代码。
- API 定义不明确
- 由于开发者编写不安全的代码而引入安全问题
- 由于添加不安全或可能变得不安全的第三方库而引入安全问题。
以下是一些降低风险的方法：
- 在整个软件生命周期中实现测试自动化 。 当您将源代码提交到版本控制系统时触发的自动化测试，可让开发者快速获得有关测试发现的问题的反馈。
- 使审核者的数量和身份与应用的安全等级相适应。例如，与面向公众的关键业务应用相比，使用率较低的内网应用的安全要求较低。
- 根据技术专业知识和提交中所更改内容所需的信任级别分配审核者。审核者应精通所审核的语言、代码与之交互的系统以及此类应用中的安全风险。技术专业知识要求有很多方面。例如：
- 代码是否清晰易懂？
- 代码是否安全？
- 代码是否使用了适当的第三方库？
- 是否已制定保护第三方库的流程？
- 代码是否可组合？
- API 设计是否遵循最佳实践？
审核不应是官僚步骤，而应是围绕最佳实践的持续对话。围绕技术堆栈的每个部分创建核对清单、样式指南和设计标准，并为新开发者提供教育计划。某些 IDE（例如 VS Code 和 IntelliJ）提供可以自动标记程序或样式错误的 Linter。Linter 可帮助开发者创建更一致的代码，并让代码审核者更专注于自动化检查不易发现的问题。
Developing Secure Software 是 Open Source Security Foundation (OpenSSF) 创建的免费在线课程。 它在软件供应链安全性的背景下介绍了基本的软件开发实践。
在单个开发者准备就绪后，立即使用功能分支拉取请求执行代码审核。不要等到即将进行新版本测试时才进行安全检查和代码审核。
将漏洞扫描（包括扫描第三方库）集成到拉取请求和 IDE 中，有助于尽快发现问题。借助 On-Demand Scanning API，您可以在本地扫描 容器以查找漏洞 Google Cloud 。
集成合并前自动化测试，以便开发者可以识别和修复会破坏应用的更改。 详细了解测试自动化。
合并审批
在持续集成的 CI/CD 流水线中，将代码合并到生产分支可能会导致下游更改，包括自动构建和发布。 因此，确保谁可以合并是确保软件部署安全的关键部分。注意事项包括：
- 在生产分支上设置受保护的分支所有者。允许合并的人员数量和身份应与应用的安全要求相适应。SLSA 4 级要求有两位经过强身份验证的审批者，但审批者的数量应与代码库的内容相适应。
- 严格控制代码库所有者的身份，因为在大多数版本控制系统中，他们可以自行执行合并。
- 为多代码库和多工件发布分离部署和合并审批流程。
保护开发的工具
Google Cloud 提供了一组模块化能力和工具，您可以使用这些能力和工具来提高软件供应链的安全状况。以下组件有助于保护软件源代码：
Cloud Workstations（预览版）
Cloud Workstations 在 Google Cloud上提供全托管式开发环境。它使 IT 和安全管理员能够轻松预配、扩缩、管理和保护其开发环境，并允许开发者使用一致的配置和可自定义的工具访问开发环境。
Cloud Workstations 通过增强应用开发环境的安全性来帮助实现安全左移。它具有 VPC Service Controls、专用入站流量或出站流量、强制映像更新和 Identity and Access Management 访问政策等安全功能。如需了解详情，请参阅 Cloud Workstations 文档。
Cloud Code source protect（预览版）
Cloud Code 提供 IDE 支持，以创建、部署应用并将其与 集成 Google Cloud。它使开发者能够通过示例模板创建和自定义新应用，并运行已完成的应用。Cloud Code source protect 可在开发者使用 IDE 时向其提供实时安全反馈，例如识别易受攻击的依赖项和许可报告。它提供快速且可操作的反馈，使开发者能够在软件开发过程的开始阶段更正代码。
功能可用性：Cloud Code source protect 不公开提供。如需访问此功能，请参阅 访问请求页面。