青藤云安全：DevSecOps发展与解决方案

青藤云安全首先介绍了DevSecOps的发展历程，将安全融入开发和运维中，让安全更好的前移以取得更好的效果;其次说明了DevSecOps的解决方案以及相关的工具，如何让DevSecOps更好的落地;然后提到了容器安全，因为容器是让DevSecOps更好落地的基础设施，容器安全从某种意义来说是DevSecOps的基础安全;最后提到了DevSecOps的最佳实践。

引发DevSecOps的这个概念背后有很强大的变化，安全一般来说是服务于其他信息技术，如果相应的技术或者解决方案或者流程发生变化，安全也要随之改变，否则无法适应新的技术的安全要求。这里面的最重大的变化有三个：开发流程的变化;技术架构的变化;IT基础设施环境的变化。

传统的软件开发流程分为六个阶段：需求、设计、开发、实现、部署、维护。最常见的开发模型就是瀑布式的开发流程，将所有的阶段进行规划，然后执行。这样的流程好处就是阶段明显，但是最大的弊端就是只要一个阶段发生延期就会导致所有的延期，而且每个阶段需要的人不一样，互相沟通的机制也很少。瀑布式开发模型会极大的拖慢整个开发周期，所以引入了敏捷开发来解决这个问题。敏捷开发解决的核心问题就是持续交付，让软件的交付周期变短，是一个增量的、迭代式的开发模式。可能不是一次性交付所用的功能和特性，而是在每一次交付中有一些功能和特性的交付。开发人员这样的交付速度，很明显会给安全人员带来挑战，怎么在每一次的迅速交付中来保证安全?敏捷开发的流行必然形成了DevOps的趋势，即开发运维一体化。

技术架构也由之前的单体应用向微服务架构调整。之前开发的产品基本属于单体应用，大部分仅需进行进程内通信即可完成相关的功能。但是随着解决问题的复杂性水平越来越高，同时为了更好的提高可用性以及运维的可维护性，引入了微服务的理念和架构。微服务很明显的好处就是拆散了系统的复杂性，降低了系统的耦合性，提高了系统的可维护性。同时也可以在高可用、平行扩展上天然支持，而不需要外部运维组件支持。微服务的架构也需要安全人员关注的粒度要足够细，之前可能只用关注一个应用的安全即可，对于微服务架构每个服务的安全都需要关注。

传统的IT技术架构的变化也是惊人的。目前上云的趋势已经成为主流，大部分公司的数据中心已经云化，无论私有云、混合云还是公有云。云计算除了带来了很好的节省成本的优势，同时也带来了效率和速度的提升。尤其是云原生应用的兴起，一切组件和相关的服务都在云端解决，自动化水平空前提高。特别提到的容器技术这个虚拟化技术可以更好的加快DevOps的落地。

从人员的角度来看，因为需求部门和开发部门的壁垒，敏捷开发出现了，持续交付的过程中让需求和开发部门更好的沟通，而这种情况会引发开发和运维的矛盾，为了更快捷的交付引入了DevOps这种组织和实践。在DevOps的过程中发现，安全的问题需要考虑进来，按照历史的惯性，一开始只是开发运维走到了一起，安全的要素还是事后考虑，大部分的情况下安全人员还是属于事后处置，安全效果没有得到很好的提升，一个很明显的现象是开发人员在部署最新的技术架构，而安全人员还在关注传统的安全问题。为了解决这个问题，所以在整个流程中加入了安全的人员形成了DevSecOps这种协同机制或者特殊岗位，可以让安全人员更早的介入开发和运维的过程，让安全的措施向前移动，主要的目的是让所有的技术人员都对安全负责。

DevSecOps角色交叉图

在之前微软提出的SDL流程中更多是侧重于威胁建模(Threat modeling)，注重的阶段全是在产品研发阶段，忽略了运维的阶段。DevSecOps刚好同时解决了开发和运维的安全问题。在实施DevOps过程中，实际的安全挑战比较大，通过下面的Gartner统计图可以发现DevOps团队跟安全的协作是他们首要考虑的问题。

DevOps关心问题统计图

在DevSecOps的实际人员配比中，开发人员、运维人员以及安全人员的比例是100:10:1，安全人员的配备是最少，同时交付的频率又是很高的，大概是一天一个交付。安全的问题也很突出，做过的历史经验统计大概每千行的代码Bug数量是0.5-10个区间，同时在222行代码中就可能有5个直接引用库，可能高达54依赖库存在。同时在DevOps的过程中，运维人员的工具化水平已经比较高，大部分流程都是通过自动化的工具进行处理。

DevOps运维工具集

这就要求安全人员在充分了解这些特点的前提下采取相应的安全解决方案，直接考虑的就是高度自动化，需要相关的安全产品来支撑DevOps的特点。DevSecOps的架构需要跟运维的工具集做相关的对应。

DevSecOps相关工具示意图

考虑到DevSecOps的安全问题核心问题是应用安全，可以通过应用安全进行考虑。参考应用测试的安全产品和理念进行思考。

