安全性只是辅助效果？解读DevSecOps的核心动机

导语：安全性居然只是DevSecOps的辅助效果，那么采用DevSecOps的核心动机到底是什么呢？

DevSecOps背后的思想仅是对DevOps的扩展。就像开发人员以瀑布式开发风格将项目扔给运营团队以使其在生产中工作一样，即使使用“ DevOps”，安全性也与应用程序开发或运营完全分开。

DevSecOps一词通常与“向左移动安全性”结合使用。这意味着应用程序的开发人员应在设计时考虑安全因素，而不是将其单独留给安全团队。似乎大多数人自然而然地将注意力集中在DevSecOps方法，如何着重于将安全性集成到开发过程中，特别是CI / CD管道，但人们也可能会说DevSecOps也涉及“转移权利”。

容器安全公司Snyk的创始人Guy Podjarny说：“这是一个概括性的术语，就像DevOps一样，适用于我们如何构建和分类以及运输和交付软件，以及如何在运行时对其进行分类。”

为什么采用DevSecOps？

相对忽略运营和安全性如何组合的原因是，大多数人从迁移到DevSecOps时获得的最大好处既不是提高安全性也不是提高可靠性。在大多数情况下，组织似乎采用DevSecOps的原因与更快地将应用程序推向市场有关。换句话说，是为了满足与DevSecOps团队开发人员通常相关的激励措施。

“我认为已经成功完成DevSecOps的组织能够将产品，新产品，新功能交付市场，比竞争对手快得多。” Palo Alto Networks公共云首席安全官Matt Chiodi解释说。“有纯粹的商业利益。”

红帽 OpenShift产品经理Kristen Newcomer表示，她发现公司通过采用DevSecOps，将部署周期从38周转移到了7周。

在传统的安全设置中，安全团队通常不会检查代码，直到代码已经遍及整个开发流程为止。发现问题后，安全团队将把项目以及要修复的问题列表发送给开发人员。漫长的反馈循环减慢了项目的交付速度，同时也加剧了安全与开发人员之间的紧张关系。

在实践中，将安全性分开还可以使安全性问题更容易进入生产环境。Chiodi说：“大多数组织花费80％或更多的时间在运行阶段。” “当安全性在构建，发布和运行过程中平均分配时，您最终会减少很多的漏洞，然后这些漏洞会在运行时出现。”

但是，在接受采访的安全专家中，似乎已经达成共识，即改善组织的安全状况不是采用DevSecOps的核心动机，而是令人意想不到的辅助效果。

正确设置DevSecOps

哪个组织不希望更快，更安全地交付应用程序？许多新公司从一开始就采用DevSecOps方法，但是要成功建立起大型组织的DevSecOps并不容易。从DevOps迁移到DevSecOps可能至少与从瀑布式迁移到DevOps一样具有挑战性。

“我所见过的在DevSecOps上真正成功的团队在执行层得到了认可，” Newcomer解释说。DevSecOps需要重大的文化变革，并涉及对每个参与人员激励措施的转变。如果没有高层的支持，DevSecOps要求的文化变革可能无法实现。

集装箱安全公司StackRox的产品负责人Hillaryaryson解释说：“ 每当您必须改变人们的思维或行动方式时，这将是最艰难的战斗。” “而且，关于如何获得DevSecOps必杀技，还没有真正的既定蓝图。”

改变安全性的角色

Newcomer说：“安全是No团队的声誉。” DevSecOps的目标是改变这种动态，以使安全性不再是部署路径上的障碍。但这涉及更改安全专业人员的工作方式。

首先，DevSecOps需要高度的自动化。安全团队根本不应该运行手动测试，而应该将测试集成到CI / CD管道中，应该在没有安全专业人员干预的情况下获得有关应用程序或功能的安全风险的反馈。

相反，在DevSecOps模型中，安全团队的作用是创建安全策略，帮助开发人员和操作员了解安全自动化工具和服务器作为顾问的输出。开发人员不需要成为安全专家，但是他们确实需要变得对安全性更加了解。毫无疑问，安全专业人员还必须更加熟悉基础架构和软件开发。

这并不总是一条容易走的路。Benson解释说：“如果您是安全专业人员，并且花了很多时间来学习这些技能，那么对于进入使您学习完全不同的技能的东西，您可能不会感到非常兴奋。”

统一激励措施

DevSecOps的主要挑战之一是，它涉及将以不同方式激励的团队召集在一起。开发人员希望快速推出新功能，安全团队希望解决每一个潜在的安全风险，运营商希望获得超级可靠的应用程序。

这种紧张局势是成功收获DevSecOps所必须获得高层支持的核心原因之一。即使将安全性集成到DevOps团队中，共享KPI还是很重要的，这些KPI汇集了团队中每个人的传统目标。

但是，谁最终对安全负责呢？这是一个棘手的问题。有些人认为安全性仍然应该是安全专业人员的责任，有些人认为责任应该转移给开发人员，而其他人则认为这应该是每个人的责任。当然，“每个人的责任”的风险在于，安全不会成为任何人的责任。

如何衡量DevSecOps的成功？

考虑到大多数公司采用DevSecOps的动机，因此开发速度是DevSecOps成功的关键指标就不足为奇了。使用开发指标的另一个优势是：很难增加安全性。

Benson解释说：“特别是在安全性方面衡量任何事情的困难之处在于，您有点在衡量反事实。” “如果什么都没有违反，这意味着您做得很好，或者这意味着您很幸运。”

但是，如果DevSecOps至少在文化转型方面与在技术方面同样重要，那么用组织指标衡量成功的意义就至少一样重要。例如：安全专业人员是在花费时间自己运行测试还是在为DevOps团队创建或配置工具来使用？安全专家在提出建议时是否了解并考虑了功能的业务原理？开发、安全性和操作之间多久通信一次…… ……