企业安全之浅谈DevSecOps

前言

前面写了一篇关于SDL实践方面文章，但是目前越来越多的公司开始转向了devsecops体系的建设，看了一些关于这方面的文章，浅谈一下自己的理解。devsecops说白了就是devops+sec。在devops的开发流程下嵌入安全。

由于本人水平有限，文章中可能会出现一些错误，欢迎各位大佬指正，感激不尽。如果有什么好的想法也欢迎交流~~

开发模式的演变

在了解devsecops以前，有必要了解一下开发模式的演变过程，大致经历了三个阶段：瀑布开发，敏捷开发，devops。这三个阶段并无优劣之分，只是适应的场景不同。

瀑布开发

传统的开发模式，我们称之为瀑布开发。

瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。

这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。

适用场景：用户需求非常明确、开发时间非常充足

敏捷开发

目前随着市场竞争的加剧，传递的开发模型已经不太适合。等你把全部的功能开发完成上线，别人早就已经占领了市场，因此为了适应目前的环境，提出了敏捷开发。敏捷开发就是为了适应目前的互联网时代快速上线的需求，把大需求变成小需求，把大的时间周期缩小为短的周期，尽快上线运行。

适用场景：项目开发周期短，要求尽快上线

devops

敏捷开发加快了版本更新的速度，但是它还存在着问题，那就是开发，qa，运维还是各干各的，成为了新的瓶颈。这时候devops就被提出了。

适用场景：对敏捷开发的进一步补充，通过对各种工具的使用，进一步加快开发部署过程

简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

devops打破了开发与运维之间的壁垒，促进开发和运维人员的沟通，增进彼此的理解。在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

目前经常说的CI/CD可以说就是把devops从理论变成现实的一种方案。开发人员和测试人员，运维人员使用CI/CD流水线确保以快速、安全和可靠的方式创建和发布软件。

下面的图可以比较形象的看出来他们的区别

devops的工具支持

devops既然讲究快速更新迭代，那么使用人工的方式就是行不通的。必须要借助自动化工具的帮助，下面是devops流程中经常会使用的工具。

代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion

构建工具：Ant、Gradle、maven

自动部署：Capistrano、CodeDeploy

持续集成（CI）：Bamboo、Hudson、Jenkins

配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

容器：Docker、LXC、第三方厂商如AWS

编排：Kubernetes、Core、Apache Mesos、DC/OS

服务注册与发现：Zookeeper、etcd、Consul

脚本语言：python、ruby、shell

日志管理：ELK、Logentries

系统监控：Datadog、Graphite、Icinga、Nagios

性能监控：AppDynamics、New Relic、Splunk

压力测试：JMeter、Blaze Meter、http://loader.io

预警：PagerDuty、pingdom、厂商自带如AWS SNS

HTTP加速器：Varnish

消息总线：ActiveMQ、SQS

应用服务器：Tomcat、JBoss

Web服务器：Apache、Nginx、IIS

数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库

项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

devops带来新的安全风险

1）大规模使用容器技术带来的安全风险：镜像安全，k8s等平台安全，容器运行时安全，容器安全基线等

2）devops的微服务架构中存在大量的API接口，api接口的安全性如何防范也是需要思考的：api资产梳理，api漏洞检测

3）CI/CD平台的安全：如jenkins平台的安全

4）组件安全：为了快速交付使用了大量的第三方组件，这些组件的安全性也需要进行监控

上面这些说是新的风险，其实在以前也都见过它们的身影，如说的镜像安全说的也就是主机系统应用安全。只不过是原来的检测方式在新的背景下可能已经不在适用，需要考虑是如何适用新的检测背景。

devops给安全带来的挑战

上面了解了devops的一些基本概念以及常使用的工具，一种新的模式总会带来一些新的安全风险，在devops这种要求快速上线的模式下，传统的检测方式会拖慢整个项目的进度，会成为整个项目的瓶颈，因此devops给安全带来了新的挑战。

1）快速交付的背景下，传统的安全检测成为其瓶颈。DevOps追求的是持续集成、持续交付、持续部署，整个过程要实现业务价值的快速交付，而安全需求却成为其卡点。

