DevSecOps 三问：Why？What？How？

作者 | 宗良

编辑 | 济萌

作者简介

宗良
文思海辉信息安全助理副总裁

现任文思海辉信息技术有限公司全球信息安全与风险办公室信息安全助理副总裁，负责文思海辉全球信息安全内控，以及对外的集成安全服务。15年以上从业经验，对软件开发/测试，服务与项目管理，信息安全与风险管控，质量与流程体系，培训体系与培训实施等多个方面都有深入理解与实际操作。

序言

随着 DevOps 的实际应用不断发展，Faster & Faster 的产品发布推陈出新，一个很严峻的问题有待解决：如何确保在快速迭代、快速发布过程中的产品安全，尤其随着《网络安全法》等一系列法律法规的完善与发布，这一问题已经上升到刑事责任而非过往的民事责任的高度。

安全与 DevOps 的整合已经迫在眉睫，本分享将就这一方面，介绍相应的 DevSecOps 的实际实施经验。

本文的三个部分：

1、Why DevSecOps;
2、What is DevSecOps;
3、How DevSecOps。

一、Why DevSecOps

1.1、传统的 SDLC 与传统的应用安全

首先跟大家的分享的是传统的 SDLC 与传统的应用安全。在整个传统的瀑布生命周期里面，大家可以看到运维是排在最后的，那么这跟安全存在什么样的关系呢？

通过上图，我们可见在运维过程里打相关的安全补丁是运维人员最常遇到的，也是最需要做的日常工作。

但是，实际上运维相关的安全工作并不是只有一个安全补丁。在打相关的安全补丁之前，还存在着许多工作，如：安全需求调研、安全设计工作、安全代码规范工作和安全测试。
1.2、敏捷模型对应的应用安全

下面我们讨论一下安全和敏捷是如何有效的结合的。首先是威胁建模和脆弱性检测：

威胁建模：这个课题已经存在很久了；但是在国内，就实践而言我个人来看并不是很完善。
脆弱性检测：从生命周期的角度来看，脆弱性检测是做什么用途的呢？如果软件本身的脆弱性已经做安全测试并觉得没有问题，但是为什么还有很多程序在服务器在生产环境中还是出现了问题？
原因很简单：因为这些漏洞来自于服务器本身的硬件、操作系统、数据库等核心中间件的漏洞，并且它们会深层次影响到部署在服务器上的应用。

故此，就需要用脆弱性检测这个方法预先找到漏洞。这个就意味着：你在一开发的过程中，需你要合理的考虑未来连接通道等等可能带来的问题。

接下来是两个测试——静态应用安全测试和动态应用安全测试。

最后是软件安全修复和安全代码培训。

1.3、标准的 DevOps 与应用安全

在 DevOps 整个运行过程中，持续集成和持续发布变得越来越快了，但足够安全么？

下面讲述一个真实的案例。我们有一个客户运用了 DevOps 系统，并且干的非常棒，从原来的每三周发一个大版本到现在基本上每天出76个版本。

但是，在安全方面系统持续地爆出来各种各样安全通知；然后，他的上级安全主管部门觉得他的安全管理非常差就给他发了一则安全整改通知并让其进行专项整顿。

那么在这个 Faster&Faster 的过程中，他做了测试、开发、检查；但是，他没有将安全特性融入进去，其后续的很多版本的 SQL 注入，跨站、中间人劫持这些最基本的安全问题都没有很好地进行修补。

对于上述的问题，我给大家讲几个概念：

1、SecOps：它的核心理念是自动化，其次是运营，同时把安全作为自动化的方式融进去。但是，EMC 公司本身没有特别好的产品，所以只是把这个作为一个服务方式来介绍给他公司的客户。在这个服务推出来以后，在当时也算业界相对比较领先的安全服务了。

2、SecDevOps：它产生时间是2015年8月17日，是偏向针对主机层的一个安全运维的专家服务。它的核心理念是早期风险建模，即上述讲到的威胁建模就是 SecDevOp。因此一定要在早期引入，越早期引入越好。

