本文目录导读：
CI/CD流水线的安全性至关重要，因为它是现代软件交付的核心，一旦被攻破，攻击者可以植入恶意代码、窃取密钥、篡改制品，甚至控制整个生产环境，一个不安全的CI/CD流水线相当于把通往生产系统的后门钥匙交给了攻击者。
下面从攻击面（风险点） 和最佳实践（防护措施） 两个维度来拆解CI/CD流水线安全。
CI/CD流水线的主要风险点（攻击面）
- 源代码及版本控制系统（SCM）：如GitHub、GitLab、Bitbucket。
- 风险：开发者凭据泄露、不安全的
git历史记录（包含密钥）、分支保护规则不严格（允许直接push到主分支）、第三方应用过度授权。
- 风险：开发者凭据泄露、不安全的
- CI/CD编排器：如Jenkins、GitLab CI、GitHub Actions、CircleCI。
- 风险：插件漏洞、配置错误（如
sudo权限）、运行环境隔离不足、平台的API Token泄露。
- 风险：插件漏洞、配置错误（如
- 构建环境：编译、测试、打包的临时或持续运行的容器/虚拟机。
- 风险：使用过时或包含已知漏洞的基础镜像、构建过程中引入恶意依赖（依赖混淆、投毒）、不安全的临时文件处理。
- 依赖与制品仓库：私有及公有仓库，如npm、PyPI、Maven、Docker Hub、Harbor。
- 风险：使用带有已知漏洞（CVE）的依赖、内部仓库遭受供应链投毒、制品签名机制缺失，导致被篡改。
- 凭证与密钥管理：用于访问数据库、云服务、第三方API的密码、Token、SSH密钥。
- 风险：将硬编码的明文密钥写在代码或CI/CD配置文件中、使用长期有效的密钥（而非短期临时凭证）。
- 生产部署环境：Kubernetes集群、云服务器、边缘节点。
- 风险：不安全的部署策略（如滚动更新失败回滚出问题）、部署后的运行时安全监控缺失。
CI/CD流水线安全最佳实践（防护措施）
可以遵循 “纵深防御” 原则，从代码提交到部署进行全链路防护。
代码与SCM安全（源头）
- 启用分支保护规则：强制要求Pull Request（PR）评审、通过自动化测试、禁止绕过。
- 密钥检测：在git pre-commit hook或CI触发器中扫描提交，防止密钥、Token、证书等敏感信息入库。
- 工具：
git-secrets,talisman,truffleHog。
- 工具：
- 最小权限原则：减少第三方集成（如GitHub Apps）的权限，仅赋予Pipeline所需的最小范围。
凭证管理（最核心环节）
- 绝对禁止硬编码：永远不要在
.env、Dockerfile、配置文件或代码中写入明文凭证。 - 使用密钥管理服务：
- 云原生：AWS Secrets Manager、Azure Key Vault、GCP Secret Manager。
- 工具集成：HashiCorp Vault、CyberArk Conjur。
- 短期动态凭证：优先使用临时、自动轮换的Token（如AWS STS假定角色、OIDC身份认证），而非长期有效的静态密钥。
- CI/CD平台内建功能：GitHub Actions Secrets、GitLab CI/CD Variables，并启用保护（仅允许在特定分支/环境中使用）。
依赖与供应链安全
- 依赖漏洞扫描：在CI Pipeline中集成SCA（软件组成分析）工具，自动检测所有第三方库的CVE。
- 工具：Snyk、OWASP Dependency-Check、Trivy、GitHub Dependabot。
- 建立私有仓库：对公司内部使用的、镜像过的、经过审核的制品进行统一管理，避免直接拉取公网仓库。
- 依赖锁定：使用
npm-shrinkwrap.json、poetry.lock、go.sum等锁文件，确保构建可复现且未被篡改。 - 容器镜像签名与验证：使用Cosign、Notary等对构建的容器镜像进行数字签名，部署前验证其完整性与来源。
构建环境安全
- 临时且隔离的环境：使用一次性、隔离的容器或VM执行构建，避免状态残留（如使用Kubernetes的临时Pod）。
- 最小权限执行：Pipeline内的进程使用非root用户运行，限制操作系统命令（如禁用
sudo）。 - 基础镜像安全：使用从安全、受控的镜像仓库拉取的、经过最小化裁剪的基础镜像（如
distroless），定期进行镜像安全扫描。
安全扫描与合规检查（嵌入Pipeline）
将安全检查作为Pipeline的强制关卡,集成在构建、测试、部署的每个阶段。
- SAST（静态应用安全测试）：在代码提交后检查源代码中的安全漏洞（SQL注入、XSS等），工具：Semgrep、SonarQube、CodeQL。
- DAST（动态应用安全测试）：在生成了可运行的测试环境后，模拟攻击测试运行中的应用，工具：OWASP ZAP、Burp Suite、Arachni。
- IaC（基础设施即代码）扫描：检查
Terraform、Kubernetes YAML、CloudFormation等模板中的配置风险（如存储桶公开访问、IAM权限过大），工具：Checkov、tfsec、kube-bench。 - 策略即代码：定义规则（如“不允许ROOT用户运行容器”），并在Pipeline中自动执行，阻断不符合规范的构建。
部署与运行时安全
- 不可变部署：不使用SSH登录修改正在运行实例，而是通过替换整个镜像、容器或虚拟机来更新。
- 灰度发布与回滚：使用Blue/Green、Canary部署策略，配备自动回滚机制（当部署后的健康检查失败时）。
- 部署后监控：利用运行时安全工具（如Falco、Aqua Security）监控异常行为（如反弹shell、加密矿工进程）。
一张安全的CI/CD流水线检查清单
| 阶段 | 检查项（是否已启用？） |
|---|---|
| 代码提交 | □ 开启了分支保护？ □ 配置了Pre-commit密钥扫描？ □ 所有PR都通过了评审？ |
| Pipeline配置 | □ 凭证是动态/来自密钥管理服务，而非硬编码？ □ Pipeline使用了最低权限的运行账号？ □ 构建环境是临时且隔离的？ |
| 依赖管理 | □ 集成了SCA工具扫描漏洞？ □ 使用了依赖锁文件？ □ 内部制品仓库已启用？ |
| 安全测试 | □ 集成了SAST（代码扫描）？ □ 集成了DAST（运行时扫描）？ □ 集成了IaC扫描（配置检查）？ |
| 制品构建 | □ 基础镜像经过安全扫描？ □ Docker镜像已签名？ □ 制品存储在不可篡改的仓库中？ |
| 部署阶段 | □ 使用了不可变部署？ □ 开启了自动回滚？ □ 部署后触发了运行时安全监控？ |
最佳实践并非一蹴而就，建议从最核心的风险点入手：① 解决密钥硬编码 和 ② 引入依赖扫描，这两步能消除绝大多数常见的CI/CD安全事件，然后逐步扩展至SAST、DAST和IaC扫描，最终形成完整的、自动化的安全流水线。
