DevSecOps 改变安全的 5 种方式

安全性必须发展以跟上当今应用程序编写和部署的方式。

图片来自

JanBaby，通过 Pixabay CC0。

关于我们是否需要扩展 DevOps 以明确引入安全性，一直存在争议。毕竟，人们认为，DevOps 一直是代表一套广泛的新实践的简写，使用新工具（通常是开源的）并建立在更协作的文化之上。为什么不使用 DevBizOps 以更好地与业务需求保持一致？或者使用 DevChatOps 来强调更好、更快的沟通？

然而，正如 John Willis 今年早些时候写道，他逐渐接受了 DevSecOps 术语，“希望有一天，我们将生活在一个不再需要使用 DevSecOps 这个词的世界里，安全将成为所有服务交付讨论的固有组成部分。在那一天到来之前，以及在这一点上，我的总体结论是，这只是三个新字符。更重要的是，这个名称真正区分了问题陈述，因为我们作为一个行业在信息安全方面做得并不出色。”

那么，为什么我们在信息安全方面做得不够出色呢？在 DevSecOps 环境中做得出色又意味着什么？

尽管（或者可能是因为）庞大的复杂点产品行业解决了狭隘的问题，但可以说我们从未在信息安全方面做得出色。但可以说，在防御威胁侧重于保护边界、网络连接有限且大多数用户是使用公司提供设备的员工的时代，我们做得足够好了。

[下载 DevSecOps 入门指南]

这些情况多年来一直没有准确地描述大多数组织的现实。但当前的时代，不仅引入了 DevSecOps，还引入了新的应用程序架构模式、开发实践以及越来越多的威胁，定义了一个严峻的新常态，需要更快的变革步伐。与其说 DevSecOps 孤立地改变了安全性，不如说 2018 年左右的信息安全需要新的方法。

考虑以下五个方面。

自动化

大量自动化是 DevOps 的普遍标志。这部分是为了速度。如果您要快速行动（并且不破坏事物），您需要拥有无需大量人工干预即可执行的可重复流程。实际上，自动化是 DevOps 的最佳切入点之一，即使在主要仍在处理单体遗留应用程序的组织中也是如此。使用 Ansible 等易于使用的工具自动化与配置或测试相关的例行流程是开始 DevOps 之路的一个常见的快速方法。

DevSecOps 也没有什么不同。今天的安全是一个持续的过程，而不是应用程序生命周期中的一个离散检查点，甚至不是每周或每月的检查。当供应商发现漏洞并发布修复程序时，鉴于利用这些漏洞的漏洞很快就会出现，因此快速应用这些修复程序非常重要。

“左移”

传统安全通常被视为开发过程结束时的看门人。检查所有框，您的应用程序即可投入生产。否则，请重试。安全团队以经常说“不”而闻名。

因此，人们认为，为什么不将安全提前（在从左到右绘制的典型开发管道中向左移动）？安全可能仍然会说“不”，但早期开发阶段返工的后果远小于应用程序完成并准备交付时的后果。

我不喜欢“左移”这个术语。它暗示安全仍然是一次性事件，只是提前了。安全需要成为应用程序生命周期中无处不在的、很大程度上自动化的过程，从供应链到开发和测试过程，一直到部署。

管理依赖项

我们在现代应用程序开发中看到的一大变化是，您通常不会编写大部分代码。使用开源库和框架就是一个明显的例子。但您也可能只是使用来自公共云提供商或其他来源的外部服务。在许多情况下，这些外部代码和服务将使您自己编写的代码相形见绌。

因此，DevSecOps 需要认真关注您的软件供应链。您是否从可信来源获取软件？它是否是最新的？它是否集成到您用于自己代码的安全流程中？您对可以使用的代码和 API 有哪些策略？您正在用于自己的生产代码的组件是否有商业支持？

没有一套答案适用于所有情况。对于概念验证与大规模生产工作负载，它们可能有所不同。但是，正如长期以来制造业的情况一样（DevSecOps 在制造业的发展方式中有很多类似之处），供应链的完整性至关重要。

可见性

我已经谈了很多关于在应用程序生命周期的所有阶段都需要自动化的必要性。这假设我们可以看到每个阶段正在发生的事情。

有效的 DevSecOps 需要有效的工具，以便自动化知道该做什么。这种工具分为许多类别。有一些长期和高级指标可以帮助我们了解整体 DevSecOps 流程是否运行良好。有一些需要立即人工干预的关键警报（安全扫描系统已关闭！）。还有一些警报（例如扫描失败）需要修复。还有我们捕获的许多参数的日志，供以后分析（随着时间的推移发生了什么变化？是什么导致了该故障？）。