3、DevSecOps：它最主要的提出者是 SANS。SANS 是目前全球最大的安全的公益性、非商业化组织。对于 DevSecOps，SANS 在2016年3月发布一份白皮书。它的核心理念就是安全和 DevOps 实现共存和共赢，两者要整合在一起。

将威胁建模、安全早期的引入和信息安全融合在一起，这是我们深入地讲到的 DevSecOps 这个东西了。

二、What is DevSecOps

2.1、DevSecOps 的概念

在这个 DevSecOps 过程中，核心的思想内容就是用红色标注出来的部分：一个是自动化，第二个是内嵌整合。那么在整个过程中，我们会深入地看到几个东西：

威胁建模。威胁建模是整个 DevSecOps 里最重要的以及最核心的一个部分。对于威胁建模，我们会在后面章节还有详细的叙述。
整合集成。它就是把安全的各种活动作为一个整体集成在一起；同时把安全作为其中的一个基因整合或融入到 DevSecOps 的整个生命周期中。

在这个过程中，围绕开发的角度和运维的角度来看，会有很多的课题。这些课题有的是从安全的角度解决，有的是从安全的角度只能给出建议。

但是，不管是建议，还是解决的方式，或者是处置，那么它所带来的结果是什么呢？最常见的一个就是当我们发现问题的时候：

首先需要找到问题的识别成本。
第二，在发现问题之后需要进行分析成本。
第三，就是如何解决和预防成本，并且形成某种程度上的推力。

2.2、DevSecOps 聚焦

从 DevSecOps 聚焦的角度来看，这张图会很大，但是我们主要就是聚焦：文化、员工、产品、流程和技术，并且将安全融合进去。

2.3、DevSecOps = DevOps + Security Embedded

在本节，我首先给大家三个重要的提示：

第一个是自动化测试
第二个是持续测试
还有一个就是Embedded

这三个重要提示是整个 DevSecOps 里面最核心的问题。

为什么说这三者是最核心呢？首先，自动化的测试是在自动化和 DevOps 过程中，将安全基因整合进去。再则，持续测试其实是你要有策略的进行测试达到 TRUST。

TRUST 这个词在海外非常认可的，整个建设 TRUST 的过程中，最基本的就是威胁建模，无论何种情况下它会告诉你可能面临哪些安全隐患、威胁或者风险。

有朋友提到在没有与因特网连接的情况下，还有安全威胁吗？一个客户有A、B、C三个网络，A类网络与因特网没有物理上的直接连接，B类与因特网之间通过网闸进行逻辑隔离，C类网络是通过传统的防火墙进行逻辑隔离。

我们去审查客户环境的时候，客户问了一个问题：“我这个A类网络里面，你觉得还有必要进行安全防护吗？”。我回答他这需要从两个有两种可能性角度去看。

第一种，你现在没有与因特网连接，但在未来因为业务或者其他特殊需求而改变了现在的部署方式，就要连接因特网了；那么在这以后，就会发现整个网络错漏百出。
另外一种，现在不能直接触碰到你的网络，但我可以通过其他手段接触，比如：用无人机作为中继平台就可以触及到你的网络了。故此，在安全领域，有一个安全工具叫无人机反制系统，就是针对这种情况。

上述这个例子就揭示了我们为什么会需要威胁建模？威胁建模不仅要从应用本身来考虑，还要考虑应用所在的主机和中间件等等。因为这是最基本的部分，它带来的就是安全设计。这意味着一个良好的设计可以减少很多的安全隐患。而安全设计在我们的很多的过程中，并不会被那么重视，不管在架构中，还是在算法中。

接下来说说安全的测试。它有很多内容：第一个是 SAST，第二是 DAST。在这个过程中，我们把安全作为基因持续集成到开发和测试。这时候会出现一个问题就是在怎么样的情况下使用什么样的安全策略，比如我们有很多的版本（大版本、小版本、里程碑版本），以及安全测试的强度不一致的问题。同时，我们一定要挑出其中跟版本最有关联的，使其在安全本质上保持一致。

例如：在全球，我们有一个调查机构叫 Verizon。它每年会出一个叫全球数据泄露调查的报告。在2016年的数据泄露调查报告里面，此机构做了一个在全球范围内的统计：“97%的漏洞是来自于我们每年经常看到的 OWASP Top 10” 。

