软件供应链威胁

软件供应链攻击途径是指攻击者故意或无意中破坏您的软件的各种方式。

存在漏洞的软件会带来诸多风险,包括泄露凭据或机密数据、数据损坏、安装恶意软件和应用中断。这些问题会导致浪费时间和金钱,并失去客户的信任。

威胁的入口点遍布整个软件生命周期,并且可能来自贵组织内部或外部。

软件供应链攻击的入口点

图表图例包含两组威胁:

  • 字母 AH 表示软件供应链中的攻击向量,在软件工件的供应链级别 (SLSA) 框架中被描述为威胁
  • 数字 14 表示 SLSA 框架未直接描述的其他攻击向量。

Google Cloud 提供了一组模块化功能和工具,这些功能和工具集成了用于缓解这两类威胁的最佳实践。

本文档中的各子部分介绍了源代码、build、部署和依赖项方面的威胁。

来源威胁

这些威胁会影响源代码的完整性。

  • 1:编写不安全的代码。如果不遵循安全编码做法,就可能会编写出无意中包含漏洞的代码。不安全的开发者工作站也可能会引入恶意代码或不安全代码。缓解措施包括:

    • 为开发者工作站设置政策。 Cloud Workstations 提供全托管式预配置工作站,您可以根据自己的需求对其进行自定义。
    • 对代码进行本地扫描。Cloud Code Source Protect(私享预览版)提供实时安全反馈,包括依赖项的漏洞和许可信息。开发者还可以使用 On-Demand Scanning API 扫描容器映像,检查是否存在操作系统和语言包漏洞。
    • 有关提高代码安全性的做法的培训。
  • :将有缺陷的代码提交到源代码库。这不仅包括恶意代码,还包括无意中引入跨网站脚本攻击等漏洞的代码。缓解措施包括:

    • 对源代码更改进行人工审核。
    • 使用与 IDE 和源代码控制系统集成的代码扫描和 lint 工具。
  • B:入侵源代码控制系统。限制对源代码控制系统和构建流水线中的其他系统的访问权限,并使用多重身份验证有助于降低此类风险。

评估源代码完整性时,还应检查您用于构建和部署软件的支持脚本和配置。将它们纳入源代码控制系统和代码审核流程,以降低这些文件中存在漏洞的风险。

如需详细了解如何保护来源,请参阅保护来源

构建威胁

这些威胁会在您构建或打包软件时破坏您的软件,或诱骗软件使用者使用有缺陷的版本。

  • C:使用非来自受信任源代码控制系统的源代码进行构建。有助于降低此风险的缓解措施包括:
    • 使用 Cloud Build 等构建服务生成来源信息,以便您验证自己的 build 是否使用了可信来源。
    • 将 CI/CD 基础架构放置在网络边界中,以防止 build 中的数据渗漏。对于 Google Cloud 服务,请使用 VPC Service Controls
    • 在私有工件存储区(例如 Artifact Registry)中存储和使用您所需的开源依赖项的可信副本。
  • D:入侵构建系统。有助于降低此风险的缓解措施包括:
    • 遵循最小权限原则,仅向需要的个人授予对构建系统的直接访问权限。在 Google Cloud 中,您可以授予适当的预定义角色或创建自定义角色
    • 使用 Cloud Build 等托管式构建服务。Cloud Build 通过为每个 build 设置虚拟机环境并在 build 完成后销毁该环境,来运行临时 build
    • 将 CI/CD 基础架构放置在网络边界中,以防止 build 中的数据渗漏。对于 Google Cloud 服务,请使用 VPC Service Controls
  • F:打包和发布在官方流程之外构建的软件。通过生成和签署 build 来源的构建系统,您可以验证软件是否由可信的构建系统构建。
  • G:破坏您为内部或外部用户存储软件的代码库。有助于降低此风险的缓解措施包括:
    • 在私有工件存储区(例如 Artifact Registry)中存储和使用您所需的开源依赖项的可信副本。
    • 验证 build 和源代码的来源。
    • 将上传权限限制为专用非人账号和代码库管理员。在 Google Cloud 中,服务账号代表服务和应用执行操作。

部署和运行时威胁

  • H:通过指定版本范围或未永久附加到特定 build 版本的标记来解析依赖项可能会导致多种问题:

    • 构建无法重现,因为构建首次使用的依赖项可能会与构建在日后执行同一构建时使用的依赖项不同。
    • 依赖项可能会解析为已遭到入侵的版本,或者包含会破坏软件的更改的版本。恶意行为者可能会利用这种不确定性,导致您的 build 选择他们的软件包版本,而不是您打算使用的版本。一些依赖项最佳实践有助于降低依赖项混淆风险。
  • 2:破坏部署流程。如果您使用持续部署流程,破坏该流程可能会对您向用户提供的软件引入不必要的更改。您可以通过限制对部署服务的访问权限并在预生产环境中测试更改来降低风险。Cloud Deploy 可帮助您管理持续交付流程以及在环境之间进行的提升。

  • 3:部署已遭到入侵或不合规的软件。强制执行部署政策有助于降低此类风险。您可以使用 Binary Authorization 验证容器映像是否符合政策条件,并阻止部署来自不受信任来源的容器映像。

  • 4:运行软件中的漏洞和错误配置。

    • 我们会定期发现新漏洞,这意味着新发现可能会改变正式版应用的安全风险级别。
    • 某些配置会增加未经授权的访问风险,例如以根用户身份运行或允许在执行容器时提权。

    GKE 安全状况信息中心会显示运行中工作负载中的漏洞配置问题的相关信息。

    在 Cloud Run 中,您还可以查看有关已部署修订版本的安全分析,包括您部署的容器映像中的已知漏洞。

如需详细了解如何保护源代码,请参阅保护 build;如需了解如何保护部署,请参阅保护部署

依赖项威胁

依赖项包括 build 中的直接依赖项以及所有传递依赖项,即直接依赖项的下游依赖项的递归树。

在该图中,E 表示在 build 中使用了恶意依赖项。不良依赖项可能包括:

  • 应用依赖的任何软件,包括您在内部开发的组件、商业第三方软件、开源软件。
  • 源自任何其他攻击媒介的漏洞。例如:
    • 攻击者获得对您的源代码控制系统的访问权限,并修改了项目使用的依赖项的版本。
    • 您的 build 包含贵组织中其他团队开发的组件。他们直接在本地开发环境中构建和发布组件,并意外在仅用于本地测试和调试的库中引入了漏洞。
  • 从公共代码库中故意移除开源依赖项。 如果使用相应依赖项的流水线直接从公共代码库检索依赖项,则移除此依赖项可能会导致流水线中断。

如需了解降低风险的方法,请参阅依赖项最佳实践

缓解威胁

供应链的整体完整性取决于其最脆弱的部分。忽视某个攻击途径会增加供应链中相应部分遭到攻击的风险。

同时,您无需一次性更改所有内容。累积行为效应(也称为“瑞士奶酪模型”)适用于软件供应链安全。您实施的每项缓解措施都会降低风险,如果您在整个供应链中组合使用缓解措施,则可以增强对不同类型攻击的防范能力。

  • 使用框架和工具评估安全状况,帮助您评估组织检测、响应和修复威胁的能力。
  • 了解保护软件供应链的最佳实践,以及专为支持这些实践而设计的 Google Cloud 产品。
  • 将 Google Cloud 安全功能纳入到开发、构建和部署流程中,以改善软件供应链的安全状况。您可以根据自己的优先事项和现有基础架构,逐步实现服务。

后续步骤