在RSA大会中，“下一代应用及IT基础设施的安全管理模式”，被提升到了前所未有的高度，大会甚至专门为这个概念和方向设置议题和讨论会，一个新晋热词“DevSecOps”出现在大家的视野中。
“DevSecOps”，一种全新的安全理念与模式，从DevOps的概念延伸和演变而来，其核心理念为安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发到运营整个业务生命周期的每一个环节。
看到这个概念，第一反应是“安全运维”，是不是新瓶装旧酒呢？确实一直以来，不论从主机安全还是到网络安全，很多工作都是安全运维的交集，既涉及到安全，同时也涉及到运维，没有运维足够的支持很多安全工作也比较难开展。但是经过一段时间，发现最初的理解实际比较片面，刚才提到的并不是真正DevSecOps所要传达的理念，DevSecOps的出现是为了改变和优化之前安全工作的一些现状，比如安全测试的孤立性、滞后性、随机性、覆盖性、变更一致性等问题；通过固化流程、加强不同人员协作，通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内，让安全属性嵌入到整条流水线。
由于本人知识和经验有限，对DevSecOps的理解可能只停留在比较浅显的认知。
目前我在工作中能真正涉及和可以应用的有两部分，第一块是在资源管理，第二块是在CI/CD这部分，监控告警、日志分析、或者其他内容，怎么应用到DevSecOps中我本人还没有很成型的思路。
资源管理这块，我们用到的，主要是依赖于YRDCMDB系统“银河”来实现的，CMDB里存储了宜人贷的所有主机、IP、域名、集群、应用等所有软硬件信息，这样在进行安全检查、安全扫描的时候，就可以直接调用银河来获取完整的信息、或者直接调用银河来执行一些简单的扫描任务。
宜人贷端口监控从银河获取IP信息完成对应的端口扫描。
基于资产管理可以更快速、准确的知道新上线的域名、应用等，从而触发安全扫描，减少遗漏。
在主机安全方面，我们未来也打算基于CMDB来做更多的联动，因为CMDB本身就自带“远程采集”和“远程执行”的属性。
DevSecOps中的安全自动化测试（扫描）当我们谈到S-SDLC的时候，总是希望安全可以更早的介入，但是随着项目的增多、迭代频率的增加，完全依赖人工测试的方式不但会压垮安全测试人员本身，也会严重影响到整个软件交付的速度，拖累整个上线周期，最终很多应用在得不到任何安全检查的情况下偷偷上线。
为了提升效率，可以将部分自动化的安全检查工作纳入到CICD的流程中，并且将大部分流程自动触发和执行，让安全测试人员可以聚焦到更核心的业务和工作上，同时尽可能减少安全测试工作对软件发布带来的时间消耗。
代码静态安全检查有商业化的解决方案比如Coverity，我们这里使用的是开源解决方案，Sonar+FindbugSecurity，根据需求精简了规则，在持续构建的过程中，会进行代码静态安全检查。
第二阶段，当完成功能自动化测试后，可以进行安全自动化测试（扫描）。在这里我们简单封装了开源的漏洞扫描工具，将扫描任务、漏洞执行描述、结果等信息通过WEB方式进行展示，方便统一使用和管理。
下面这张图是我们未来想要继续改进的方向，大致思路如下：
在各个业务的功能自动化测试平台集成安全测试用例
√ 功能测试平台主动调用安全测试平台（传入登录操作所需的信息）
√ 安全平台模拟登录后，开始进行扫描
√ 最终将结果反馈给CI平台
这里涉及到和功能测试自动化团队的协作，对于成熟的测试团队，让他们来实现一个登录初始化的数据并且构造一些业务数据，应该不是很难的事情，这样安全测试人员就不再需要去维护每个业务的登录去构造数据了，有了登录和一定的业务数据，安全扫描的效果也会好上很多。
用DevSecOps理念来解决第三方组件的漏洞问题
在软件开发中，安全人员还经常遇到的问题就是来自第三方组件的安全漏洞应急，比如今年发生的Struts2、fastjson等漏洞，都是在软件开发过程中引入的，这块儿是比较好和DevSecOps相结合的。
不考虑入侵排查的因素，正常的响应流程一般为1DAY高危漏洞爆发，安全人员获取和验证POC之后，在WAF中添加恶意请求特征，缓解风险，同时推进补丁升级。传统的方式一般是人肉统计、或者通过批量命令执行检查线上服务器的制定目录和文件、lsof进程所打开的文件等，这样的方式，第一容易出现遗漏且效率低下，第二应急结束后未来又有新的系统发布再次引入了该漏洞组件后，并不能及时发现。
这里我们引入了XRAY+统一发布的方式来解决这个难题。在构建过程中，会根据漏洞库进扫描二进制文件，一旦发现包含高危漏洞的组件被引入，可直接告警或直接阻断发布。
XRAY的工作方式如下：
√ 文件HASH比对
√ 可对接多个漏洞库：NVD、Blackduck、Whitesource、Aqua等
√ 支持深度分解检测：从docker镜像、到rpm包、war包、jar包等，层层分解，进行扫描
甚至根据漏洞库的修复方案，可直接对受影响版本自动更新版本号以及解决依赖升级问题（这个我没有验证过）。这里想针对docker多说两句，线上环境的一致性和变更管理其实很困难，我觉得docker很大的一个好处就是解决了环境一致性问题，因为每次都需要重新构建，从OS到组件再到应用，无形之中也对漏洞修复工作带来了便利性，修复效率有所提升。
每次构建的软件都保存在仓库中，可以快速筛选出使用的第三方组件，比如fastjson
而通过统一发布平台和仓库的关联，则可以快速找到哪些项目包含了带漏洞的组件，并且之前已经被发布到线上环境，做到快速筛查。
总结
DevSecOps这个概念提出来的时间虽然不长，而且和以往S-SDLC的思路也有一些交集，但是却再次定义了安全在软件工程中的重要性以及结合方式；在敏捷思想和DevOps已经足够成熟的今天，相信未来会有更多思想被提炼出来、也会有更多的最佳实践来提高安全工作的效率。