2）devops使用了大量新的技术以及平台，这些带来了新的安全风险，而传统的安全没有覆盖这些检测项。

3）思维的冲突。devops打破了开发与运维之间的界限，但是安全还游离咋整个流程之外。部门之间的隔阂让开发和安全团队难以进行高效的协作

4）自动化程度低：DevSecOps流水线的落地需要自动化技术的支撑

5）安全能力薄弱：开发人员、运营人员等角色缺少安全意识和相关技能

这些就是devops给安全带来的挑战，现有安全保障方法无力匹配软件发布的速度。我们需要找到一种方式需要在兼顾快速交付的前提下同时保证安全。因此业界推出了devsecops，也就是适应devops开发模式的安全流程。

devops的安全问题主要就集中在如何在保证快速交付的背景下保证安全？

1.我们知道安全问题越早发现，修复成本就越低，因此安全要尽量的左移，尽早的发现安全风险并修复，这样修复时间和影响就会降到最低。

2.尽量使用自动化工具，传统的测试方式需要大量的时间，因此不适合目前的快速交付，可以通过使用自动化工具来进行漏洞检测。

3.仅仅依靠有限的安全人员是不可能保证安全的，因此需要将安全保证分布到开发和运维

devsecops简介

DevSecOps(Development Security Operations)，最早由Gartner咨询公司研究员David Cearley于2012年提出是一套基于DevOps体系的全新敏捷安全实践框架，整合了开发、安全及运营理念。

核心理念：安全是整个IT团队（包括开发、测试、交付、运营及安全团队）中所有成员的责任，需要贯穿软件生命周期的每一个环节。

从这个核心理念中可以看出与传统的安全相比较，devsecops将安全从安全人员扩展到了全体的开发人员，也就是开发人员也要为安全负责，另一方面就是安全要贯穿软件生命周期的每一部分。

DevSecOps主张将安全要素融入CI/CD流水线，重塑企业文化、流程、技术和度量体系，帮助企业逐步构筑一套适应自身业务发展、面向敏捷业务交付并引领未来架构演进的内生敏捷安全体系。

如下图，为RSAC 2018出现了一个新概念——Golden Pipeline，简单示意图如下：

在devsceops中，安全以人为本，用技术去驱动与软件生命周期同步规划，同步构建，同步运营。

devsecops工具集：

漏洞检测类：DAST（awvs,appscan等）,SAST（fority,SonarQube+Find Security Bugs，codeql（规定不能用于cI/CD流水线））,IAST（开源洞态，商用的）

组件检测类：sca（开源的组件检测工具opensca,Dependency-Check）

运行时应用自保护：RASP（百度曾开源了一个openrasp），BAS，EDR，UEBA

容器生命周期安全管理：镜像安全扫描，镜像基线缺陷检查，容器运行时安全检测，Kubernetes安全

其它工具：威胁建模工具，APP加固工具，应急响应工具等等

devsecops与SDL的区别

SDL与devsecops并无冲突，它们适应的场景不同，devops进一步的将安全融入流程，加入了更多的自动化，打破安全与业务的隔离。

devsecops软件生命周期建设

Gartner将整个软件开发、运营过程定义为了10个阶段：计划阶段(Plan)、创建阶段(Create)、验证阶段(Verify)、预发布阶段(Pre-release)、发布阶段(Release)、预防阶段(Prevent)、检测阶段(Detect)、响应阶段(Respond)、预测阶段(Predict)、改进阶段(Adapt)。

接下来看看在整个软件生命周期内，安全应该如何嵌入其中

计划阶段

软件生命周期目标：软件开发立项准备、需求分析、方案设计

嵌入安全工作：确定安全负责人，进行安全培训，安全需求分析与方案设计，威胁建模，安全需求库，确定安全编码规范，制定安全测试计划，编写安全测试用例

上面写了很多的步骤，但在实际的操作中可能会需要大量的人力以及时间，因此需要精简以及复用。如不同的项目可以复用安全编码规范，设计轻量级的威胁建模（最好能够自动化威胁建模）等等

创建阶段

软件生命周期目标：这个阶段主要就是开发开发代码的阶段，开发通过各种IDE工具进行代码的开发，然后将开发好的代码提交到代码仓库，并构建开发环境

