DevSecOps 也许不是一个优雅的词汇，但是其结果很吸引人：更强的安全、提前出现在开发周期中。来看看一个 IT 领导与 Meltdown 的拼搏。

如果 DevOps 最终是关于创造更好的软件，那也就意味着是更安全的软件。

而到了术语 “DevSecOps”，就像任何其他 IT 术语一样，DevSecOps —— 一个更成熟的 DevOps 的后代 ——可能容易受到炒作和盗用。但这个术语对那些拥抱了 DevOps 文化的领导者们来说具有重要的意义，并且其实践和工具可以帮助他们实现其承诺。

说道这里：“DevSecOps”是什么意思？

“DevSecOps 是开发、安全、运营的混合，”来自 Datical 的首席技术官和联合创始人 Robert 说。“这提醒我们，对我们的应用程序来说安全和创建并部署应用到生产中一样重要。”

[想阅读其他首席技术官的 DevOps 文章吗？查阅我们丰富的资源，DevOps：IT 领导者指南]

向非技术人员解释 DevSecOps 的一个简单的方法是：它是指将安全有意并提前加入到开发过程中。

“安全团队从历史上一直都被孤立于开发团队——每个团队在 IT 的不同领域都发展了很强的专业能力”，来自红帽安全策的专家 Kirsten 最近告诉我们。“不需要这样，非常关注安全也关注他们通过软件来兑现商业价值的能力的企业正在寻找能够在应用开发生命周期中加入安全的方法。他们通过在整个 CI/CD 管道中集成安全实践、工具和自动化来采用 DevSecOps。”

“为了能够做的更好，他们正在整合他们的团队——专业的安全人员从开始设计到部署到生产中都融入到了开发团队中了，”她说，“双方都收获了价值——每个团队都拓展了他们的技能和基础知识，使他们自己都成更有价值的技术人员。 DevOps 做的很正确——或者说 DevSecOps——提高了 IT 的安全性。”

IT 团队比任何以往都要求要快速频繁的交付服务。DevOps 在某种程度上可以成为一个很棒的推动者，因为它能够消除开发和运营之间通常遇到的一些摩擦，运营一直被排挤在整个过程之外直到要部署的时候，开发者把代码随便一放之后就不再去管理，他们承担更少的基础架构的责任。那种孤立的方法引起了很多问题，委婉的说，在数字时代，如果将安全孤立起来同样的情况也会发生。

“我们已经采用了 DevOps，因为它已经被证明通过移除开发和运营之间的阻碍来提高 IT 的绩效，”Reevess 说，“就像我们不应该在开发周期要结束时才加入运营，我们不应该在快要结束时才加入安全。”

为什么 DevSecOps 必然出现

或许会把 DevSecOps 看作是另一个时髦词，但对于安全意识很强的IT领导者来说，它是一个实质性的术语：在软件开发管道中安全必须是第一层面的要素，而不是部署前的最后一步的螺栓，或者更糟的是，作为一个团队只有当一个实际的事故发生的时候安全人员才会被重用争抢。

“DevSecOps 不只是一个时髦的术语——因为多种原因它是现在和未来 IT 将呈现的状态”，来自 [Sumo Logic] 的安全和合规副总裁 George 说道，“最重要的好处是将安全融入到开发和运营当中开提供保护的能力”

此外，DevSecOps 的出现可能是 DevOps 自身逐渐成熟并扎根于 IT 之中的一个征兆。

“企业中的 DevOps 文化已成定局，而且那意味着开发者们正以不断增长的速度交付功能和更新，特别是自我管理的组织会对合作和衡量的结果更加满意”，来自 [CYBRIC] 的首席技术官和联合创始人 Mike 说道。

在实施 DevOps 的同时继续保留原有安全措施的团队和公司，随着他们继续部署的更快更频繁可能正在经历越来越多的安全管理风险上的痛苦。

“现在的手工的安全测试方法会继续远远被甩在后面。”

“如今，手动的安全测试方法正被甩得越来越远，利用自动化和协作将安全测试转移到软件开发生命周期中，因此推动 DevSecOps 的文化是 IT 领导者们为增加整体的灵活性提供安全保证的唯一途径”，Kail 说。

转移安全测试也使开发者受益：他们能够在开放的较早的阶段验证并解决潜在的问题——这样很少需要或者甚至不需要安全人员的介入，而不是在一个新的服务或者更新部署之前在他们的代码中发现一个明显的漏洞。

“做的正确，DevSecOps 能够将安全融入到开发生命周期中，允许开发者们在没有安全中断的情况下更加快速容易的保证他们应用的安全”，来自 SAS 的首席信息安全员 Wilson 说道。

Wilson 指出静态（SAST）和源组合分析（SCA）工具，集成到团队的持续交付管道中，作为有用的技术通过给予开发者关于他们的代码中的潜在问题和第三方依赖中的漏洞的反馈来使之逐渐成为可能。

“因此，开发者们能够主动和迭代的缓解应用安全的问题，然后在不需要安全人员介入的情况下重新进行安全扫描。” Wilson 说。他同时指出 DevSecOps 能够帮助开发者简化更新和打补丁。

DevSecOps 并不意味着你不再需要安全组的意见了，就如同 DevOps 并不意味着你不再需要基础架构专家；它只是帮助你减少在生产中发现缺陷的可能性，或者减少导致降低部署速度的阻碍，因为缺陷已经在开发周期中被发现解决了。

“如果他们有问题或者需要帮助，我们就在这儿，但是因为已经给了开发者他们需要的保护他们应用安全的工具，我们很少在一个深入的测试中发现一个导致中断的问题，”Wilson 说道。

DevSecOps 遇到 Meltdown

Sumo Locic 的 Gerchow 向我们分享了一个在运转中的 DevSecOps 文化的一个及时案例：当最近 [Meltdown 和 Spectre] 的消息传来的时候，团队的 DevSecOps 方法使得有了一个快速的响应来减轻风险，没有任何的通知去打扰内部或者外部的顾客，Gerchow 所说的这点对原生云、高监管的公司来说特别的重要。

第一步：Gerchow 的小型安全团队都具有一定的开发能力，能够通过 Slack 和它的主要云供应商协同工作来确保它的基础架构能够在 24 小时之内完成修复。

“接着我的团队立即开始进行系统级的修复，实现终端客户的零停机时间，不需要去开工单给工程师，如果那样那意味着你需要等待很长的变更过程。所有的变更都是通过 Slack 的自动 jira 票据进行，通过我们的日志监控和分析解决方案”，Gerchow 解释道。

在本质上，它听起来非常像 DevOps 文化，匹配正确的人员、过程和工具，但它明确的将安全作为文化中的一部分进行了混合。

“在传统的环境中，这将花费数周或数月的停机时间来处理，因为开发、运维和安全三者是相互独立的”，Gerchow 说道，“通过一个 DevSecOps 的过程和习惯，终端用户可以通过简单的沟通和当日修复获得无缝的体验。”