DevSecOps 的三种解读

关键要点

• DevSecOps 和 DevOps 一样，可以有多种解释，前三种解释涉及人、过程和技术
• 第一个含义是确保 DevOps 技术的安全性，这意味着调整现有的解决方案使其可用于新的技术栈，或者构建新的工具来解决新的安全问题
• 第二个含义是确保 DevOps 方法的安全性，即更改安全控制与应用程序和开发过程相互作用的时间和方式
• 第三个含义是适应 DevOps 共享所有权的哲学，使开发和运维团队拥有更多的安全责任和活动
• 要真正地拥抱 DevSecOps，首先要采用它的哲学，这才能得出正确的方法和相应的技术

DevSecOps 现在是一个热门词汇，我喜欢它，也讨厌它。

我喜欢它，因为它具体化了美国证券交易委员会行业 (包括我在内) 多年来一直试图实现的一个目标——让开发人员拥有自己的安全性。这个简单的流行语给我们的使命举起旗帜，帮助它鼓足动力，推动它成为一种常态。

我讨厌它，因为，就像所有的流行语一样，它没有正确地反映出这漫漫旅程背后的高度复杂性。安全性是一个广泛的主题，涉及基础设施、应用程序代码、网络堆栈、第三方供应商，当然还有人员。追求安全的方式涉及很多细节，但流行词没有怎么考虑这些细微差别。于是就难免不同的人用它来表达不同的意思——或者至少强调的是不同的部分。

这并不奇怪，许多流行语也有类似的情况。更具体地说，如果你在一个房间里有三个专家，你会得到对术语“DevOps”的 4 种解释和对“云”的 5 种解释。虽然我们永远不会得到一个唯一的定义，但把不同的观点写下来仍然是有帮助的，因为它们能让我们区分别人在使用这个术语时表示的是什么意思。

着眼于它的不同用法，我发现了 DevSecOps 这个词的三个主要含义。这些观点代表 DevSecOps 旅程中的不同里程碑，并与 DevOps 本身的共通解释保持一致。让我们仔细研究每一个，将这个美妙而可怕的术语带入到一种更深的层次。

DevSecOps 作为“DevOps 技术的安全保障”

DevSecOps 最直接的翻译可能是描述 DevOps 带来的一波技术的安全解决方案。云、容器和无服务器等技术是 DevOps 运动的关键。每一个都提供了新的功能并引入了新的技术栈，这些技术栈反过来又有特定的安全需求。

支持这些技术的第一步是使用现有的安全产品 (主要用于旧的栈)，并在 DevOps 环境中添加所需的技术组件去使用它。这些都是对现有工具的小改动，而不是工具运维方式的实质性改变，只是为了支持新的环境。

我们以容器安全性为例。Symantec、McAfee、TrendMicro 和其他公司都提供端点安全解决方案，包括反恶意软件、监控恶意网络活动等。这些成熟的产品长期用于服务器和虚拟机，在概念上同样适用于容器。然而，容器和主机之间的控制，以及其他技术上的差异，使得这些产品无法支持开箱即用的容器，并要求它们进行调整。TrendMicro 的深度安全产品就是一个很好的例子，它在版本10 中增加了容器支持，并在主机和容器之间划分了新的职责。这一变化足以使他们号称参与了DevSecOps 运动，尽管该产品仍然主要用于传统的安全环境。

在保护 DevOps 技术的道路上更进一步是安全解决方案，它解决了这些技术引入的新安全需求。这里的示例包括 CloudCheckr  和 Evident.io 检查云配置以查找无意中留下的存储桶 (以及其他问题，如下图所示)，或者 Snyk 在开放源码库中寻找漏洞。处理更新的技术需要新颖的思维方式，而对于那些已经倾向于传统思维方式的企业来说，这通常更加困难。因此，这通常是初创公司的领域，大公司通过收购来介入，而不是从头开始构建解决方案。



图:CloudCheckr 的云安全评估结果

