强化锻造：技术深度探讨 CI/CD 流水线的安全

Source: Dev.to

持续集成和持续交付（CI/CD）流水线提供的快速迭代和部署能力已成为现代软件开发不可或缺的一环。它们使团队能够更快、更高效地向用户交付价值。然而，这种速度和自动化也带来了新的攻击面。被攻破的 CI/CD 流水线可能导致灾难性后果，包括注入恶意代码、未授权访问敏感系统以及声誉受损。本博客深入探讨了保护 CI/CD 流水线的关键要点，提供可操作的策略和技术示例。

CI/CD 流水线：信任链

在其核心，CI/CD 流水线自动化了构建、测试和部署软件的过程。它通常包括以下几个阶段：

• 代码提交： 开发者将代码更改推送到版本控制系统（例如 Git）。
• 构建： 代码被编译，获取依赖项，并生成制品。
• 测试： 执行各种测试（单元测试、集成测试、安全扫描）。
• 部署： 将制品部署到不同的环境（预发布、生产）。

每个阶段都可能成为潜在的漏洞点。保障 CI/CD 流水线的安全需要整体性的方法，将整条链视为一个整体，并在每一个环节确保信任。

Source: …

CI/CD 的关键安全支柱

1. 安全的源码管理 (SCM)

任何 CI/CD 流水线的基础都是源码仓库。保护它至关重要。

• 访问控制： 实施强身份验证和授权机制。使用基于角色的访问控制 (RBAC) 只授予开发者必要的权限。
  示例： 在 GitHub 中，利用团队和分支保护规则。例如，限制直接推送到 main，并要求关键分支的拉取请求至少获得两次批准。

• 分支保护： 配置分支保护规则，防止直接提交到生产分支。合并前必须通过拉取请求、代码审查以及通过 CI 检查。
  示例： main 分支的保护规则可能包括：

  • 合并前必须通过状态检查（如成功的构建、安全扫描）。
  • 至少需要一位代码所有者的批准。
  • 禁止强制推送。

• SCM 中的机密管理： 切勿将机密（API 密钥、密码、证书）直接提交到代码库。使用专用的机密管理解决方案。
  示例： 对于构建期间需要访问的敏感环境变量，使用 GitHub Secrets 或 GitLab CI 变量，并将其标记为 “protected” 和 “masked”。

2. 安全的构建代理和 Runner

构建代理是执行构建和测试脚本的机器或容器，通常拥有提升的权限。

• 最小权限原则： 为构建代理配置最小必要权限。避免以 root 或管理员身份运行。
  示例： 若使用 Docker 进行构建，在容器内以非 root 用户运行 Docker 命令，或使用 Docker 的无根模式。

• 短暂的构建环境： 使用在每个作业完成后即被销毁的短暂构建代理。这可以降低持久性妥协的风险。
  示例： 采用容器化的构建代理（如 Docker、Kubernetes Pod），为每个作业启动后即丢弃。Kubernetes 等编排工具能够高效管理此类流程。

• 定期更新与补丁： 保持构建代理的操作系统和所有软件均为最新的安全补丁。
  示例： 为构建基础设施实现自动化补丁管理，或使用不可变镜像，在每次部署时用已打好补丁的镜像完整替换旧代理。

• 网络隔离： 将构建代理与生产网络隔离。仅允许必要的出站连接。
  示例： 使用网络安全组 (NSG) 或防火墙规则，限制构建代理子网的出站流量，仅可访问内部制品仓库和外部依赖源。

3. 安全的流水线配置与编排

CI/CD 工具本身（如 Jenkins、GitLab CI、GitHub Actions、CircleCI）是需要保护的关键组件。

• CI/CD 平台的访问控制： 保护对 CI/CD 平台的访问。为所有用户启用多因素认证 (MFA)。
  示例： 为 Jenkins 管理登录或 GitLab/GitHub Enterprise 账户启用 MFA。

