正文
关键要点
-
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这样的初创公司则专注于将每个服务的安全性洞察与各自的操作指示板统一起来。