2018年应用安全测试产品魔力四象限

应用安全测试产品核心能力在DevOps下的得分

关于应用安全测试产品的核心能力主要有三种：静态代码扫描(SAST);动态外部扫描(DAST);交互式应用测试(IAST)。静态代码扫描和动态外部扫描都是比较常见的应用安全手段。静态代码扫描的优点是可以支持多语言并且容易理解，缺点是准确率很低，对于执行流不可见，而且需要很多的客户配置的规则。动态外部扫描可以做到应用平台无关性，可以很好地支持手工测试调试，但是缺点也很明显比如覆盖率很低、需要安全专业背景才可以解释、执行效率较低等。交互式的应用安全测试方案可以很好地结合上述两种方式的优点，准确率极高，实时性很高，可以看到代码执行流，很灵活地用在各种环境，也不需要额外的配置等。

各种测试方案的对比图

如果现实情况允许的情况下，可以将IAST的方案升级到实时应用保护(RASP)，在测试环境可以使用IAST，在生产环境使用RASP。主要的区别是IAST重在测试，通过CI/CD集成，不阻止访问;而RASP重在生产环节，可以进行阻止操作，可以替代WAF这种产品。但是两者功能实现原理基本一致，可以做到一种结合。

IAST和RASP区别和联系

目前软件开发有个趋势就是开源软件的兴起。就以Java开源组件来看，年下载量以指数规模增长。所以开源软件漏洞以及授权合规的问题就显得重要起来。

Java开源组件10年来下载数量

软件组件分析(SCA)作为一个很重要的部分被提及，主要就是针对开源软件(OSS)以及第三方商业软件来发现漏洞以及合规问题。

2019Q2的SCA波形图

这个领域还属于比较新兴的阶段，Black Duck被Synopsys收购后迅速补全了这个领域，是这个领域比较领先的公司，还具有开源软件漏洞分析的能力，并且有自己对开源漏洞的编号。WhiteSource可以根据实际使用的组件给出风险建议。

再说到容器安全。容器作为DevOps的比较友好的基础设施，其特点可以很好的促进DevOps的落地，可以说以后的DevOps的基础设施。容器安全也就是DevOps的基础设施安全。容器的采用率上目前已经很好，在使用率上已经达到了81%，无论是在测试环境还是生产环境，容器的年度下载量也已经达到120亿。

容器采用率示意图

近4年容器下载量

容器安全需要关注的安全分为以下几个方面：

第一、HostOS安全。对于HostOS，应该本着够用即可的方式，因为HostOS本身并不需要跑什么应用，所以只要保证基本的容器环境即可，也可以有效降低攻击面。方式有几种：自己编译，也有其他商场的专门为容器而生的操作系统，比如Red Hat、 Enterprise Linux、 Atomic Host、CoreOS、Ubuntu Core、VMware (Photon OS)、Microsoft (Nano Server)、RancherOS等。

第二、关注镜像扫描和配置扫描。镜像扫描主要关注镜像中的漏洞以及可能存在的组件的漏洞，这个跟上面提到的SCA分析开源漏洞有相关性。同时要关注HostOS的合规以及容器本身配置的合规性。CIS也为Docker专门编写了标准来符合相关的标准。

第三、网络隔离性。在微隔离提出后(Micro segmentation)，容器的隔离叫微微隔离(Nano segmentation)。容器间的隔离更多是以粒度更细的隔离方式，能够在API或者服务层面进行隔离，可以有效增强业务的可视性并加大了攻击扩散的难度。

第四、实时监控。容器的实时监控安全是最重要的防入侵环节。采用的方式有多种，包括：Agent安装在HostOS上、启动特殊权限容器、在每个容器中部署一个安全层、直接锁定模式等。现在比较主流的是启动特殊权限容器，这样部署起来更容易一些。

其他还有几个方面就不展开讨论了，包括对容器编排系统比如Kubernetes的支持，以及IAM领域在容器的实现等。

容器安全领域在美国目前有多家公司涉及其中，其中比较领先的是TwistLock和AquaSec，都很好的解决了上述提到的安全问题。

综上所述，笔者只是从技术领域来进行DevSecOps的讨论。如果需要从技术上对内部做安全产品的评估，可以参照下表进行对照，是否产品得到了很好的使用。

DevSecOps自动化评估表

本文主要围绕DevSecOps的发展和解决方案来展开。讲解了DevSecOps的发展由来和面临挑战，重点描述了技术的解决方案，尤其是IAST&RASP和SCA产品在应用测试产品的出现以及它们解决的问题，最后讲解了容器安全的一些要求。在DevSecOps的风潮下，安全自动化越来越重要，同时也是软件供应链最大的变化，这个不仅仅是要求软件交付的企业，对于采购软件的企业，也要把安全的要求附件到软件开发的企业中来完善这种安全的制度以及流程。

新一代主机安全趋势研讨会（深圳站），限额报名中，扫码报名：