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