嵌入安全工作：

1）通过IDE安全插件在开发开发过程中检测代码问题，这里需要开发能够根据插件报出来的安全问题进行修改，因此需要开发懂得一定的安全知识。如在IDE中安装findbugs插件。

2）开源组件检测：将SCA对接Git、SVN代码平台，集成到DevSecOps流水线，实现对待测软件增量、全量的检测，加强对组件的风险管理。

3）SAST：SAST也就是我们常说的代码扫描。SAST可以对接git,svn等代码仓库，也可以以插件的形式集成到jenkins的流程中，在代码提交时对代码进行静态扫描，而且为了嵌入CI/CD流水线和不过分地影响自动化效率，通常仅对待测软件增量部分进行SAST检测。建议对接代码仓库，这样对流程的影响比较小。常用的SAST工具有fority,codeql等

4）IAST：如果可以的话，这个阶段也可以接入IAST，在开发自测阶段就可以利用IAST进行检测。

验证阶段

软件生命周期目标：这个阶段主要就是开发自测完成，代码提交到代码仓库的测试分支，构建测试环境，然后测试人员进行测试的过程。

嵌入安全工作：

1）DAST：通过awvs,appscan等黑盒工具对程序进行自动化检测。

2）IAST：开发阶段可能已经上过IAST了，可能认为测试阶段就没有必要在用IAST了。其实测试阶段也还是要的。可以对开发阶段验证开发阶段的漏洞是否都已经全部修复。在不同的阶段同时使用SAST、DAST及IAST，结合各自的安全检测能力优势，及时、准确地发现更多的安全风险。

3）SCA：开发阶段通过sca可能已经将有问题的组件处理掉了。在测试阶段可以对上一步的效果做一个验证，同时测试阶段的组件资产已经相对固定，可以用sca梳理资产列表以及依赖关系。

4）AVC：AVC（Application Vulnerability Correlation，漏洞关联分析技术）是一种漏洞关联性管理技术，旨在通过将来自不同来源的漏洞。由于使用类型的应用安全测试技术，如IAST、SCA/OSS、DAST、SAST、渗透测试、模糊测试等，会产生不同标准和格式的漏洞结果，也会存在重复扫出同一个漏洞等情况，AVC可通过自动分析和关联漏洞合并，使开发人员可以直观地、有策略地修复漏洞，优先解决重要的安全问题，提高安全测试效率。

预发布阶段

软件生命周期目标：可以理解为试生产阶段，或者说是准生产阶段。在准生产环境下的检测，能得到更接近真实生产环境的测试结果

嵌入安全工作：

1）API模糊测试：API模糊测试与SAST、DAST、IAST等AST软件安全测试技术不同，AST是基于已知经验发现安全问题，而API模糊测试是通过随机的、概率学的方式去寻找安全问题，所以API模糊测试更容易发现未知的安全问题。API模糊测试是对惯常的例如AST等软件安全测试技术的有力补充。在准生产环境下的API模糊测试，更能够在接近生产环境的条件下发现安全问题。

2）容器镜像安全扫描：目前越来越多的企业开始使用容器去进行部署应用。在拉取镜像后、运行容器前，一定要对目标镜像进行安全扫描。

3）代码混淆，APP加固：通过这种方式对移动端软件进行逆向保护。

发布阶段

软件生命周期目标：在经过前面几轮的测试，系统可以正式进行发布并面向用户使用。这个阶段也代表着开发阶段的完成，正式进入运营阶段。

嵌入安全工作：

该阶段的主要工作就是防篡改

1）数字签名：防止软件产品被篡改，进而确保安全传递

预防阶段

软件生命周期目标：软件交付后的上线部署过程

嵌入安全工作：

该阶段主要工作就是签名校验，完整性检查以及纵深防御

1）校验数字签名：发布阶段软件包的数字签名进行校验，以确认是正规途径获得的未经篡改的软件包

2）软件包完整性校验：为了防止软件包在传递过程中被人恶意修改或者软件包中的文件被覆盖。在上线部署前就需要对软件包的完整性进行校验。

3）在上线时配置安全规则，如设置禁止/允许运行过程中预期的操作

