持续部署风险大吗?存在哪些安全问题

采用持续部署可以大大加快软件交付速度，但也引入关键的安全挑战。近年来，一些严重的全球规模安全漏洞(Solarwinds 和 Kaseya等)与软件交付基础设施的漏洞有关。

持续部署可能会使情况变得更糟。随着代码变更为自动推送到生产环境，出错的余地缩小，而安全漏洞的影响可能会瞬间放大。

这些问题引发了关键的安全担忧，需要我们审视这些风险是如何产生的，并寻找实际的缓解措施，以帮助团队安全地采用持续部署(CD)。无论你是正在考虑采用CD，还是已经运行CD，理解这些问题对于在交付管道中保持速度和安全性都是至关重要的。

什么是持续部署?

持续部署 (CD) 是一个自动化的软件发布流程，其中代码更改会自动部署到生产环境中，而无需人工干预。它确保所有修改都经过严格的管道，并结合自动化测试来保持代码完整性。

其目标是减少部署时间，尽量减少错误，以便能够频繁更新以快速满足用户需求。持续部署高度依赖自动化以实现快速、可靠的交付，因此需要全面的测试和监控系统。

持续部署可自动执行整个 CI/CD 管道，包括其最后阶段。持续集成 (CI) 侧重于合并代码和测试，而 CD 则自动执行整个部署过程。这缩短了从代码提交到生产部署的时间。使用CD的组织可以迅速响应市场变化，但也需要建立一个协调良好的基础设施和严格的测试流程。

持续部署管道的关键组件和工作流

持续部署管道由多个阶段组成，这些阶段可确保仅部署经过验证且生产就绪的代码。该过程是完全自动化的，依靠工具和脚本来执行质量关卡和运营准备。

1. 源代码控制和触发事件：当更改被推送到源代码控制系统(如 Git)时，管道开始运行。整个过程完全自动化，依赖工具和脚本来强制执行质量检查和操作准备情况。

2. 构建阶段：代码被编译并打包成可部署的工件。解决依赖关系，并且可以运行静态分析工具检测代码质量标准。此阶段可确保以一致、可重复的方式构建应用程序。

3. 自动化测试：单元测试、集成测试和端到端测试依次运行。每个测试套件都验证系统的不同方面。如果测试失败，管道将停止，防止不稳定的代码进入生产环境。

4. 环境预置：使用基础设施即代码工具自动预置或更新所需的环境。容器和编排平台(如 Docker 和 Kubernetes)通常用于标准化部署环境。

5. 部署到预生产环境和验证：在进入生产环境之前，应用程序被部署到镜像生产的暂存环境。在这里运行冒烟测试和“合理性”检查，以验证核心功能是否在类似生产环境中正常工作。

6. 生产部署：如果前面的所有阶段都通过，代码将自动部署到生产环境。蓝绿部署或 Canary 发布等技术通常用于降低风险，并允许在发生故障时快速回滚。

7. 监控和反馈：部署后，监控工具会跟踪应用程序的运行状况、性能和错误率。警报系统会通知团队异常情况，而日志记录和指标则为持续改进提供反馈。

持续部署中的安全问题以及如何缓解

虽然自动化提高了效率，但如果处理不当，也会引入安全风险。以下是影响CD管道安全性的主要问题以及应对方法。

1. 监控和警报不足

在持续部署中，问题可能会迅速影响到生产环境。如果无法实时了解应用程序行为，内存泄漏、CPU 峰值、请求失败或未经授权的访问尝试等问题可能会被忽视，直到用户受到影响。

为了降低这些问题的可能性，不仅要监控基础设施指标，还要监控应用程序级信号，包括 API 错误率、数据库延迟和身份验证失败。其他需要考虑的项目包括：定义警报阈值和升级策略以确保及时干预，将警报集成到通信平台以实现快速响应，以及使用异常检测和历史基线来捕获不会触发硬阈值的细微安全漏洞。

2. 测试自动化不足

为了防止漏洞进入生产环境，安全测试需要成为 CI/CD 管道的一部分。仅依赖功能测试会忽略 API 不安全、配置错误或输入验证缺陷等风险。

整合特定于安全的自动化测试，例如：

• 静态应用程序安全测试 (SAST)，用于检测代码级问题。
• 动态应用程序安全测试 (DAST)，用于在运行时模拟攻击。
• 依赖扫描，检查库中的CVE。
• 对Kubernetes或Terraform配置进行“代码检查”。
• 定期安排安全回归测试，以验证过去的修复，并通过在开发周期的早期集成测试来支持左移安全实践。

3. 有风险的部署策略

采用“一次性全部更新”的天真部署模式会增加失败发布或安全回归的范围。如果引入了问题，所有用户会立即受到影响，这使得回滚和故障排查变得更加困难。 使用为安全性和可观测性设计的部署策略：

• 金丝雀部署：向一小部分流量发布新代码，根据健康检查和指标逐步扩展。
• 蓝绿部署：维护两个相同的环境——只有在确认新版本稳定后才切换流量。功能功能标志：允许在运行时启用或禁用功能，将部署与发布解耦。

这些方法可以最小化中断，并为团队提供时间在全面推出之前检测和解决问题。

4. 缺乏回滚机制

在快速发展的管道中，如果不支持回滚，就会增加停机时间和风险。如果无法获取或追溯到已知的最后一个良好状态，团队可能会在恢复过程中遇到困难。

设计可逆的部署流程。使用存储在工件仓库中的版本化工件。对于基础设施，对配置进行版本控制，并使用支持状态管理和回滚的基础设施即代码工具。使用部署工具自动化回滚路径，并在预生产环境中测试回滚场景，以确保在事件发生时的可靠性。

5. 暴露于供应链攻击

现代应用程序高度依赖第三方组件，这些组件可能会受到损害从而引入恶意软件、后门或可利用的缺陷。攻击者越来越多地将开源库、容器映像和 CI/CD 工具本身作为目标。

缓解措施：

• 使用能够持续扫描依赖项中已知漏洞的工具。
• 使用校验和和签名验证外部包和基础镜像的完整性。
• 优先选择最小化、加固的容器镜像。
• 使用机器人自动化依赖更新，但需要人工审查或分阶段推出。
• 使用签名的工件和安全的工件提升实践，将构建环境与生产环境隔离。
• 维护软件物料清单(SBOM)，以实现透明性和符合SLSA或NIST SSDF等安全标准。

6. 密钥管理

不当处理凭证(如API密钥、令牌或数据库密码)会带来重大安全风险。将密钥硬编码或存储在版本控制系统中会使它们对任何有仓库访问权限的人都是可访问的。

相反，使用专门的秘密管理系统，提供以下功能：

• 加密存储和访问控制。
• 短期凭证和自动轮换。
• 访问事件的审核日志记录。
• 基于最低权限的作用域权限。
• 通过安全通道(例如环境变量或加密文件)将密钥注入运行时环境，而无需在日志或 UI 中公开它们。确保开发人员和自动化脚本遵循安全处理实践，并验证机密信息不会因配置错误的访问日志或错误消息而泄露。

持续部署在速度、敏捷性和响应能力方面具有不可否认的优势，通过将安全性构建到管道的每个阶段(从代码提交到生产发布)，团队可以在不牺牲控制或安全性的情况下接受持续部署。通过制定正确的策略，CD 不仅会变得更快，而且会变得更智能、更有弹性。

 

参读链接：

https://www.tripwire.com/state-of-security/continuous-deployment-too-risky-security-concerns-and-mitigations