DevSecOps 将会嵌入 DevOps

通常人们在一个项目行将结束时才会考虑到安全，这么做会导致很多问题；将安全融入到DevOps的工作流中已产生了积极结果。

DevSecOps：安全正当时

一直以来，开发人员在构建软件时认为功能需求优先于安全。虽然安全编码实践起着重要作用，但对于赶在最后期限前构建应用程序的团队来讲，它往往会被降到第二或第三级需求的位置。

“软件安全”的说法通常会在软件开发人员中引起负面情绪，因为它意味着增加额外的编程量、不确定性、以及阻碍快速开发和发布周期的拦路石。最近这种思维模式正在逐渐发生改变，其中很大的一部分原因是自动化安全成功地融入了DevOps实践中。

DevSecOps的调查结果显示，24%的受访者认为安全是开发人员目前的第一考虑因素。而在自我标榜有着成熟DevOps实践的组织机构中，38%的受访机构表示安全是首要考虑因素且开发人员在安全上面投入大量时间。这说明开发过程中的安全实践比例要比DevOps团队高60%。

调查结果还显示，67%的开发人员并没有在安全方面投入足够的时间，或者他们认为这是其他人的责任。

鼓励新想法

毋庸置疑，开发人员将继续优先区分业务需求和市场需求：而这正是DevOps实践的用武之地，它能改变开发人员的这种心态以及开发行为。DevOps实践能够让开发人员从必须遵循强加的规则和指南转向创造性地决定采用新的、更加容易的、自动化方式提早且在SDLC整个过程中采用安全编码实践。

强调一系列的DevOps原则如文化、自动化和基础设施即代码能够让开发人员更多地了解到自己所构建的东西可被如何利用。DevOps文化并非盲目地遵循所要求的安全实践和控制，而是鼓励开发人员思考如何将确保应用程序的安全融入日常代码活动中。

一些组织机构鼓励开发人员像可能会利用代码中漏洞的攻击者那样思考。而另外一些组织机构帮助开发人员更好地理解他们所面临的挑战即在最后期限完成编程的同时确保代码的安全。这种实践有助于引起同理心，同时让软件变得更加安全。

从被动到主动

改变软件的构建方式也有助于开发和安全团队的立场从被动转为主动。过去，软件安全关注的是预测攻击的来源和发动方式并设置障碍来应对攻击，这个过程耗时较长。此外，有必要注意到的一点是，人们并无法预测到多数攻击尤其是复杂攻击，也就是说随着新型攻击的发现，修复方案通常会跟上。无法预测攻击这一事实就是为何新的0day漏洞出现后会看到作为响应的补丁。

随着DevSecOps的到来，人们就能主动将保证软件安全的精力投入到打败攻击的过程中。例如，某些组织机构正在构建的软件的攻击面在缩小，从而既能快速部署又能快速恢复。换句话说，开发人员不再那么担心被黑，而更担心如何阻止可预见的攻击并快速从网络事件中恢复。

开发人员还在寻求多种创新方式，从而让软件承受攻击并继续发挥作用。换句话讲，软件应该“弯曲”而非“破裂”。这种从阻止到“弯曲而非破裂”的思维方式转变能让人们在应对攻击时变得更加灵活。

安全不拖累交付

DevSecOps的新兴概念主要是为了在增强应用程序安全性的同时不能拖累发布和部署周期。这些技术包括在软件开发周期中增加安全测试技术如模糊测试和软件渗透测试。

其它技术包括在持续性整合平台中自动化安全分析，从而在SDLC中提早限制易受攻击代码的引入。这种方式能让开发团队提早考虑安全从而更快地推出修复方案。它能让积极编程的开发人员更容易地修复实时出现的问题，而不是等到几周或几个月之后才收到警告信息。

应用这些以及其它DevSecOps原则能为创造有弹性且安全的环境产生较大影响。如果正确执行这些原则，那么将有助于开发人员在正确的时间拥有正确的工具和正确的洞察力。如果在早期将安全构建于SDLC和所有地方，那么开发人员会更快地构建更好的软件。