共计 3132 个字符，预计需要花费 8 分钟才能阅读完成。
在本篇文章中，咱们将理解第三方服务的监管有余，工件完整性验证及日志可见性有余这三个要害 CI/CD 平安危险，并给出缓解相应危险的倡议与措施。
第三方服务监管有余
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 平安危险并给出了缓解相应危险的平安倡议。点击下方链接查看往期文章：
十大 CI/CD 平安危险（一）
十大 CI/CD 平安危险（二）
十大 CI/CD 平安危险（三）
十大 CI/CD 平安危险（四）
