随着导游词|网络技术的反复更新，信息安全领域的内涵也不断发展，安全研发技术的地位也日益凸显。 作者来自腾讯安全云鼎实验室，最近参与了《研发运营一体化(DevOps)能力成熟度模型》等安全部分的标准制定，这次将向大家分享他对研发安全和DevSecOps的理解和实践尝试。
云计算得到普遍应用，微服务等基础设施成熟，同时随着企业业务高速发展带来的观音出厂维更高效的要求，企业开发的运维模式也从传统的瀑布模式到敏捷模式，再到敏捷模式
安全模式也发生了变化，但其核心始终一致，是更前面的安全。 其中“DevSecOps”是Gartner 2012年也提出的DevOps模式下的安全概念，每个人都要为安全负责，业务、技术、安全合作生产更安全的产品。
http://www.Sina.com/http://www.Sina.com /
如果你问“如何收敛产品的安全漏洞”，得到的答案可能是安全测试。如果问题改为“如何减少产品中漏洞的出现”，那么答案可能是“减少漏洞代码”。
其实从两个问题得到的答案对应着两个防御理论。 一个是漏洞防御，另一个是威胁防御。
漏洞防御系统从防御的角度看类似于导弹防御系统这样的性防御，面对的对象是可以识别的，也就是说修复和防御已知的明确的安全漏洞。
这种方式的优点是模式简单，能迅速、有效地发挥效果。 但问题也很明显，这是单点方式，实际上因为适合攻击，所以存在不全面、未知的风险。
这是一种增加攻击成本的方式，我要填补漏洞，加上防御措施，如果普通黑客想突破我的系统，就必须突破导弹防御系统。 也就是说，如果防御方发现没有修复或没有增加防护措施的安全问题，攻击成本就会变高。
另一方面，威胁防御系统实际上是在软件开发的整个生命周期，甚至包括运输阶段挖掘潜在的安全威胁，从威胁建模、安全设计、安全测试等多个角度削减威胁，建立防御手段
与漏洞防御系统相比，这里的威胁不必是已经形成的安全问题，任何潜在的威胁都必须建立应对手段加以识别和削减。
优点是明显的、更系统、更全面，但更系统、更全面，需要更多的时间，增加总体执行周期，同时要求各阶段都有安全的动作，操作复杂度高，安全覆盖度更高
以前，我们在利用SDL、IPDRR等模型组织具体的停机系统时，实际上是将两种理论结合起来创建的。
从漏洞与威胁防御说起
返回软件安全开发，访问
统计来自forresteranalyticsglobalbusinesstechnographicssecuritysurvey，2019，图为《SDL已死，应用安全路在何方？》 [1]
为什么要关注APP应用的安全？ 关注软件开发的安全性吗？ 这是Forrester的调查统计，从图中可以看到，在更前置的安全上，攻击者的目标安全漏洞仍然在软件安全领域持续渗透。
上图显示了开发运维不同阶段的漏洞修复成本。 可见越早成本就越低，漏洞也越容易修复。 因此，软件安全需要更左移，更靠前。
不管是SDL还是DevSecOps，其中主要强调的一个就是安全前置或者安全左移，就是更早的在软件开发生命周期嵌入安全动作，就能更容易的收敛安全漏洞问题
http://www.Sina.com/http://www.Sina.com /
SDL由微软提出并应用企业的攻击风险点依旧是以应用漏洞为首，重点关注软件开发的安全保证流程，旨在开发安全的软件APP应用程序。
SDL的核心理念是越早的收敛漏洞成本越低，而软件安全开发模型就是用于解决的方案需求分析、设计、编码、测试和维护。 在需求、设计和产品发布阶段，添加了适当的安全活动以减少软件漏洞并最大限度地减少安全缺陷。
实际上，如下图所示，从表中可以清楚地看到需要在各个阶段进行的各种安全活动。 大致的执行流程如下。
SDL模型的核心是安全设计的核心原则。
其他相对容易理解，这里侧重于攻击面的最小化和默认的安全性。
最小化攻击面实际上主要有两个，一个维度可能是暴露的CGI等是攻击点，减少不必要的接口等。 另一种是即时暴露也应该限制访问范围缩小攻击面。
默认安全性意味着在设计产品时，必须考虑某些配置的默认项目处于安全状态。 例如，某些安全开关必须默认打开。
>在SDL模型里，还有个很重要的执行要点，那就是威胁建模，威胁建模是在需求设计阶段的一项识别和消减威胁的重要手段。关于威胁建模，微软提出的一个方法叫做“STRIDE”。STRIDE威胁建模其实就是基于数据流图去识别不同环节是否存在仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证的一个过程。
其中六个维度的威胁大家通过表格里的安全属性就可以看到它其实是基于信息安全基本要素制定的。额外提及一下，由于隐私安全关注的爆发，也成为了第七个安全威胁。具体这里就不对威胁建模展开说明了，大家有兴趣可以通过文末扩展阅读内容进行学习。
经常有同学会对几个关键词混淆不清，SDL、S-SDLC、SDLC，接下来额外做下解释，好帮助大家理解。
如上图所示，通过英文全称大家应该就可以看得出区别，前两者都是安全开发生命周期，第三个是软件开发生命周期。
至于S-SDLC和SDL有什么区别呢？S-SDLC是由开源Web安全组织OWASP推出的一个项目，它跟SDL的区别是它更关注的是SDL的落地化。
DevOps与DevSecOps
要讲DevSecOps就必须先介绍下DevOps，就涉及到软件开发模型的变更。
这是一个软件开发运维的流程，一开始可能是一个角色负责所有阶段，当系统变得复杂化后，于是几个角色就被区分出来，分别是开发、测试、运维。
针对这样一个流程，最经典的一个模型是瀑布模型：
就是一个阶段做完再到下个阶段，我们会发现这是一个很低效的过程，于是后来演变出了敏捷模型（其实还有其他的模型，不过相关性不大，这里就不做介绍了），我们用来自网上的两张图来体现敏捷模型与瀑布模型的区别：
通过对比可以看到，在敏捷模型里开发和测试不是原来的完成全部开发再测试这样的情况，而是类似下图这种：
在敏捷模型里，大家可以发现，运维阶段的工作还是在最后，所以再之后演变出DevOps：
从图中可以看到迭代过程中，开发测试部署是快速迭代同时进行，部署操作不再是等到最后。这就是一个简单的开发运维模型的一个变更过程。
然后我们回过头来看看DevOps:
第一段是来自AWS的解释，DevOps集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织更好的服务其客户，并在市场上高效的参与竞争。
对于DevOps来说，有个核心元素就是CI/CD，所以到DevSecOps，大家会发现在CI/CD嵌入安全也是一个重要环节。
DevOps的流水线大概是这样的：
其实，DevOps早在九年前就有人提出来，为什么这两年才开始受到越来越多的企业重视和时间呢？
因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。
随着开发运维模型的变更，SDL就不再是完全适用于新的模型，DevOps带来的各种优势和技术趋势甚至成为了安全实施的难点：
所以早在2012年Gartner就提出了DevSecOps，并通过这么多年的发展，逐渐成熟。
相对于SDL，DevSecOps不再是一个单纯的安全开发模型，也不仅仅是关注开发阶段，它所强调的是人人为安全负责，人人参与安全，安全嵌入到开发到运维的每个阶段。
所以首先从角色角度，安全团队不再置身于业务之外，也不再是安全团队兜底安全，安全是一个开发、安全、运维、QA一起协作的过程。
然后我们可以简单做下SDL和DevSecOps的对比,其中最明显就是安全责任、安全关注的流程以及效率的区别。
但是其实是不是原来SDL的东西就没法用到DevSecOps？需要推翻呢？不是的，需要做的是进一步的流程融入，更加自动化，更多前置，以及安全文化的塑造。
在DevSecOps里有三个关键点，分别是人和文化、流程以及技术。
传统安全里业务发展优先，安全是“以后”才会发生的事情，甚至认定安全会阻碍业务的发展，而DevSecOps强调的是人人参与安全，人人为安全负责,安全是大家的事，其实也确实应该是这样的。
流程方面更多要考虑整合流程，建立相关安全流程，加强不同团队间的协作,以及安全需要低入侵柔和的嵌入开发和运维流程。
技术方面更多是构建安全工具链，实现更多自动化安全检测。
在具体落地和实践方面，RSAC2019大会安全专家迅速的滑板 Maccherone提出的实践DevSecOps的九大关键因素文化融合的七个阶段,也可以作为参考:
文化融合的七个阶段：
包含有文化意识维度的安全意识、安全编码,在架构和设计维度的威胁建模，工具方面需要构建的第三方导入代码分析(第三方组件安全)、代码编写分析。
然后是全漏洞管理要建立团队工作协议，也就是强调协作，建立漏洞管理共识和处理流程，对安全问题优先进行高危漏洞清理。最后其他监督方式如安全同行的审阅，一些安全评估手段。
七个阶段运用不同颜色直观展示DecSecOps在组织中的实践和接受程度。
这九大实验要素基本覆盖DevSecOps落地的一些关键点，包括说需要关注供应链安全，考虑第三方组件的安全，这也是我们现在在做的一些方向。
在落地DevSecOps过程中，其中很重要的一块我觉得是构建工具链，在不同的DevOps阶段需要进行不同的安全动作,都需要不同的工具支撑。
其中比较关键的工具是AST及SCA：
DAST就是动态应用测试，比如说我们常见的AWVS、APPSCAN等漏扫就是这个类型，SAST是静态应用测试，通常就是代码审计工具，而IAST则是介于两者之间的交互式应用测试工具，通常通过插桩的方式，既能像SAST定位具体问题代码位置也能像DAST能定位到具体CGI。
这里需要注意的是，通常流量代理测试的方式也有人归类到IAST，但实际它不是真正意义上的IAST。
过去我们在做腾讯云研发安全的过程中，也在构建相关工具链：
或者通过另外一个视图可以看到我们过去在云相关安全工作在DevSecOps中的情况：
除了工具链，上文也提到，DevSecOps的落地中很重要的一个部分也是我们一直做的一个点就是如何在CI/CD嵌入相关安全动作。
RSAC2018出现了一个新概念“Golden Pipeline”，叫做“黄金管道”，特指一套通过稳定的、可落地的、安全的方式自动化地进行应用CI/CD的软件流水线体系，所以基于这样图将我们的工具链对应上，大概就包含这几个部分的内容。
所以总结来看，DevSecOps的落地是有几个关键点的：
我用一棵树来表示，最基础的部分是工具链的建设，然后核心的枝干，也就是落地点就是在CI/CD中进行安全动作的嵌入，而枝叶部分，一些需要重点的安全动作就包含有自动化测试、软件成分识别与检查，以及对应一些在新的技术趋势下需要特别关注的关注点就包含有容器安全、API安全、第三方组件安全。这里图中相对没有体现出来的核心点就是安全文化。
过去在几个关键点其实我们也在做一些落地，比如联合公司内代码扫描平台和其他团队共同构建的静态代码扫描：
基于公司统一源，以及与其他团队合作及自研的第三方组件安全管理方案：
与IEG安全团队共建包含现在开源协同作为公司统一容器基线安全解决方案的容器镜像扫描能力：
还有与云API、官网等团队合作的一些API安全方面的尝试：
以及未来更多展望，包含更完善的安全开发库及自动化安全规范检查，或者安全设计与需求阶段的自动化检查等。
扩展阅读:[1] 《SDL已死，应用安全路在何方？》
https://zhuanlan.zhihu.com/p/126275053
[2] 微软SDL：
https://www.microsoft.com/en-us/securityengineering/sdl/practices
[3] STRIDE威胁建模方法讨论:
https://www.freebuf.com/articles/es/205984.html
[4] 威胁建模工具入门:
https://docs.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool-getting-started
[5] S-SDLC:
http://www.owasp.org.cn/owasp-project/S-SDLC/
[6] 应用安全测试技术DAST、SAST、IAST对比分析:
https://www.aqniu.com/learn/46910.html
[7] 从RSAC看DevSecOps的进化与落地思考:
https://www.freebuf.com/articles/neopoints/228886.html
[8] 文章部分图片来源于：
https://baijiahao.baidu.com/s?id=1649919009474612596