4）嵌入RASP：在配置阶段嵌入RASP，使其能够在上线部署后的运营过程中及时发现问题并做出应对

5）BAS：BAS是Gartner反复提到的安全运营技术和工具。不同于以往渗透测试、漏洞扫描等以漏洞发现为主要目标，BAS以攻击为中心视角去看待安全风险，站在攻击者的角度看待组织的风险，通过模拟攻击者行为，验证组织内防御体系的有效性，做到对纵深防御体系持续改进和反馈。

检测阶段

软件生命周期目标：软件上线部署后的正常生产运营过程

嵌入安全工作：

论采取什么样的安全测试，都不能确保软件中的漏洞在交付前全部被发现，有些漏洞不可避免地会被带入到生产环境，因此安全监控在运营过程中是不可或缺的。

1）RASP运营：在部署阶段嵌入了RASP，在上线后的运营，用于生产环境的安全测试，以及主动防御。

2）容器运行监控：类似与传统的HIDS，监控容器的运行状态

3）线上黑盒扫描：上线后对系统进行黑盒扫描，验证前面的步骤是否还存留安全问题

4）UEBA：用户行为监控，通过监控用户的行为特征，发现异常请求

5）API威胁监控：对每个API请求和响应进行过滤，从不符合约束的API请求和响应中识别和防范相关威胁。

6）日志监控：收集与监控各种设备的日志

响应阶段

软件生命周期目标：软件上线后出现问题时进行相应，也是在运营过程。

嵌入安全工作：

1）主动防御：出现新的漏洞时，通过设置waf规则或者RASP的虚拟补丁进行临时修复

2）根据出现的具体问题采取措施进行响应，如安全编排技术

预测阶段

软件生命周期目标：这个阶段也是对应的上线后运营过程

嵌入安全工作：

借助前面阶段的情报信息和相关数据才能够对潜在的安全问题做出相应的预测，以便采取有针对性的安全措施解决安全隐患。

1）威胁情报：通过威胁情报信息，及时发现可能危害系统的风险并进行修复

2）漏洞情报：企业应当及时获取最新的漏洞情报，并快速识别漏洞对企业业务的影响范围，让企业能够在第一时间进行威胁处置，避免后续风险的扩散。

改进阶段

软件生命周期目标：承接本周期循环中前面九个阶段的同时，向下开启下一个周期循环，与下一个周期循环中的计划阶段连接，形成DevSecOps体系的持续运营

嵌入安全工作：

本阶段主要承上启下的作用，对上面的工作做总结，发现不足的地方并进行改进。如下面的几个方面

1）应急流程的优化

2）对欠缺的技术进行补充

上面的体系基本上包含了三个大的方面：安全风险发现（通过IAST，SAST等工具发现安全风险），安全防御（RASP，waf等进行防御）以及安全运营（威胁情报，RASP/WAF阻断等）。

上面就是Gartner对DevSecOps软件生命周期10个阶段的所要完成的安全工作，设计了很多的安全技术以及工具。可是在实际的工作中，又有几个公司能把上面的流程完整的建设起来。

以上“全套”的方案对大多数企业而言太贵了，在业务规模和安全投入没有达到理想化水平之前，只能做一些妥协和裁剪。可以先选几个方面做起来，后面在慢慢补充。一些工具如果有开源的也可以先用开源的代替。从小的改变做起，从易于自动化的安全活动做起，确保流程能够得到持续的反馈、优化和改进。

devsecops的其它要素

devsecops除了要柔和的嵌入到开发流程以外，还要在文化和技术方面做积累，文化，流程和技术三者携手并进，才能打造一个完整的devsecops。

文化

流程

上面已经说了devsecops的十个流程。在实践过程中逐步完善各个流程，实现敏捷安全的持续集成、持续交付、持续部署的工作流。

技术

技术方面要注意技术的积累与反馈，根据实际效果及时对各项技术进行调整，不断提高检测能力。要积累自动化的安全能力，建立全流水线的工具链。

总结

上面就是我对devsecops的一个大概理解，在目前提倡效率的环境下，越来越多的公司会加入到devsecops的实践中。

参考链接

《DevSecOps敏捷安全》子芽

https://xz.aliyun.com/t/12162