保护来源

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本文档介绍了管理软件源代码的最佳做法。

软件团队在管理源代码时采取的基本步骤是采用版本控制系统 (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]
  • 安全政策:存储政策文件,以自动执行政策。例如,您可以存储 Gatekeeper 政策,以在 GKE 中允许或拒绝部署行为,或者存储 Sentinel 政策,防止 Terraform 预配违反政策的基础架构。

版本控制是 DORA DevOps 研究确定的一项技术能力,可推动实现更出色的软件交付表现和组织绩效。将脚本、源代码和配置文件存储在版本控制中有助于重现和恢复环境、跟踪和审核更改以及快速应对缺陷。

代码库配置

代码库是整理代码及相关角色、权限、集成和审批的基本逻辑单元。

代码库配置可能出现的问题包括:

  • 代码库配置不是标准化的,因此很难确保代码库的安全性适合它所代表的应用,尤其是在组织有数百个或数千个代码库的常见场景中。
  • 创建代码库的任何人将成为拥有完整管理员权限的所有者,包括能够在没有其他审核者的情况下执行合并。
  • 将代码库与代码分析、构建服务器、问题跟踪器、通知服务以及 CI/CD 基础架构的其他部分集成可能会相当麻烦。以标准方式创建和设置代码库可以节省重复性工作并支持最佳做法。

为解决这些问题,最佳做法包括

  • 使用自动化的可重复安全流程来设置代码库。例如,您可以设置包含代码库针对其安全要求的 Terraform 模块。与安全性较低的应用相比,安全性较高的应用需要更多且不同的合并审批者。
  • 为代码库管理员提供一种从一组代码库配置模板中进行选择的方法,这些模板可推动新的代码库设置,而不是从头开始配置每个代码库。这些模板应反映应用的不同安全级别,并与每个安全级别所需的用户身份同步。在实践中,这通常意味着使用分层身份和访问权限控制 (IAM) 系统,以反映您的组织中的应用和基础架构以及对其负责的用户。
  • 要求对代码库用户进行多重身份验证、集中式身份管理。
    • 集中式身份管理可确保当用户从组织离职或移至新团队时,您在来源管理方面保留的最低权限。
    • 多重身份验证可显著降低来源遭受钓鱼式攻击和其他类型的攻击的风险。双重身份验证是代码审批人员的 SLSA 4 级要求之一。
  • 将代码库所有者限制为可信的少量员工。这可能需要将版本控制与身份管理系统集成,并移动在组织中设置更高政策的功能。如果可能,请移除代码库所有者无需再次审核即可执行合并的功能。

代码审核

代码审核是组织保持其软件质量和安全性的主要方式。代码审核会尝试解决各种失败模式,例如:

  • 引入的代码存在软件缺陷或设计不灵活。
  • 定义不当的 API
  • 因开发者编写的不安全代码而导致的安全问题
  • 引入因添加不安全或可能不安全的第三方库而导致的安全问题。

降低风险的一些方法包括:

  • 在整个软件生命周期中实现持续测试。在您将源代码提交到版本控制系统时触发的自动化测试可让开发者快速获得有关测试发现的问题的反馈。
  • 确保审核者的数量和身份适合应用的安全级别。例如,与面向公众的业务关键型应用相比,使用率低的内网应用的安全要求较低。
  • 根据技术变更和提交更改所需的信任级别来分配审核者。审核人员应该熟练掌握所评价的语言、与代码交互的系统以及此类应用的安全风险。技术专业知识要求具有许多维度。例如:
    • 代码是否可读?
    • 是否安全?
    • 是否使用了适当的第三方库?
    • 是否已实施相应的流程来保护第三方库?
    • 代码是否为可组合项?
    • API 设计是否遵循了最佳做法?
  • 评价不应该是官僚作风步骤,而应该是围绕最佳做法进行的持续对话。围绕技术栈的每个部分制定核对清单、样式指南和设计标准,并面向新开发者提供培训计划。VS Code 和 IntelliJ 等 IDE 提供了可以自动标记程序化错误或样式错误的 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 在 Google Cloud 上提供全代管式开发环境。它可让 IT 和安全管理员轻松预配、扩缩、管理和保护其开发环境,并让开发者能够通过一致的配置和可自定义的工具访问开发环境。

    Cloud Workstations 可增强应用开发环境的安全状况,帮助实现左移安全性。它具有 VPC Service Controls、专用入站流量或出站流量、强制映像更新以及 Identity and Access Management 访问政策等安全功能。如需了解详情,请参阅 Cloud Workstations 文档

  • Cloud Code 源代码保护(预览版)

    Cloud Code 提供 IDE 支持,方便您创建、部署和集成 Google Cloud 应用。它使开发者可以根据示例模板创建和自定义新应用,并运行已完成的应用。Cloud Code 源代码保护功能会在开发者运行 IDE 时为其提供实时安全反馈,例如识别易受攻击的依赖项和许可报告。它提供快速且切实可行的反馈,使开发者能够在软件开发过程的开始处纠正其代码。

    功能可用性:Cloud Code 源代码保护不适用于公共访问。如需使用此功能,请参阅访问权限请求页面

后续步骤