📚 课程目录第4章 CI/CD流水线中的安全关卡

4、CI/CD流水线中的安全关卡：代码扫描、依赖审计、镜像签名、部署前策略校验、运行时准入控制

在CI/CD流水线中，安全不能仅依赖最终的人工审核或渗透测试，而必须将安全关卡嵌入到每一个关键阶段。本章将系统阐述五道核心安全关卡：代码扫描、依赖审计、镜像签名、部署前策略校验以及运行时准入控制。每一道关卡都对应一个明确的合规边界，确保只有通过严格校验的制品才能进入下一阶段。

  核心原则：安全左移 + 持续验证。每一道关卡都是“门禁”，未通过则阻断流水线，并生成可追溯的合规报告。

4.1 代码扫描：SAST与密钥检测

代码扫描是流水线的第一道安全门禁，主要包含静态应用安全测试（SAST）和密钥/凭据检测。SAST在编译前分析源代码，发现SQL注入、XSS、反序列化漏洞等常见缺陷。密钥检测则防止开发人员将API密钥、数据库密码等敏感信息硬编码到代码仓库中。

扫描类型	检测目标	常用工具	合规要求
SAST	代码逻辑漏洞、注入、缓冲区溢出	SonarQube、Checkmarx、Semgrep	OWASP Top 10 覆盖
密钥检测	硬编码密码、Token、SSH密钥	GitLeaks、TruffleHog	PCI DSS、SOC2
IaC扫描	Terraform/K8s YAML 配置风险	Checkov、tfsec	CIS Benchmark

最佳实践：将代码扫描结果与CI/CD的“质量门”绑定。例如，设置“严重漏洞数 > 0”即阻断流水线，并自动创建Jira工单。

4.2 依赖审计：SCA与SBOM生成

现代后端应用超过80%的代码来自开源依赖。依赖审计通过软件组成分析（SCA）识别已知漏洞（CVE），并生成软件物料清单（SBOM）。SBOM是供应链安全的核心合规产物，记录了所有依赖的名称、版本、许可证和传递依赖关系。

# 使用 Syft 生成 SPDX 格式的 SBOM
syft packages your-image:latest -o spdx-json > sbom.spdx.json

# 使用 Grype 进行漏洞扫描
grype sbom:./sbom.spdx.json --fail-on high

合规红线：对于金融、医疗等受监管行业，必须确保SBOM中不包含GPL等强传染性许可证的依赖，且所有高危CVE必须在规定时间内修复（通常为72小时）。

4.3 镜像签名：内容信任与不可篡改

镜像签名确保容器镜像在构建后未被篡改，并且发布者的身份可验证。常用的签名工具包括Cosign（Sigstore项目）和Notary（Docker Content Trust）。签名过程将镜像摘要与签名者的私钥绑定，并将签名存储在镜像仓库或独立的透明日志中。

# 使用 Cosign 对镜像进行签名
cosign sign --key cosign.key your-registry/app:latest

# 验证签名
cosign verify --key cosign.pub your-registry/app:latest

特性	Cosign (Sigstore)	Notary (DCT)
密钥管理	支持密钥对、OIDC、KMS	基于TUF框架，需自建Notary服务
透明日志	默认集成Rekor	无内置透明日志
合规审计	签名记录可公开验证	需额外配置审计链路
生态集成	原生支持K8s、GitHub Actions	主要与Docker Engine集成

4.4 部署前策略校验：OPA与Kyverno

在将镜像部署到Kubernetes集群之前，必须通过策略引擎对部署清单（Deployment、Service等）进行校验。常用的策略引擎包括Open Policy Agent（OPA）和Kyverno。策略校验确保部署满足安全基线，例如：禁止特权容器、强制只读根文件系统、限制服务暴露范围等。

# OPA Rego 策略示例：禁止特权容器
package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  container.securityContext.privileged == true
  msg := sprintf("容器 %v 不允许使用特权模式", [container.name])
}

  策略即代码：将安全策略与应用代码一同版本化管理，通过CI/CD流水线自动测试策略本身的有效性，避免策略变更导致误阻断。

4.5 运行时准入控制：Admission Controller

运行时准入控制是最后一道防线，在Kubernetes API Server处理请求时进行拦截和校验。Kubernetes原生支持MutatingAdmissionWebhook和ValidatingAdmissionWebhook。前者可以动态修改Pod配置（如注入Sidecar），后者则严格校验请求是否符合策略。

生产建议：优先使用 ValidatingAdmissionWebhook 进行策略校验，避免 MutatingWebhook 因修改逻辑错误导致集群不稳定。同时，为 Webhook 配置超时和失败策略（FailurePolicy），防止 Webhook 不可用时阻塞整个集群。

4.6 安全关卡合规矩阵

下表总结了五道安全关卡与常见合规框架的映射关系，帮助团队快速定位每个关卡需要满足的审计要求。

安全关卡	PCI DSS	SOC2	HIPAA	GDPR
代码扫描	6.3.1	CC7.1	164.312(a)(1)	Art. 25
依赖审计	6.2	CC6.1	164.312(c)(1)	Art. 32
镜像签名	7.2.1	CC6.7	164.312(d)	Art. 5(1)(f)
部署前策略	1.1.6	CC5.2	164.308(a)(4)	Art. 24
运行时准入	10.5	CC7.2	164.312(b)	Art. 33

常见陷阱：不要将安全关卡全部放在流水线末尾。例如，代码扫描应在每次提交时触发，而不是在合并到主分支后才执行。延迟发现漏洞会大幅增加修复成本，并可能导致合规违规。

通过以上五道安全关卡的层层过滤，CI/CD流水线能够有效阻断不安全代码、漏洞依赖、未签名镜像和不合规配置进入生产环境。每一道关卡都生成可审计的日志和报告，为后续的合规审查提供完整的证据链。