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