第三方服务监管不足

CI/CD 攻击面包括企业资产，例如 SCM 和 CI，以及被授权访问这些资产的第三方服务。与不受监管地使用第三方服务有关的风险依赖于第三方服务可以极其轻松地被授予对 CI/CD 系统中资源的访问权限，从而有效地扩大了企业的攻击面。

风险描述

如今大部分企业都将第三方链接到其 CI/CD 系统和流程，这样易于实施且易于发挥直接价值，也使第三方成为日常软件开发中不可或缺的一部分，嵌入或授予第三方访问权限的方法正变得越来越多样化。以常见的 SCM—GitHub SAAS—为例，可以通过以下 5 种方法中的一种或多种连接第三方应用程序：

GitHub 应用程序
OAuth 应用程序
提供给第三方应用程序的访问令牌
提供给第三方应用程序的 SSH 密钥
发送给第三方的 webhook 事件配置

每种方法都需要几秒钟到几分钟的时间来实施，并为第三方提供多种功能，比如读取单个存储库中的代码，甚至是全面管理 GitHub 组织。尽管这些第三方被授予对系统的潜在高级别许可，但在许多情况下，企业在实际实施之前不需要特殊许可或批准。

构建系统还允许轻松集成第三方。将第三方集成到构建流水线中通常并不会比在流水线配置文件中添加 1-2 行代码或从构建系统的市场安装插件（例如 Github Actions 中的操作、CircleCI 中的 Orbs）更复杂。将第三方功能作为构建过程的一部分导入并执行，并可以完全访问执行它的流水线阶段可用的任何资源。

在大多数 CI/CD 系统中，类似的集成方法以各种形式提供，从而使在整个软件工程生态系统中管理和维护围绕第三方使用的最小特权的过程变得极其复杂。各企业也正在努力应对以下挑战：

全面了解哪些第三方可以访问不同的系统
第三方拥有哪些访问方法、被授予的权限/访问级别以及实际使用的权限/访问级别

影响

缺乏对第三方实施的管理和可见性会影响企业在其 CI/CD 系统中维护 RBAC。RBAC 的实施不足和第三方的最小特权，加上围绕第三方实施过程的管理和尽职调查不足，显著增加了企业的攻击面。鉴于 CI/CD 系统和环境的高度互联性，单个第三方威胁可被利用，给企业造成巨大损失，例如具有写入权限的第三方存储库，攻击者可以利用该代码将代码推送到存储库，这反过来又会触发构建并在构建系统上运行恶意代码。

建议

围绕第三方服务的管理控制应在第三方使用生命周期的每个阶段实施：

批准——建立审查程序，以确保在软件工程生态系统中的任何地方获得资源访问权限的第三方在被授予环境访问权限之前获得批准，并且授予他们的权限级别符合最小特权原则。
集成——引入控制和程序以保持对集成到 CI/CD 系统的所有第三方的持续可见性，包括：
- 整合方法。确保涵盖每个系统的所有集成方法（包括市场应用程序、插件、OAuth 应用程序、编程访问令牌等）。
- 授予第三方的权限级别。
- 第三方实际使用的许可级别。
持续使用的可见性——确保每个第三方都被限制在其需要访问和删除未使用和/或冗余权限的特定资源的范围内。作为构建过程的一部分集成的第三方应在范围内运行，对机密和代码的访问受限，并具有严格的出入口过滤机制。
取消配置——定期审查所有集成的第三方并删除不再使用的部分。

工件完整性验证不当

由于确保代码和工件验证的机制不足，工件完整性验证不当风险会导致访问 CI/CD 流程中的系统的攻击者将恶意代码或工件推入流水线中。

CI/CD 流程由多个步骤组成，最终负责将代码从开发人员的工作站推送到生产环境。在这个过程中内部资源和工件与从远程位置获取的第三方包和工件相结合，最终资源依赖于分布在不同步骤中的多个来源，由多个贡献者提供，这也意味着多个入口点被创建，通过这些入口点可以篡改最终资源。如果被篡改的资源能够成功地渗透到交付过程中，很可能会以当作受信任的资源一直流向生产环境。