容器很好地说明了这个场景。主机和容器之间的隔离并不完美，这一事实产生了一个新的风险——在容器中运行恶意代码会从容器沙箱中跳出来并影响主机。由于相同的物理主机经常运行不同级别的容器，甚至属于不同的所有者，沙箱逃逸是一个真正的、直接的威胁。容器带来的这些额外的新风险为专注于容器安全的初创企业打开了大门，比如 Sysdig、Aqua 和 Twistlock，它们会使容器更为坚固，并标记试图突破容器的安全性。这些初创公司通常会安全将自己定位为 DevSecOps 公司。

在这两种情况下，DevSecOps 一词都是指确保 DevOps 技术的安全性。也就是说，这些解决方案中有一些自然地渗入了我们应用 devops 的方式，这让我们有了下一个含义……

DevSecOps 作为“DevOps 方法论的安全保障”

除了技术之外，DevOps 还采用了强大的新方法论，如持续交付 (CD) 和微服务 (接下来是无服务器)。这些技术将导致更快的开发和更细粒度的组件，这两种技术都将快速破坏现有的安全方法。

又一次，这些新方法需要对现有玩家进行演进。让我们以 CI/CD 为例。

持续交付的采用意味着在发布过程中“为审核而停下来”不再被接受，而是需要在管道中进行强大的自动化安全测试。对自动化的需求引起了对静态应用程序安全测试 (SAST) 工具的关注，但是这些工具花费了太长时间 (通常是几个小时) 来完成单个代码扫描，这在频繁的构建环境中是不可行的。为了适应这种情况，大多数 SAST 工具引入了增量扫描的概念，只测试更改过的代码。这些扫描完成得更快，因此可以适用于管道。再一次，这些调整常常被用来展示 DevSecOps 的威力。

虽然这种适应很重要，但往往还不够。一些新的方法不仅改变了技术设置，而且还打破了现有工具所依赖的核心概念，这需要重新考虑整个产品——这又是一个初创企业擅长的领域。微服务安全监控就是一个很好的例子。

从独体大型应用程序到微服务的移动改变了应用程序的定义，现在不再通过一组输入和输出来监视实体，而是数据在多个不同服务之间的流动，有时甚至上百个。在这样的环境中成功地实时识别攻击需要一个完全不同的安全监视解决方案，该解决方案可扩展到监视大量服务和它们之间的数据流。像 Aporeto 这样的初创公司通过跟踪服务到服务通信和标记未授权的连接尝试来解决这个问题，而像 SignalSciences 这样的初创公司则专注于将每个服务的安全性洞察与各自的操作指示板统一起来。



图:Aporeto 映射微服务和不可信连接标记 ( Aporeto 演示网络研讨会)

除了克服这些新方法的挑战之外，这些专用的解决方案还利用了它们提供的机会。例如，虽然容器在逻辑上与 vm 相似，但它们通常是无状态的，并部署在高弹性环境中。因此，关闭一个行为可疑且可能受到损害的容器是完全合理的，因为不会丢失任何数据，并且系统只会启动个新的。这种粗劣的回应显然不是裸机主机的选择，在大型虚拟机中也不可行。而且，实际上，您将很难找到一种端点安全解决方案，可以在警报状态下撤下一台机器，而实际上所有的容器和微服务安全初创公司都大力提倡这样做。

有种更广泛的解释，是与只关注技术相比，DevSecOps 要调整适应 DevOps 方法论，从长远来看，这种解释更有价值。它通常也需要一些技术支持 (例如，如果没有支持容器，就不能保证微服务的安全性)，并继续理解和调整安全性以适应正在制定的新流程。然而，尽管它触及了金三角的两个部分(人、过程、技术)，但它仍然忽略了最重要的部分。

DevSecOps 作为“DevOps 共享所有权哲学的安全保障”

DevOps 的核心不是技术或方法，而是人员和协作。它是关于接受”让我们的软件运行良好是每个人的问题，并且我们分担责任去解决它”。DevOps 反对开发“把代码扔过墙”的做法，因为运维可以处理和帮助项目事务处理人员每天面对的约束。

这种文化和哲学的转变推动了新的方法和技术。它导致开发人员编写更多可运维的代码，运维将基础设施以及大量后续的软件和技术视为代码，以使其规模化。这种转变才真正地让企业在竞争中更快、更好。