OWASP Top 10这个漏洞会在安全测试的时候成为我们进行安全分级策略的一个重要输入来源。也就是说，对于小版本而言，我们只测这10个漏洞有没有最基础的呈现就可以了。它就相当于功能测试里最基础的冒烟测试。

如果这个都不能过，就不用考虑版本发布的事宜了。但是对于大版本或是重要的里程碑而言，我建议不要只测这10个漏洞了，还需要参看两个数据（一个是讲全球漏洞的 CVE，另一个是讲***方式的 CAPEC）。如果你的产品偏向于应用层，我建议你看 CAPEC；如果产品偏向于网络层，我建议看 CVE。

对于开发过程来说，我们非常建议的是要进行安全状态的评估。很多的客户在做开发的时候会有缺失，也就是说他们做了检测，甚至做的威胁建模，但是却没有做安全状态的评估。

所以，当生命周期走到发布的时候，就无法判定能否发布，因为不知道这个版本有没有安全隐患以及安全隐患会不会造成影响。其实这个问题产生的根源在两个部分：

第一，前期没有威胁建模；
第二，没有规划好安全测试的分级策略，导致做安全状态评估的时候无法记性操作了。

如果我们做好上述这些的话，自然就能得出一个是否是安全的定论。然而，安全测试里面除了要做 SAST 和 DAST，还有 FUZZ 和法律法规的检测等等。由于出台国家网络安全法，所以我们必须要对策略合规性进行合理的考虑（这个合规是合法法律，规是指行政法）。

最后，我要将的就是***测试了。***测试是模拟***进行***的一个测试。从我个人观点来说，***测试还是很有意义的。但是，大家需要注意的是：随着网络安全法的出台，不管是甲方组织进行***测试，还是乙方去做***测试，都一定要注意合法合规。简答来说，合法合规的***测试是需要进行报备授权的，也就是说：有报备的叫***测试，没报备的叫******或者被定性为破坏计算机系统罪行。

总结一下，上述我们主要谈论到了三个地方。

第一个就是刚才谈到自动化；
第二个是把安全作为基因整个融入到 DevOps 过程中；
第三个就是 Embedded。Embedded 意味着什么呢？用中文是柔性，柔性项目管理，柔性生命周期，柔性就是不是那么硬，不是强制要求，自发自动主动的去做；否则的话，只能是前面讲的那几个词 SecurityDevOps。

DevSecOps 是什么？是把安全嵌进去了，融入在其他，这才是它真正的核心，这才是它真正的价值所在。

三、How DevSecOps

在整个DevSecOps过程中，存在四个问题：

如何设计你的 DevOps 整体的框架，然后把安全融进去；
安全怎么整合；
自动化配合 Self-Driven 自驱动；
V&V 就是质量保证和质量控制。

因此，我们需要更多检测系统和更多的相关东西，并将这些作为一个整体融在一起，那怎么融？我个人建议，有三种方式：

第一种是以 DevOps 为核心，并把安全集成到发布过程中，这是一种最常见的融合方式。
第二种是把安全作为一道关卡，这也是我推荐的一种方式。比如说冒烟测试就必须通过，如果这个时候不做却在以后发现问题，那么安全就不知道要在哪个阶段放进去了。
对于我门来说，是先做完功能性能的测试，然后再去做安全测试，还是先做安全测试再去做别的呢？这是一个很实际很尖锐的一个问题。那么，这个就取决于你对实际产品和环境策略的把控了。
但是，从安全的角度出发，我建议安全前置，这个是为什么呢？因为 DevSecOps 有个很重要的隐藏概念叫 Shift Left。它在某种程度上是独立的以及嵌进去的，意味着在需求早期就要做威胁建模，而在整体设计前也要做安全设计。
安全要走在每一个阶段的前面，否则到后面 Faster&Faster 的时候你就没时间做了。这其实是一个很关键的核心，你没有 Shift Left 以后就没办法把安全整合进去就更别谈 Embedded。
第三种是测试驱动开发，现在是安全驱动整个 DevSecOps，这个概念来自于哪里？它的来源是：在 Github 有人提供这个东西的原代码。但是现在它还是原形的东西，所以怎么做就显得太激进了。
实话说，我认为安全是要服务于业务，而不能凌驾于业务之上。某种程度上这个方式有点凌驾于业务之上的，所以并不是我推荐的，我推荐的还是第二种。

