如何安全加固您的CI/CD管道

近年来，各大软件公司都开始依赖DevOps方法，来增强软件交付的敏捷性和协作能力。CI/CD管道使得软件开发生命周期(SDLC)中的各个流程更加自动化，进而实现了新功能的无缝集成和交付。 虽然CI/CD管道能够通过自动化和敏捷性，来增强软件的开发，但是它们往往需要集成大量的工具和服务，而这极有可能会引入新的安全漏洞。可见，识别和修复这些安全漏洞是确保CI/CD安全实践的关键。本文将和您讨论如何安全加固CI/CD管道。

CI/CD安全性简介

虽然CI/CD管道是通过自动化来提高软件开发和交付的效率，但是管道的核心阶段在默认情况下并不包含安全性。实际上，CI/CD的安全性是一组旨在识别和修复漏洞的实践，而不会显著地减慢管道中的各项流程。CI/CD的安全实践主要涉及到：注入渗透测试和主动安全审计，并据此减少因延迟交付，给安全和QA团队造成的瓶颈。因此，安全的CI/CD管道会让软件团队能够自动化多个部署环境，提高SDLC(软件开发生命周期)的安全性，从而增强敏捷性。

CI/CD管道的常见安全威胁

一个组织的CI/CD管道往往具有基于所使用的业务案例、工作负载、以及技术栈的独立特征。因此，CI/CD的安全性在实现上也会因用例的不同而有所差异。对此，我们应当首先认识那些几乎在所有管道中都存在的安全风险类型：

未经授权访问的代码存储库

CI/CD的各种操作主要依赖共享存储库，来实现协作、配置管理、更新和版本控制。所有源代码和配置文件都被保存在Git存储库中，并作为单一的来源。公共存储库在CI/CD管道中备受欢迎的原因是，它们降低了开发的成本和时间。 但是，由于开发人员将源代码从其私有主机发布到公共的共享文件夹中，因此给存储库带来了安全威胁。攻击者可以搜索开源注册表作为一种侦察技术，并利用获得的数据，进行有针对性的网络钓鱼、逆向工程、以及远程代码执行攻击。

不安全的代码

CI/CD管道中快速开发和交付的要求，导致了越来越多的开源使用、以及与第三方的集成。一些团队可能会在没有核查源代码的安全漏洞的情况下，将第三方代码集成并导入部署环境。显然，这是由于开发人员未能遵循代码安全的最佳实践，而增加了CI/CD管道的攻击面。常见的代码漏洞包括格式字符串漏洞、缓冲区溢出、错误处理不当、以及规范化问题等。

密钥管理不当

密钥管理有助于合理化对CI/CD管道中数据和资源的访问。其中包括：密码、令牌、API密钥、以及其他身份验证凭据，它们可以在管道中被用于验证访问敏感系统的用户。因此，密钥的曝露会让攻击者获取CI/CD进程的部分、甚至全部控制权。常见的密钥管理环节中的错误配置包括：对密钥进行硬编码、在公共云环境中存储密钥、以及手动进行密钥管理等。

左移安全

在较旧的管道中，由于安全性往往是最后一步，因此导致了部署过程中的瓶颈。如今的最佳实践理论是：在SDLC的早期集成安全控制，也被称为“转移安全”。此类左移会涉及在CI/CD管道的每个层面上实施安全检查，从而在每个步骤中，实现更加准确的威胁检测。显然，其目标就是为了消除DevOps和安全团队之间的摩擦，提高软件开发的效率，并确保稳健的安全实践。

采用CI/CD安全工具的关键注意事项

在选择保护CI/CD管道的工具时，我们应当考虑如下因素：

扫描覆盖率 拥有成本和许可条款 需要维护和配置的工作量 可扩展性 与现有开发和安全栈的集成

在CI/CD管道上管理安全性

随着威胁态势的不断变化，管理安全性已经成为了CI/CD管道的最重要环节之一。保护DevOps工作流的第一步便是评估如何将DevSecOps的原则应用于CI/CD管道。在评估的过程中，我们需要确定管理安全性的工具和策略。

保护CI/CD管道的最佳实践

为了充分体现将安全性直接集成到软件生命周期中的好处，开发团队应该：

避免在配置文件和CI/CD构建工具中使用硬编码的密钥

SDLC的各个阶段都会用到密钥。而提供这些密钥的一种简单方法是，将它们作为环境变量引用到配置文件和清单中。任何可以访问这些模板和文件的人员，都将能够从此类文件中提取凭证信息，这便可能导致数据的泄露。因此，软件团队应当使用加密存储或启用密钥集中管理的工具，以使得密钥数据能够远离恶意用户。为了安全地管理和分发密钥，管理员应该在将密钥存储在ETCD服务器之前，就执行静态加密。 首先，如下代码段所示，将密钥编码为Base64格式：

$ username=$(echo -n "admin" | base64)
$ password=$(echo -n "a62fjbd37942dcs" | base64)

在YAML文件中定义密钥：

echo "apiVersion: v1
> kind: Secret
> metadata:
>   name: test-secret
> type: Opaque
> data:
>   username: $username
>   password: $password" >> secret.yaml