• 流水线即代码： 将流水线定义（如 Jenkinsfile、.gitlab-ci.yml、GitHub Actions 工作流）存放在 SCM 中。这便于版本控制、审计以及对流水线变更的同行评审。
  示例： 一个定义构建和测试阶段的 .gitlab-ci.yml 文件：

  stages:
    - build
    - test
  
  build_job:
    stage: build
    script:
      - echo "Building the application..."
      - mvn clean package
    artifacts:
      paths:
        - target/*.jar
  
  test_job:
    stage: test
    script:
      - echo "Running unit tests..."
      - mvn test
    dependencies:
      - build_job

• 参数化与输入验证： 对流水线运行时用户提供的任何参数进行清理和验证。
  示例： 如果流水线接受部署环境作为参数，需确保它只接受合法的环境值，例如 dev、staging、prod，并拒绝其他任意输入。

Source: …

重新定义安全值（例如 staging、production），而不是任意字符串。

• 审计日志： 为 CI/CD 平台内的所有活动启用全面审计日志，以检测可疑行为并支持取证调查。

4. 安全的制品管理

构建过程产生的制品至关重要。必须安全存储并防止篡改。

受信任的制品仓库

使用安全的集中式制品仓库（例如 Nexus、Artifactory、AWS ECR、Docker Hub）。

• 示例： 将 CI/CD 流水线配置为将构建好的 Docker 镜像推送到 ECR 仓库，并从该仓库拉取进行部署。

制品访问控制

对制品仓库实施严格的访问控制。只有授权的流水线和用户才能推送或拉取制品。

• 示例： 为 AWS ECR 配置 IAM 策略，仅允许特定 CI/CD 角色向特定仓库推送镜像。

制品签名

对制品进行签名，以验证其完整性和真实性。

• 示例： 使用 Sigstore 或 GPG 等工具对 Docker 镜像或 JAR 文件进行签名。部署流水线随后可以在部署前验证签名。

5. 流水线中的安全测试（左移安全）

在流水线中尽早且频繁地集成安全测试至关重要。

静态应用安全测试（SAST）

在不执行代码的情况下分析源代码中的漏洞。

• 示例： 将 SonarQube、Checkmarx 或 Bandit（针对 Python）等工具集成到构建阶段，以扫描代码中的常见安全缺陷。

软件组成分析（SCA）

识别开源库和依赖项中的已知漏洞。

• 示例： 使用 OWASP Dependency‑Check、Snyk 或 Trivy 等工具扫描项目依赖，查找已知 CVE。

动态应用安全测试（DAST）

对运行中的应用进行漏洞测试。

• 示例： 在部署到预发布环境后，运行 OWASP ZAP 或 Burp Suite 等 DAST 扫描器，识别 Web 应用漏洞。

容器镜像扫描

扫描容器镜像中基础操作系统和已安装软件包的已知漏洞。

• 示例： 将 Trivy 或 Clair 集成到 Docker 构建过程，扫描生成的镜像是否存在漏洞。

6. 安全的部署与基础设施

部署目标也需要安全防护，部署过程本身必须可信。

基础设施即代码（IaC）安全

像对待应用代码一样保护 IaC 配置（如 Terraform、CloudFormation），并对其进行安全误配置扫描。

• 示例： 使用 tfsec 或 checkov 等工具在应用 Terraform 配置之前，扫描其是否符合安全最佳实践。

部署最小权限

为 CI/CD 流水线授予部署到生产环境所需的最小权限。

• 示例： 为云环境部署使用具有限制性 IAM 角色的专用服务账户。

不可变部署

尽量实现不可变部署，即通过 替换 现有实例来部署新版本，而不是就地更新。

• 示例： 在 Kubernetes 中，使用更新后的应用镜像部署新 Pod，然后优雅地终止旧 Pod。

高级安全考虑

• Threat Modeling: 对 CI/CD 流水线进行威胁建模，以识别潜在攻击向量并设计适当的防御措施。
• Secrets Rotation: 定期轮换 CI/CD 流水线和已部署应用程序使用的密钥。
• Incident Response Plan: 为与 CI/CD 流水线相关的安全漏洞制定明确的事件响应计划。

结论

确保 CI/CD 流水线的安全不是一次性任务，而是持续的警惕和不断改进的过程。通过：

• 实施强有力的访问控制，
• 采用针对构建代理和制品管理的安全实践，
• 在开发生命周期的早期集成安全测试，以及
• 加固部署基础设施，

您可以显著降低被攻破的风险。将您的 CI/CD 流水线视为关键资产，并在每个阶段进行加固，以维护软件的完整性和用户的信任。