对于众多开发和安全团队而言，要将安全性作为共同责任整合到软件开发生命周期的每个阶段，而非在开发完成后才着手处理安全问题，文化与思维方式的转变至关重要。
在这段存档的主题演讲中，Contrast Security公司DevSecOps转型架构师Larry Maccherone，重点介绍了如何将应用安全（AppSec）与DevOps的传统流程，从根本上转型为现代化的DevSecOps方法。本段内容来自InformationWeek于2024年5月22日举办的"如何借助DevSecOps强化DevOps"线上研讨会。
以下为演讲视频文字整理，部分内容经过轻微编辑以提升可读性。
Larry Maccherone：我先从坏消息说起——我们目前做应用安全的方式从根本上就是有问题的。传统思维认为，安全工作应该在产品进入生产环境之前集中进行，这是一种过时的观念。
与这种思维配套的，是"守门人"式的工作方式。如果一个团队在践行DevOps理念，他们每天可能要多次向生产环境发布更新，安全团队根本不可能对每次发布进行全面审计并有效把关，尤其是在资源有限的情况下。这正是大家公认的传统安全方式的核心问题，也是DevSecOps逐渐成为新主流模型的原因。
但我认为，问题还远不止于此，还有一些更深层的隐患。安全人员的工作本质上是在挑开发人员的毛病，相当于当面告诉工程师"你的孩子长得丑"。这项工作耗时耗力，而工程师通常也不愿意接受这样的反馈。
等到安全反馈传递给他们时，他们早已投入到好几个新功能的开发中了。整件事对他们来说只是个麻烦，他们只会做最低限度的工作来了事。这种沟通往往充满对抗性，常听到的回应是："我最少要做什么才能让你别来烦我？"这显然不是一个有效的解决方式。
更大的问题在于，现有的策略规范往往与现代开发方式格格不入，由此产生的摩擦让安全团队自己也难以全面执行。而一旦开始选择性执行，就会显得随意武断，进而引发"破窗效应"——既然可以忽略这些规定，为什么不能忽略所有规定？我认为，全面审计带来的信息量太大、令人沮丧，如果连这些规则都无法审计，就永远得不到任何积极的回应。
那么，如何打破这个僵局？面对的挑战有很多，今天时间有限，我重点谈几个最关键的。首先，必须重新审视大家对应用安全的认知方式。
通常，AppSec负责人会认为，通过以下几类行动就能解决上述问题：制定更贴近实际、更易落地的产品安全策略，避免策略过时；更好地执行策略，并建立合理的指标激励机制；加强培训，因为很多人认为团队只是知识不足，培训之后问题自然迎刃而解；加强协作，甚至引入新工具。
上述这些举措本身并没有问题，但仅靠它们还不足以从根本上解决问题。为此，我提出了一套文化转型方法，能够从根本上重构应用安全的流程和运营模式，实现向现代DevSecOps方式的转变。这套方法充分借鉴了DevOps的核心理念，对团队来说也更易于接受和落地。
我在Comcast工作期间开发并验证了这套转型蓝图。采用这套方法的团队，主动承担起了安全责任，并按照我所描述的方式推进工作。结果显示，他们在生产环境中的漏洞数量仅为未参与该项目团队的六分之一；与参与项目前相比，漏洞数量同样降低到了原来的六分之一；更重要的是，整个项目只需四分之一的人力即可运行。
这套方法效果显著，最终在Comcast全部600个团队中全面推广，旧有的应用安全项目也随之逐步退出历史舞台——到了关键节点之后，新团队基本上都必须通过这套程序进行接入。
Q&A
Q1：DevSecOps和传统AppSec有什么核心区别？
A：传统AppSec采用"守门人"模式，在开发完成后集中进行安全审计，效率低且容易造成团队对抗。DevSecOps则将安全作为共同责任，融入软件开发生命周期的每个阶段，开发和安全团队协作推进，减少摩擦，提升安全效果。尤其在DevOps高频发布的场景下，传统方式根本无法跟上节奏，DevSecOps才是更适配的安全模型。
Q2：Larry Maccherone在Comcast的DevSecOps项目取得了哪些具体成效？
A：Larry Maccherone在Comcast推行的DevSecOps转型项目成效非常显著：参与项目的团队，生产环境漏洞数量降至未参与团队的六分之一；与参与前相比，漏洞数量也减少了六分之五；整个项目所需人力仅为原来的四分之一。最终该方案被推广至Comcast全部600个开发团队，完全取代了原有的应用安全项目。
Q3：为什么传统应用安全策略在现代开发团队中难以有效执行？
A：主要有两个原因：一是策略内容往往与现代开发实践脱节，落地时摩擦较大，安全团队只能选择性执行；二是选择性执行会造成规则显得随意，引发"破窗效应"，让开发人员觉得既然部分规则可以忽略，其他规则也可以不遵守。此外，全面审计产生的信息量巨大且令人沮丧，反而难以获得团队的积极配合。
热门跟贴