本文是 DZone 2026 Trend Report 中一篇 DevSecOps 实践指南的读后笔记。原文按流水线从前往后的顺序，介绍了安全 CI/CD 的五个关键阶段：先定基线和风险等级，再把安全检查左移到开发早期，用代码化的策略自动拦截违规配置，通过软件物料清单看清依赖链，最后用零信任和 AI 修复加固整条流水线。
基线：风险分级与 KPI
安全 CI/CD 流水线的底层逻辑很简单：尽早扫描、保护访问、管好密钥、检查基础设施、降低供应链风险、在发布前强制执行控制。一条典型的路径是 开发（快速反馈）→ 预发布（更广的验证和发布检查）→ 生产（最强的门控）。
门控（gate）就是代码进入下一个阶段之前必须通过的自动检查，像安检门一样，不通过就拦下来，不让继续往前走。生产环境是真实用户在用，所以门控最严。
关键在于按风险分级设置门控强度。高风险变更（生产部署、基础设施变更、依赖更新、权限变更）走更强的门控，常规工作保持轻量快速。这样才能兼顾速度和安全性。
原文给出了一套 KPI 体系，覆盖效率、质量、安全、流水线健康四个维度：
| KPI 类别 | 指标 | 含义 |
|---|---|---|
| 效率 | 构建时间 | 流水线完成一次构建的平均时间 |
| 效率 | 部署频率 | 新代码发布到生产的频率 |
| 质量 | 变更失败率 | 部署失败需要回滚或热修复的比例 |
| 质量 | 代码覆盖率 | 自动化测试覆盖的代码比例 |
| 安全 | 密钥暴露事件 | 在提交或流水线检查中发现密钥的次数 |
| 安全 | 漏洞检测率 | 自动扫描发现的安全问题数量 |
| 健康 | 流水线成功率 | 流水线运行成功的比例 |
| 健康 | 平均修复时间 | 修复已检测安全问题的平均时间 |
Stage 1：左移扫描，但不制造噪音
左移（Shift Left）的意思是把安全检查尽可能往开发流程的前端移。扫描对象包括源码、第三方依赖、密钥和凭证、容器镜像、基础设施即代码（IaC）模板、运行中的应用、流水线配置文件。
但 全量扫描 ~ 和 ~ 快速反馈 之间存在矛盾。原文给出的解法是 PR 和主分支采用差异化扫描策略：
- PR 扫描：只跑核心检查（密钥、代码、依赖、基础 IaC），目标是快速反馈，不阻塞合并
- 主分支扫描：加全量依赖扫描、容器镜像扫描、流水线文件检查，有时加 DAST（动态应用安全测试）
还有个容易被忽略的问题：噪音。如果流水线报告太多 findings，团队会开始忽视它们。解决方法是只阻塞最明确、最严重的问题，低风险 finding 留到后续审查。已批准的例外和简单的审查规则也能防止同一个已知问题反复失败。
Stage 2：策略即代码（Policy-as-Code）
Open Policy Agent（OPA）在这里扮演中央策略引擎的角色，在部署之前检查 Terraform 计划、Kubernetes 清单等配置，确保只有合规的变更能继续往前走。
Terraform 是管理云基础设施的工具，Terraform 计划就是 terraform plan 命令生成的变更预览，列出了将要创建、修改或删除的云资源（比如 AWS 上的 S3 存储桶、虚拟机等）。OPA 在部署前审查这个计划，拦截不安全的配置。
OPA 策略通常覆盖四类规则：
- 依赖风险 ：阻止包含已知严重漏洞或来自不可信源的包
- 许可证规则 ：识别项目或公司不允许的依赖许可证
- 密钥保护 ：防止 token、密码、密钥、证书在流水线中流通
- 部署和环境规则 ：控制应用可以部署到哪里、允许哪些基础镜像、需要哪些安全设置
原文给了一个 Rego 策略示例，阻止创建公开访问的 AWS S3 bucket：
package terraform.security
# 如果任何 S3 bucket 的 'public' 被设为 true，则拒绝
deny[msg] {
# 遍历 Terraform 计划中的所有资源变更
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket"
# 检查公开访问设置是否被启用
resource.change.after.public == true
msg = sprintf("安全违规：S3 bucket %s 不允许设为公开。", [resource.address])
}
这个策略的使用方式是把 Terraform 计划转成 JSON，然后交给 OPA 评估：
terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
opa eval --input tfplan.json --data policy.rego "data.terraform.security.deny" --fail-defined
当策略违规被检测到时， opa eval --fail-defined 返回非零退出码，流水线自动失败。
策略本身也需要治理：放在版本控制中、在 PR 中审查变更、记录审批人。例外必须包含明确理由和截止日期，不能永不过期。
Stage 3：SBOM，知道你的软件里有什么
SBOM（Software Bill of Materials，软件物料清单）是 DevSecOps 的核心实践。它的价值在于：
- 看清直接依赖和传递依赖
- 提高供应链可追溯性
- 出现严重漏洞时能快速定位影响范围
- 增强合规和审计准备
SBOM 通常在构建阶段生成，随构建产物一起保存，并发送到安全平台做持续检查。同时还要保存 构建证据 ，证明产物来自可信流程，事后未被篡改。
原文给出了一个 CycloneDX 格式的 SBOM 示例，展示了策略检查时会评估的数据结构：组件名、版本、purl（包 URL）、哈希值、许可证信息。
在 SBOM 上可以加安全门控：阻止包含被禁许可证或高危漏洞的组件；阻止未知或未签名的产物；检查 drift，即产物、镜像或依赖是否偏离了最初批准或构建的状态。
Stage 4：零信任，不信任流水线中的任何部分
把零信任应用到 CI/CD 意味着：默认不信任流水线的任何部分，不管是代码、用户还是构建 agent。不依赖网络边界，而是持续验证每一次访问和每一个操作。
具体做法从 用短期身份替代长期密钥 开始（比如 OIDC）。每个流水线阶段只拥有它需要的权限（最小权限原则），runner 与环境的其他部分隔离，尽量使用短期 runner。
密钥和部署权限需要持续管理：定期轮换密钥，人员角色变更或离开团队时审查部署权限。只有受信任的镜像和构建产物才能往前走，不安全的配置、未批准的组件、有风险的构建被策略直接阻断。每次部署都要保留清晰的审计记录：谁触发了部署、什么时候、涉及哪个提交和产物。
Stage 5：安全的 AI 自动修复
这是原文最具前瞻性的部分。把 AI agent 引入 DevSecOps 流水线，修复工作从手动、被动变成自动、主动。AI agent 可以扫描代码变更、识别风险模式、排定优先级，然后建议甚至直接应用修复。
但 AI 驱动修复也引入新风险：目标劫持（goal hijacking）、中毒记忆（poisoned memory）、被操纵的上下文。OWASP Agentic Security Initiative（ASI）和 AI Security Verification Standard（AISVS）提供了安全使用 AI agent 的指导框架。
一个关键概念是 Least Agency （最小自主权）：agent 只应该拥有完成任务所需的最小自主权。在实践中，这通常意味着 agent 准备 修复方案，然后走正常的 review 流程再合入，而不是直接自动提交。
还需要区分"什么可以自动修"和"什么必须人工审"：
| 可以自动修复 | 必须人工审查 |
|---|---|
| 小范围依赖更新、版本提升 | 访问控制变更 |
| 简单配置修复 | 安全策略变更 |
| 遵循已知模式的代码修复（低风险、范围明确） | 生产部署逻辑 |
| 共享基础设施 | |
| 关键业务代码 |
回滚和隔离也同样重要。如果 agent 做了一个有问题的修复，必须能停止发布、回退变更、快速回到上一个良好状态。追踪是哪个 agent 操作导致的变更，限制自动化变更可以走多远。
量子安全加密
原文还有一节讲量子安全加密：不是说现在就要把所有加密算法都换掉，而是先摸清家底，搞清楚代码、库、容器、平台设置中哪些地方用了加密，跟踪哪些算法是批准的，用策略检查阻止弱算法，维护一份以后需要更新的系统清单。这事对长期数据保护、密钥交换和数字签名最重要。
可观测性
流水线安全应该是可度量的。有用的指标包括策略检查失败频率、生产前拦截了多少严重漏洞、修复时间、例外数量。自动保存日志、SBOM 记录、构建产物详情、策略审批、例外记录，这些在审计和事件响应时都是关键证据。
小结
这篇指南把 DevSecOps 描述为一个从"检测"到"执行"的演进，不只是发现问题，而是用策略门控、流水线保护、更快更精准的响应来系统性地解决问题。2026 年的趋势是 AI 修复、短期身份、供应链策略门控、以及把流水线本身作为攻击面来保护。AI agent 安全、可审计性和人工审批正在成为标准要求，不是因为 AI 不可靠，而是因为安全流水线 必须 可追溯、可回滚、可问责。