影响

在软件交付过程中，恶意攻击者可能会滥用不当的工件完整性验证，通过流水线传送恶意工件，最终导致恶意代码在 CI/CD 流程中的系统上，或更糟的情况，在生产环境中执行。

建议

防止不当的工件完整性验证风险需要一系列措施，跨越软件交付链中的不同系统和阶段。建议企业考虑以下实践：

实施相关流程和技术来验证从开发到生产的整个过程中资源的完整性。生成资源时，该过程将包括使用外部资源签名基础架构对该资源进行签名。在流水线的后续步骤中使用该资源之前，应根据签名权限验证资源的完整性。在这种情况下需要考虑的一些普遍措施有：
- 代码签名——SCM 解决方案提供了使用每个贡献者的唯一密钥对提交进行签名的能力。然后可以利用此措施来防止未签名的提交流下流水线。
- 工件验证软件——使用签名和验证代码和工件的工具提供了一种方法来防止未经验证的软件被交付到流水线中（如 Sigstore）。
- 配置偏差检测——检测配置偏差的措施（例如，未使用签名 IAC 模板管理的云环境中的资源），表明资源由不受信任的源或进程部署。
从构建/部署流水线获取的第三方资源（例如作为构建过程的一部分导入和执行的脚本）应遵循类似的逻辑——在使用第三方资源之前，应计算资源的哈希值，并交叉引用官方发布的来自资源提供者发布的哈希。

日志记录和可见性不足

日志记录和可见性不足将给攻击者在 CI/CD 环境中执行恶意活动的机会。强大的日志记录和可见性功能对于企业准备、检测和调查安全相关事件的能力至关重要。虽然工作站、服务器、网络设备以及关键 IT 和业务应用程序通常在企业的日志记录和可见性程序中全面覆盖，但开发环境中的系统和流程通常并非如此。

鉴于利用软件工程环境和流程的潜在攻击向量的数量，安全团队必须培养足够的能力以在这些攻击发生时立即执行检测。由于其中许多向量涉及利用针对不同系统的程序化访问，因此面临这一挑战的关键方面是围绕人工和程序访问创建强大的可见性。鉴于 CI/CD 攻击向量的复杂性，系统的审计日志（例如用户访问、用户创建、权限修改）和应用日志（例如将事件推送到存储库、执行）具有同等的重要性构建，上传工件。

影响

恶意攻击者为了达成攻击目的，逐渐将注意力转移到开发环境。企业如果无法确保围绕这些环境进行适当的日志记录和可见性控制，则可能无法检测到违规行为，而且企业在缓解/补救以及事件调查能力也会大大降低。对于受到攻击的企业来说，时间和数据至关重要，集中放置所有相关数据源将在事件响应场景中起到完全不同的作用（成功补救或破坏性打击）。

建议

实现足够的日志记录和可见性有几个要素：

映射环境——如果不熟悉涉及潜在威胁的所有不同系统，就无法实现强大的可见性能力。潜在的违规可能涉及参与 CI/CD 流程的任何系统，包括 SCM、CI、工件存储库、包管理软件、容器注册表、CD 和编排引擎（例如 K8s）。识别并建立组织内使用的所有系统的清单，包含这些系统的每个实例（例如 Jenkins）。
识别并启用合适的日志源——一旦识别了所有相关系统，下一步就是确保启相关日志。应通过允许的所有各种措施，围绕人工访问和程序访问优化可见性。所有相关审计日志源以及应用日志源都非常重要，应当给予同等重视。
将日志传送到集中位置（例如 SIEM），来支持不同系统之间日志的聚合和关联，方便进行检测和调查。
为检测异常和潜在的恶意活动创建警报，包括每个系统本身的异常和代码传送过程中的异常，这涉及多个系统并且需要更深入地了解内部构建和部署过程。

本系列文章至此篇已完结，在五篇文章中我们陆续介绍了十大 CI/CD 安全风险并给出了缓解相应风险的安全建议。点击下方链接查看往期文章：