接着，一旦创建了密钥，您就可以将它们应用到Kubernetes的pod中。这可以通过创建一个.yaml文件来完成。文件secret-env.yaml的环境变量中存放了源自密钥的数据。该文件的规范，如下代码段所示：

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: alpine:latest
      command: ["sleep", "9999"]
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: password
  restartPolicy: Never

如上述代码段所示，在填充环境变量时，Kubernetes会解码Base64值。这些环境变量可被用于所有的Kubernetes API对象，且无需对密钥数据进行硬编码。

对CI/CD的构建工具实施访问控制

DevOps团队应实施身份验证和授权机制，以管控那些可以访问CI/CD管道中特定流程和工具的实体。团队应贯彻最小权限原则，以确保仅将资源的访问权限，授予绝对需要的角色。同时，CI/CD管道中的数据还应该使用令牌、访问密钥和密码等方式予以保护，以防止恶意负载被添加到管道中。

为源代码管理建立身份验证机制

带版本控制的存储库(通常在Git中)是CI/CD管道的必备工具。它们能够促进协作并实现新功能的持续部署。不过，由于Git存储库包含着应用程序的源代码、基础设施即代码(Infrastructure-as-Code)清单、以及知识产权，因此源代码控制中的漏洞将会允许攻击者访问到应用程序的设计和实现逻辑。 鉴于它们往往是黑客逐利的目标，因此我们应该使用多因素身份验证，来对Git存储库的访问予以安全加固。同时，开发团队还可以通过Git的最佳实践，来防止意外的分支、以及提交.gitignore文件。

确保管道中所有环境配置的一致性

DevOps团队应确保开发、测试、生产等所有环境的配置具有一致性。通过配置奇偶校验，QA团队可以在测试期间准确地检测出安全问题，特别是那些普遍存在于所有环境配置中的问题。同时，团队也可以使用容器和基础设施即代码的声明等虚拟化和抽象技术，来实现一致性的检测。

配置回滚功能

安全和QA团队通常会在应用程序更新或部署后发现安全问题。这往往需要管理员将相应的部署回滚(或称恢复)到早期的版本。此类部署配置的回滚应当十分谨慎，以消除安全问题，直至开发团队对其进行妥善的处理。在实践中，我们最好通过保留旧版本的工件，直至新的部署被批准用于生产环境的回滚。

实施持续的漏洞扫描和监控

监控和测试CI/CD管道中的每个资源也是非常必要的。我们可以使用漏洞扫描工具利用已知漏洞的数据库，去测试应用代码、环境配置、以及部署脚本，进而消除潜在的受攻击媒介。此类扫描和监控工具应当被部署在整个SDLC中，以便在漏洞发生时，及时发现漏洞，进而避免漏洞被利用。

持续清理冗余资源

CI/CD管道通常使用不可变的基础架构来构建，这些基础架构在运行了特定的进程之后就会终止。由于攻击者可以使用临时资源的开放端口，来作为跳板进入已部署的环境，因此我们有必要合理地管理这些资源，以减少安全漏洞。在实践中，DevOps团队应确保在资源被终止后，及时清理包括容器、服务和虚拟机在内的所有临时资源。

CI/CD的安全层

管理CI/CD安全通常需要一种全面的、多层次的方法，以加强管道上每个节点的防御能力。下图展示了该安全层的逻辑结构： 安全CI/CD管道中的安全层

漏洞扫描

如前所述，漏洞扫描涉及到使用已知的威胁数据库，来识别和修复整个CI/CD管道中的安全漏洞。自动化的测试可以扫描指定的应用程序和部署环境，以识别和分类代码、基础设施、以及第三方服务中的弱点。

静态安全测试

此类软件组合分析技术，旨在识别内部开发团队编写出的代码中的潜在漏洞。安全团队可以经常使用这些工具，来开发测试用例，进而在部署新的应用程序构建之前，查明不安全的代码漏洞。

运行时安全

该层面主要依赖运行时应用自我保护(runtime application self-protection，RASP)工具，来实时检测生产环境中应用所面临的安全威胁。此类工具会扫描配置模板，并持续测试已部署的环境状态，进而通过比较，来识别和响应任何运行时威胁。

审计和监控

应用和基础设施的日志，会持续跟踪和存储应用与部署的相关数据。审计主要涉及到通过分析日志，以推断出可用于改善应用安全态势的模式。我们可以通过部署诊断工具，来监控和分析指标，以获悉与目标系统相关的问题。 持续的审计和监控可帮助开发团队，构建出对应的应用场景，并预测基线用户的行为。安全团队可以通过分析那些偏离已有基线的用户行为，来识别安全威胁。

结论

众所周知，任何有权访问源代码存储库或容器注册表的人，都可以在CI/CD管道中运行代码，因此DevOps工作流带有固有的安全隐患。根据最近的一项调查预计，大约55%的组织出于安全考虑，推迟了​​其应用程序的推出​​。虽然DevOps框架可以增强协作和自动化，但组织必须采用带有高级策略和工具的持续安全模型，来确保CI/CD管道在所有层面上都有统一的安全态势。