DevSecOps 的最后一幅最宽阔的景象也遵循着同样的脚步。要以 DevOps 的速度真正解决安全问题，我们必须将它嵌入到常规的开发和操作过程中。由于安全团队的人数就像之前的运维团队一样被开发人员的数量远远抛开，实现共享所有权的唯一方法是让开发团队执行大部分的日常安全活动。剩下的工作应该主要由运维来完成，安全团队应该花大部分时间使其他团队能够完成常规工作，管理和自动化这个活动(“安全性即代码”，延续“基础设施即代码”)。

对于现有的安全解决方案来说，这是一个艰难的变化。这些企业的建立是为了迎合安全专业人士，并且他们的整个上市模式以及他们的世界观都专注于这个行业。他们发起安全事件，使用安全人员的术语，并根据安全行业的标准对产品定价。安全厂商越大，他们改变目标市场的损失就越大，这样做的可能性就越小。

更重要的是，安全产品的设计主要是为了帮助信息安全人员完成他们的日常工作，而开发人员都通常是从这种扭曲的视角完成开发。结果与 VMWare 构建 IDE 或 Citrix 创建 CI 产品时的情况类似。这些都是功能强大的运维工具，但他们没去考虑开发人员，所以不太可能为这些用户设计合适的工具。

有趣的是，DevSecOps 的哲学更适合相反的方向，那就是拥抱安全的公司的开发人员做工具。这些公司已经赢得了开发人员的心和思想，现在可以让这些开发人员在他们的 DevOps 之旅中更进一步。源代码供应商可以解决代码安全性问题，APM 供应商可以监控安全性缺陷，而管道供应商可以让流转过程更为稳定。

这不再是一个理论上的机会。在 2017 年，我们看到 GitHub 将安全警报添加到 repos、谷歌 Chrome 在其内置开发工具中标记脆弱人 JavaScript 库，而 Sysdig 也推出了容器安全产品。这些公司也有一个学习曲线来理解如何构建安全解决方案，但是它们定位在了正确的位置上。



图:Chrome 开发工具标记脆弱的 JavaScript 库

最后，对于创业公司来说，这是一个绝好的机会。销售给开发人员比他们的安全部门要高效得多，因为前者的销售成本要低得多。此外，如今的 CSO 也越来越多地提出他们已经学着忽略电话销售了，但开发团队已经接受的安全解决方案，并仍将投入注意力。我们现在已经清楚，开发人员是运维领域的新拥护者，安全也可能会步其后尘。

目前，很少有安全公司关注开发人员。在认证领域有一个很好的例子，Auth0 为开发者赢得了大量的文档、最底层的定价模型和强大的社区论坛和程序。他们最新推出的价值 5500 万美元的 D 系列是赢得回报的一个标志。在此，我可以给出的另一个例子，我自己的公司斯奈德，它修复了开源依赖中的漏洞。我们主要关注开发人员，从深度开发工具集成，到许多思想领导力活动，投资于自动化的修复，这对开发人员比对审计人员更有帮助，并且获得了巨大的回报。



图: 将自动修复引入 GitHub 内的开发人员上下文。

统计数据显示，真正采用 DevOps 哲学的组织无论使用何种技术和方法，都能获得更好的商业结果。我希望那些真正采用 DevSecOps 的组织能够在保持自身和用户数据安全方面得到同等的提升。

理解 DevSecOps

DevSecOps 是一个热门词汇，它不会消失。这个词很快就会成为信息安全的流行词，而且这个词越热，就会有越多的公司和供应商使用它，不管它的意思是什么。

下次您遇到使用这个术语的解决方案时，我希望本文将帮助您正确地对其进行分类。它是支持 DevOps 技术、适应 DevOps 方法论的安全解决方案，还是支持 DevOps 哲学并帮助您改变组织? 或者它可以适用于许多情况? 有了正确的分类，可以帮助您消除噪音，专注于 DevSecOps 任务。

关于作者

Guy Podjarny (@guypod) 是斯奈德的联合创始人兼 CEO，专注于使用开源并保持安全性。Guy 在收购了自己的初创公司 Blaze 之后，曾在 Akamai 担任首席技术官，并参与了第一个 web 应用程序防火墙和安全代码分析器工作。Guy 经常在会议上发言，著有 O'Reilly 的《安全性开源库》、《响应和快速》和《高性能图像》。

查看英文链接： The 3 Faces of DevSecOps