DevSecOps

本文约需 2 分钟阅读

DevSecOps 是指将软件开发 (Dev)、安全 (Sec) 与运维 (Ops) 融为一体，把安全嵌入开发生命周期各个阶段的方法。以往主流是临近发布时由安全团队进行检查的「守门人」模式，而 DevSecOps 会在设计、编码、测试、部署的各个阶段自动执行安全检查。它是一个由「安全是每个人的责任」这一文化变革和将工具集成到 CI/CD 流水线两方面共同构成的理念。

从 DevOps 的演进

DevOps 拆除了开发与运维之间的壁垒，使发布速度大幅提升。然而速度越快，安全审查就越成为瓶颈，这带来了新的课题。在一周部署数次的环境中，为每次发布都插入人工安全审查并不现实。为解决这一问题而诞生的，正是「左移」(shift left) 的理念。

传统: 设计 → 开发 → 测试 → 安全审查 → 发布

DevSecOps: Sec设计 → Sec开发 → Sec测试 → Sec部署 → Sec运维

左移是指将安全验证移动到开发流程的「左侧」(更早的阶段)。问题发现得越早，修复成本越低，并能大幅降低临近发布才发现严重漏洞而导致返工的风险。

将安全集成到 CI/CD 流水线

在 DevSecOps 的实践中，会将安全工具嵌入 CI/CD 流水线的每个阶段。这是一种开发者无需特别操作、只要推送代码就会自动运行安全检查的机制。

提交

SAST + SCA

构建 + 生成 SBOM

DAST

部署

运行时监控

SAST、DAST、SCA 的区别

SAST (静态分析)

在不执行源代码或字节码的情况下进行分析。检测安全编码违规以及 SQL 注入、 XSS 的模式。可从开发初期开始执行，但往往误报 (False Positive) 较多。

DAST (动态分析)

从外部对运行中的应用程序模拟攻击。能够发现实际可被利用的漏洞，但无法定位源代码中的位置。通常在预发布 (staging) 环境中执行。

SCA (软件成分分析)

检测依赖库的已知漏洞和许可证违规。作为供应链攻击的应对措施，其重要性急剧上升。 npm audit、 Dependabot、 Snyk 等为代表。

与 SBOM 的关系

SBOM (Software Bill of Materials，软件物料清单) 是软件所含全部组件的清单。以 2021 年美国第 14028 号行政命令为契机，要求政府采购软件提供 SBOM 的趋势加速。在 DevSecOps 的流水线中，会在构建时自动生成 SBOM，并与 SCA 工具联动，即时定位存在漏洞的组件。从合规的角度看，SBOM 也是在事件发生时迅速确定影响范围的重要资产。

安全冠军的角色

DevSecOps 的成功不仅需要引入工具，还离不开组织文化的变革。安全冠军 (security champion) 是配置在各开发团队中的安全联络人。他不是专职的安全工程师，而是掌握安全知识、在团队内部担任顾问角色的开发者。

“在每个团队各配置一名安全冠军后，对安全团队的咨询减少了 40%，漏洞修复速度提升到了 3 倍。最大的变化是开发者自身开始把安全当作自己的事来对待。”

在代码审查阶段融入安全视角的检查，也是安全冠军的重要职责。初创公司的安全体系构建请参阅初创公司安全检查清单，开源安全审计请参阅开源安全审计。关于供应链攻击的实际情况，也请参考供应链攻击解析。DevSecOps 实践书 (Amazon)可以进一步深入学习。

常见误解

最常见的误解是「只要引入工具，DevSecOps 就完成了」。即便把 SAST 和 DAST 集成进 CI/CD，若缺乏修复所检出漏洞的文化与流程，警报也只会被忽视。此外，「DevSecOps 是安全团队的工作」这一认识也是错误的，让开发者、运维人员、安全负责人三方协作的体制才是其本质。把安全作为「质量的一部分」融入开发流程，正是 DevSecOps 所追求的样子。