从 DevOps 到 DevSecOps

针对 DevOps 领域的安全治理问题，Gartner 提出了 DevSecOps 概念。简言之，DevSecOps 是一种旨在将安全性嵌入 DevOps 链条中的每个部分新方法，它有助于在开发过程早期而不是产品发布后识别安全问题，目标是让每个人对信息安全负责，而不仅仅是安全部门。

DevSecOps 架构如下图所示：

针对上图，左边的“Dev 段”，聚焦软件开发过程的安全保障；右边的“Ops 段”，聚焦软件运行时安全。换句话说，“从一个软件或服务的角度，左边画个圈，保证了它‘生’来安全；右边画个圈，保证了它‘活’的安全。一个 DevSecOps，也就让它有了幸福的‘生活’。”

进一步看，这张图的左、右部分可以再拆成上下两段，因此出现四个象限。

• 第一象限的 Configure+Detect 阶段，可以理解为对应用程序的运行时的安全保障，比如容器和基础设施安全、RASP、WAF 等；

• 第二象限的 Plan+Create 阶段，从宏观上可以认为是在进行软件的安全设计与开发前准备，更注重安全规则的制定、安全需求分析、软件设计时的安全考虑；

• 第三象限的 Verify+Preproduction 阶段，即是对开发阶段进行安全保障，可以进行 AST、Fuzz、SCA 等；

• 第四象限的 Predict+Respond 阶段，可以理解为软件的在网安全监测，比如监测和响应安全事件等。

DevSecOps 概念的诞生，实际上伴随着“安全左移”的思想，即“更早”、“更快”地发现安全风险并（处理）。“六西格玛管理教过我们算过一笔账：问题发现越早，代价越小。以我理解，DevSecOps 的目标是在软件生命周期的全部阶段，可以更早、更快地发现并处理安全问题。而它之所以出现，是因为现有的软件开发（运维）流程无法支撑这一目标。”

DevOps 的基本诉求之一是要“快”，而安全保障却具有”快不起来“的特点。因为安全本身需要更为专业的知识背景，分析更复杂的攻击方式和潜在安全问题。并且，即使使用工具，其技术栈也深于普通的检查工具，这意味着耗时更长。比如，对源代码的静态检查，如果只是检查代码风格，他们可以做到快速扫描；如果需要进行安全编码的自动化检查，那么就需要进行流分析，甚至需要一个专门的编译过程来收集必要信息。

参考做法：一方面，抽取快速、简单、明确的检查工具或检查规则，将它配置到开发作业流的前端，比如 IDE、个人代码门禁，将厚重的内容放到后端，例如每日半夜自动触发的全量安全验证。另一方面，将厚重的内容进一步剥离形成异步模式，让它成为“慢轨”，不影响日常高速迭代的“快轨”车道。

正如 DevSecOps 宣言的起草者之一 Shannon Lietz 所说，不存在“one size fits all（一刀切）”的好事。公司级的安全团队会提供方法、规范、组件、基础技术和工具，而产品线对自己的安全质量负责。最后，安全团队提供方法、规范、组件、技术和工具。Shannon Lietz 曾提到，保障安全的工作是“非常有技术含量的工作“。而由安全团队所做的技术工作的成果落地到开发团队时，常常被认为是过于冗繁、小题大做。开发人员在被要求修改看起来不会影响程序正常功能的潜在问题时，就容易有抵触情绪。并且，安全类的检查工具常常伴有误报。

DevSecOps 秉承了 DevOps 的开放思想。未来发展有三个方向：

• 生态的开放：兼容并包，例如提供开放的集成能力（可以集成第三方，也能被第三方集成）、工具能力二次开发。不仅是规则定制，甚至可以将分析过程的中间结果也开放出来，以满足更灵活的定制化需求。

• 心态的开放：理解安全是更专业的话题，需要专业的解决之道，愿意学习安全知识而非抗拒，比如安全设计与编码规范。

• 从安全角度看，对“高效”的诉求尤其强烈。对此有深入理解的人认识到有一些安全的工作无法避免人工操作，这也意味着需要更长时间。举个例子，设计阶段的安全分析工作还没有太好的自动化工具；那些更专业的安全服务目前还无法实现全自动化。SAST 基于编译的增量分析还需要解决不少的问题，当提高检查敏感度参数时，就需要安全团队的专家协作进行代码人工检视以及工具告警的人工排查。

如何更高效地确保产品生命周期的安全，这将是 DevSecOps 的永恒课题。

文章部分素材源自：架构头条