Continues Compliance 持续合规

Brief

持续合规是一种实践方式，它通过自动化手段，持续确保软件开发过程和相关技术符合监管与安全标准。人工的合规检查不仅会拖慢开发进度，还容易引入人为错误；而自动化的检查和审计则可以提供更快速的反馈、更清晰的证据以及更简化的合规报告。

通过在持续交付（CD）流水线中集成策略即代码（policy‑as‑code）工具（例如 Open Policy Agent），并生成与 SLSA 指南对齐的软件物料清单（SBOM），团队可以在早期就发现并解决合规问题。将规则和最佳实践“代码化”，可以在不制造流程瓶颈的前提下，在各个团队之间一致地执行统一标准。

OSCAL 也显示出作为一个在大规模环境下自动化合规的框架的良好前景。目前，围绕持续合规的实践与工具已经足够成熟，理应被视为“理性的默认选项”，这也是我们将其推荐级别提升到“Adopt（采用）”的原因。随着 AI 在编码中的使用日益增加，以及人们对 AI 生成代码可能产生“盲目信任”和“懈怠”风险的担忧，将合规嵌入开发过程本身比以往任何时候都更加关键。

来源：技术雷达

Guide

1. 什么是“持续合规”（Continuous Compliance）

可以这样向团队解释：

持续合规就是：
不再把合规当成“上线前最后几周临时抱佛脚”的一次性活动，而是像自动化测试和持续集成一样，把合规则做成一条自动化的“生产线”，贯穿整个软件生命周期。

关键要点：

• 持续性：不是一年一次审计，而是每次提交代码、每次构建都自动检查。
• 自动化：用工具和脚本代替人工勾勾画画的表格与文档。
• 嵌入流程：合规检查内嵌在 CI/CD 流水线里，而不是额外的一道“闸门”。

2. 为什么要从“人工合规”升级到“持续合规”

可以从三个角度来阐述：

1. 效率与交付速度
   • 人工逐条对照规范 → 审批周期长，拖慢发布。
   • 自动合规检查 → 每次提交几分钟内给出结果，开发人员能快速修复。
2. 减少人为错误
   • 人看几十页规范，很容易漏项或理解偏差。
   • 规则代码化之后，每次检查执行的都是同一套逻辑，可重复、可追踪。
3. 审核与证据留存
   • 监管或客户要求提供“你是如何达标的证据”时，自动化审计日志比 Word 文档更有说服力。
   • 工具可以生成时间线：某次构建是否通过了哪些安全/合规规则，为什么失败，何时修复。

3. 持续合规的关键技术与实践

可以按“实际落地要做什么”来拆分：

3.1 策略即代码（Policy as Code）

• 使用类似 Open Policy Agent（OPA） 的工具，用策略语言（如 Rego）把合规规则写成代码。
• 示例场景：
  • 限制哪些镜像仓库可以被使用；
  • 强制所有服务必须开启加密传输；
  • 禁止高危端口暴露在公网。

好处：

• 规则统一存放在代码库里，可版本控制、可 Code Review。
• 规则变更可以像代码变更一样走流程，避免“口头规定”失真。

3.2 在 CD 流水线中生成 SBOM 并对齐 SLSA

• SBOM（软件物料清单）：类似“配料表”，列出软件中所有依赖组件、版本和来源。
• 在 CI/CD 中自动生成 SBOM，并结合 SLSA（Supply-chain Levels for Software Artifacts） 的指导：
  • 明确每个构件的来源和构建过程是否可追溯；
  • 及早发现引入了存在漏洞或来源可疑的依赖。

这样可以：

• 快速响应像 Log4Shell 这类供应链漏洞：一旦有新漏洞披露，可以立刻知道哪些服务受影响。
• 满足越来越多法规对供应链安全透明度的要求。

3.3 使用 OSCAL 实现大规模自动化合规

• OSCAL（Open Security Controls Assessment Language） 是一种标准化格式，用来描述安全控制、评估结果和系统实现情况。
• 价值在于：
  • 把原本散落在文档里的合规要求结构化；
  • 让合规工具之间可以互通（不同系统都能读懂同一份 OSCAL 描述）。

对于大型组织或多云复杂环境，OSCAL 能帮助在多个系统之间统一描述与自动校验合规状态。

4. “Adopt” 的含义与为什么现在是“默认选项”

在很多技术雷达或最佳实践指引中，“Adopt” 通常意味着：

• 这项技术或实践已经足够成熟；
• 风险与成本可控；
• 推荐大多数团队在没有特殊原因的情况下优先采用，而不是“观望”。

把持续合规从“试验（Trial）/评估（Assess）”升级到“Adopt”，说明：

1. 工具生态已经比较稳定（OPA、各种 SBOM 工具、OSCAL 生态等）。
2. 大量实践证明，持续合规可以：
   • 显著减少发布前的合规阻塞；
   • 降低审计成本；
   • 提升安全与合规透明度。
3. 与现有 DevOps / DevSecOps 流程的集成方式已相对清晰。

因此，现在更合理的思路是：

默认做持续合规，只有在非常小的团队 / 非受监管业务下，才可以暂时不做或简化。

5. 在 AI 时代，为什么“把合规嵌入开发过程”更关键

AI 生成代码带来两类新的风险：

1. “看上去没问题”的代码实际上有隐患
   • AI 可能引入不符合内部编码规范、安全控制或许可协议的代码（例如使用 GPL 代码片段）。
   • 开发者因为“生成很快”，反而降低了对细节的警惕。
2. 责任与可追踪性变得模糊
   • 谁为 AI 生成的代码负责？
   • 如何证明某段代码在引入时通过了哪些合规/安全检查？

把合规嵌入开发过程，可以通过：

• 在提交或合并请求阶段，自动扫描 AI 生成的代码是否：
  • 使用了不允许的第三方组件或许可证；
  • 违反安全编码规范；
  • 没有满足数据处理与隐私条款（如访问日志未脱敏等）。
• 把检查结果与构建产物、提交记录绑定，形成可审计证据链。

这样，即便是 AI 生成的代码，也必须“通过同一套闸门”，避免因为“生成快”而“放松检查”。