作为 DevSecOps 实践的威胁建模

软件工程师总是在压力之下构建更多、更快的软件。与此同时，在满足用户和监管机构数据隐私要求的安全软件方面，监管和市场压力日益增大。这种动态经常使软件工程师与应用程序安全或产品安全团队发生冲突。

事实上，据一位研究人员称，大型企业中81% 的开发团队已经发布了具有不安全代码特性的应用程序，其中一半的开发团队经常这样做。公司认为开发人员和安全架构师需要更好的关系，我完全同意。

这些技术团队正朝着同一个目标努力，因此，通过打破团队之间的障碍，创造一个更具凝聚力的工作环境，符合所有人的利益，尤其是高层领导。如果系统的安全性是由一个外部安全团队设计和执行的(与工程团队的其他成员断开连接) ，那么这只会加强作为单独竖井的安全性。但是公司可以通过将安全责任嵌入到工程团队中来缓解紧张局势: 这就是 DevSecOps 背后的想法。当工程师考虑解决问题时，安全性就开始了: 在设计阶段。

虽然左移运动在20年前就已经出现，其目标是确保产品测试在开发阶段的早期发生，但我认为我们需要开始左移，以便做出真正的改变。在采用这种文化的过程中，安全性和隐私将不再是事后才想到的，也不再是开发过程中的内置固定装置，从而确保工程师和安全团队都是一致的，并且对彼此的目标具有可见性。

通过实时构建架构安全设计，重新想象构建、测试、修复、构建、测试、修复周期，技术团队可以更早而不是更晚地发现软件漏洞，这意味着更有效的产品部署。这就是作为业务工具的威胁建模过程可以带来巨大好处的地方。

从历史上看，威胁建模是在白板上进行的静态、缓慢和手动的过程，是由缺乏公司内部运作机制知识的第三方安全专家领导的研讨会的一部分。然而，这已经戏剧性地演变成一种易于实现的自动化安全实践，可以从一开始就融入到开发和安全周期中，使组织能够从左边开始。

通过自动化威胁建模，减轻了安全架构师和工程师的安全工作负担。反过来，随着自动化平台建议随着应用程序的发展而改进安全性，公司处于更有利的地位，能够跟上正在进行的软件推出的节奏。因此，通常在测试阶段产生的启动阶段瓶颈被消除了，因为在开发之前已经确定了安全需求ーー这意味着在编写一行代码之前就已经管理了风险。在此基础上，它应该很快变得明显什么是一个时间和成本节约演习威胁模型。

没有开发人员或安全专家希望一个有缺陷的产品投放市场，因此采用一种能够带来更好结果的新方法具有良好的商业意义。在开发和网络安全过程中引入威胁建模的企业将在公司内部嵌入真正的 DevSecOps 系统，从而改变这两个部门之间的关系。

根据我的经验，文化和增长是企业决定调整其网络安全饮食以包括自动化威胁建模的关键因素。到目前为止，说服应用开发团队在这个过程中投入时间是需要克服的最重要的文化障碍，因为他们需要见证这些好处ーー直到这一点之前，他们都与 AppSec 流程脱节。

一旦配备了工具和知识，交付安全设计将是开发人员的第二天性，并将创建一个新的协作文化。实际上，对软件设计缺陷的监督和问责越多，就越容易认识到这些初步检查的重要性。

同样，当“安全第一”和“从左边开始”的心态对于保持企业项目管理的正常进行至关重要时，业务增长也会到达一个阶段ーー这与企业文化息息相关。随着公司内部规模的扩大，软件部署的速度必须随着客户需求和市场竞争力的提高而加快，在设计过程的最后发现缺陷是不可能的。

由于开发人员和安全团队负责大量的代码，因此产品交付的弹性至关重要，确保健壮的 DevSecOps 文化是成功的途径。