Arch Day 130
Arch Day 130: CI/CD与供应链安全 — 从GitOps到SLSA Level 3
现代CI/CD不仅是"自动化构建部署"，更是软件供应链安全的核心控制点。2026年，每一次构建都必须回答：谁构建的？用什么代码？产出是否被篡改？
2026-08-07
第五阶段 - 云架构深度CICDGitOpsArgoCDSLSASigstore供应链安全
日期: 2026-08-07 (Day 130) 阶段: 第五阶段 - 云架构深度 标签: #CICD #GitOps #ArgoCD #SLSA #Sigstore #供应链安全
核心概念
一句话定义
现代CI/CD不仅是"自动化构建部署"，更是软件供应链安全的核心控制点。2026年，每一次构建都必须回答：谁构建的？用什么代码？产出是否被篡改？
知识点详解
1. CI/CD平台选型
| 平台 | 优势 | 适用场景 |
|---|---|---|
| GitHub Actions | 生态最广、Marketplace丰富 | 开源项目、GitHub全家桶 |
| GitLab CI | 自托管最佳、内置安全扫描 | 合规严格的企业 |
| ArgoCD | K8s GitOps标准 | Kubernetes部署 |
| Dagger.io | 用编程语言定义pipeline（非YAML） | 需要跨CI平台可移植性 |
| Tekton | K8s-native CRDs，2026.03 CNCF Incubating | 云原生CI/CD |
2. 供应链安全——SLSA v1.2
| Level | 保证 |
|---|---|
| L0 | 无保证 |
| L1 | 构建过程有文档化provenance |
| L2 | 加密签名provenance，检测构建后篡改 |
| L3 | 检测构建过程中篡改，强制隔离 |
GitHub Artifact Attestations使用Sigstore签名，可达SLSA v1.0 Build L3。
3. GitHub Actions安全加固
- Immutable Actions: release资产和Git tag不可更改/删除
- SHA Pinning策略: 组织级强制action pin到commit SHA
- 关键风险: 第三方action本质是第三方代码，tag可被恶意指向不同代码
4. Progressive Delivery
| 策略 | 原理 | 工具 |
|---|---|---|
| Blue-Green | 新旧同时部署，一次性切换 | Argo Rollouts |
| Canary | 少量流量→逐步扩大 | Argo Rollouts / Flagger |
| Progressive | 基于KPI自动决策 | Argo Rollouts + Prometheus |
面试题
问题：如何保证CI/CD pipeline的安全性？
回答：1) SLSA Level 2+：每次构建生成签名provenance；2) 依赖锁定：lock文件+hash验证；3) SHA pinning：GitHub Actions固定到commit SHA而非tag；4) 最小权限：CI/CD用临时凭证(OIDC federation)而非长期密钥；5) SBOM：每次构建生成软件物料清单。