3.1、安全的自动发布特性和安全控制特性

上图是一个很典型的自动化发布的模块架构。在这个自动化模块的架构里面，安全放在在哪里？没有的话，就是会带来种种的问题。因此，我们需要一个安全的自动化发布，并考虑把安全性融进去。这就意味着在一起规划时候，你就要将安全性考虑进去。

3.2、实例问题感悟

下面讲一个真实的案例。我们有一个客户上了 DevOps 系统后感觉非常棒。因为，他从原来每三周发一个大版本到现在每天出76个版本。数据显示上很厉害，但是安全方面持续地爆出来各种各样安全通知，然后上级主管部门觉得这个客户安全管理的怎么这么差，就给他发了一则整改通知，叫专项整顿。

虽然，他做测试、开发、检查了，但是他跟安全的特性没有融进去，然后很多的版本，SQL 注入，跨站、中间人劫持这些最基本的问题，甚至包括前段时间的想哭病毒，他们都有轻微的感染现象。

后来我们帮助客户上了 DevSecOps 干，并且我们跟客户一起去搞。最后的结果，他的76个应用系统、232个发布单元，全部实现了对应的 DevSecOps。有人问具体工具怎么做的：首先，商业化工具，其实也就那些大家熟悉的譬如 Fortify、AppScan 之类；此外，用了一些开源的工具；最后，就是也会自研一些东西，自研的东西一定结合客户场景和应用、实际环境。

3.3、DevSecOps 未来可以整合的元素

对于 DevSecOps 的未来从个人角度说，我认为有六个地方是需要与整个 DevSecOps 进一步深度结合的：

第一和第二是人工智能AI和态势感知。在现今而言，其实AI和态势感知是 DevSecOps 中很重要的一个环节。对于态势感知，大家可能从运维的角度或者从安全的角度听说了很多。但是，在我所见到众多的态势感知系统，其本质上不是态势感知系统，而就是一个 SIEM 统一日志平台。
可是，在国外并不是这样的。例如：大概两年前我跟客户讲 SIEM 不是态势感知，而是 SOAPA；那个客户在前段时间突然间打电话给我说“我终于理解你跟我讲的 SOAPA 是什么事情了”，这个作为小故事这里分享。
那么我的意思是我们要理解整个趋势，并且考虑规划我们的发展，在这个过程中，这六个地方是我看到的能够与 DevOps 整合的或者与 DevSecOps 整合的最大的六个方面。
第三个是智能物联。现今在很多情况下我们讲 DevSecOps 还只是传统应用。但是，现今对于 ICS 系统来说某种程度上还是一个空白的区域。
第四个是自动建模。上面我们所谈到的威胁建模是 DevSecOps 一个重要的输入来源和重要的基础。但是，自动建模意味着纯粹靠人工建模会需要极其庞大的工作量。目前，自动建模都没有比较成熟的产品。
第五和第六是法律法规和证据保全。这两点就是要告诉你出事儿了怎么办以及需要什么样的证据来证明做过哪些事情。因为，电子证据在法律法规上是有要求的，而现在我们系统里很多东西是不能直接作为证据的。尤其，在金融行业里面，一旦发生重大信息安全事故或者重大灾难的时候，电子证据就成为一个很重要的法律证据。

总之，这六个趋势都可以独立和 DevOps 或 DevSecOps 进行整合，同时也可以拆分开来分别整合到 DevSecOps 中去。那么这些趋势的本质是什么？本质是我们需要跟上持续的潮流。

比如，五年前在中国你跟人讲 DevSecOps，99%的人会问什么叫 DevSecOps？而今天你跟人讲 DevSecOps，5%的人可能已经在做了 DevOps，剩下80%的人是了解一部分内容的，剩下15%的人才是对 DevSecOps 一窍不通的。

END