【51CTO.com快译】DevSecOps是指先在应用程序开发的生命周期中引入安全性，从而尽可能地减少漏洞并使安全性更接近IT和业务目标。
DevSecOps定义
DevSecOps是软件行业的一种文化转变，旨在将安全性纳入现代应用程序开发和部署所特有的快速发布周期中，也称为DevOps运动。接受这种左倾心态需要组织弥合开发团队和安全团队之间通常存在的鸿沟，以至于许多安全流程都由开发团队自己进行自动化和处理。
DevSecOps与传统软件开发有何不同?
传统上，主要的软件开发人员过去每隔几个月甚至几年发布一次新版本的应用程序。这为代码提供了足够的时间来保证质量和进行安全测试，这些过程由独立的内部或外部合同的专门团队执行。
但是，在过去的十年中，公共云、容器和微服务模型的兴起，将整体式应用程序分解为独立运行的较小部分。这种故障还直接影响了软件的开发方式，导致了滚动发布和敏捷开发实践，在这些实践中，新功能和代码不断以快速的步伐投入生产。其中许多流程已通过使用新技术和新工具而实现了自动化，从而使公司能够更快地进行创新并保持竞争优势。
云，容器和微服务的进步也导致了业界所谓的DevOps文化的出现，开发人员现在可以在不等待单独的基础架构团队为他们完成的情况下配置和扩展所需的基础架构。现在，所有主要的云提供商都提供了API和配置工具，这些API和配置工具允许使用部署模板将基础结构配置视为代码。
尽管DevOps文化为软件开发带来了很多创新，但是安全性往往无法跟上代码的生产和发布的新速度。DevSecOps旨在纠正这一问题，并将安全性测试完全集成到持续集成(CI)和持续交付(CD)管道中，同时也积累了开发团队所需的知识和技能，以便可以测试和修复结果也可以在内部完成。
构成真正的DevSecOps环境的三个关键因素是：
· 安全测试由开发团队完成。
· 测试期间发现的问题由开发团队管理。
· 解决这些问题的责任在于开发团队。
应用程序安全测试公司Veracode的联合创始人兼首席技术官Chris Wysopal告诉CSO：“最后一个需要花费一些时间，但是我认为那是应用程序安全真正成为DevSecOps的时候，不需要一个单独的团队了。”
实现真正的安全/开发集成
根据Wysopal的说法，实现最后一步之所以很困难，是因为开发人员必须建立无需外部指导即可修复与安全相关的bug所需的技能，而这需要时间。许多团队通过在开发团队中嵌入所谓的安全冠军来达到目标。这是一个在应用程序安全方面具有专业知识的人，并且比整个团队中的大多数人接受了更高级的培训，即使对整个团队进行安全编程实践的培训也应该是过程的一部分。此人可以查看安全修补程序，以确保它们是正确的。
这并不意味着安全拥护者不能在团队之外寻求专家意见。例如：向该公司的应用程序安全测试提供商提供服务，后者可能会为客户提供咨询服务。在特殊情况下，这不是正常的情况。这与拥有独立的开发和安全团队，以及将一个或多个安全团队成员嵌入开发团队不同。
根据DevOps自动化和开源治理公司Sonatype的CTO Brian Fox的说法，开发和安全性之间的集成也需要在管理层进行。Fox告诉CSO：“当安全任务与完全集成到开发中而不完全融合时，我认为您没有得到正确的选择。有时候，即使人们在同一个团队中工作，您也会遇到目标不同的管理层冲突。这是许多组织中发生的事情的一个要素。”
Fox表示，这是在质量检查之前发生的，那里曾经有一个质量检查经理和工程经理，他们在一起工作，但是总有一些部落主义在进行。“一旦这种情况消失了，质量保证已成为开发团队人员所做工作的一部分，您就不再看到我们与他们的心态，而我们在安全性方面还没有到位。我认为这就是很多公司挣扎。”
DevSecOps测试和工具
硅谷科技公司在早期采用DevSecOps方面处于领先地位，但是当时可用的安全测试工具对开发人员并不友好。开发人员需要命令行工具，这些工具可以自动化，以便他们可以轻松地调整各种配置，并且可以轻松地将其输出导入错误跟踪器。而传统的安全扫描程序在设计时就考虑了安全团队和CISO，其目标是治理、安全性、政策合规和风险管理。
慢慢地出现了由开发人员为开发人员创建的新工具，这些新工具已集成到开发环境和CI / CD工作流程中。有些是开源的，有些是围绕它们构建的启动业务模型，但是当它们解决了开发人员的需求时，他们并没有真正满足CISO的需求。
如果使用了许多不同的开放源代码工具，则开发团队可能会觉得他们正在涵盖他们认为需要涵盖的内容。Wysopal说，从治理的角度来看，安全团队很难将所有这些不同的分散工具映射到公司的策略。
在过去的两年中，传统的应用程序安全供应商已更改其产品，以解决这两种用例：提供CISO所需的分析和报告，并具有开发人员期望的灵活性和易用性。一些针对诸如GitHub之类的开发人员的基于云的服务提供商已开始直接在其服务中添加安全性测试。当它不能作为本机功能使用时，通常可以作为第三方供应商的集成在服务市场中使用。
“在过去的两年中，我们看到了事情的摇摆朝着无所不包的单一套件的方向发展。” Fox警告说，当下一个颠覆性技术问世时，这种整合将在某个时候逆转，企业需要为此做好准备。套件的问题在于，它们可以在组织需要的一项或多项事情上表现出色，但随后包含了其他可用的功能，因为它们是随包免费提供的。随着时间的流逝，这可能导致组织内部的开发人员群体破裂，他们将开始测试和使用比公司认可的套件更好地满足其需求的其他工具。
从治理的角度来看，拥有不受管理的团队是不好的，但是公司需要意识到，从现在起的一两年内，这种情况将不可避免地发生，尽管尝试限制工具的使用，但总会有一些开发人员来做自己的事情。“最早采用云技术的人有时是规模更大的组织中的个人团队，他们在反驳购买计算机所需的时间。” Fox说到。
DevSecOps的采用
根据Wysopal的说法，越来越多的公司正在将自动化安全扫描集成为CI / CD管道的一部分，但是由于他所说的“安全债务”(即导致生产中存在的漏洞数量)，结果可能不会立即显现。因为开发人员选择不修复它们。
发生这种情况的原因可能多种多样，包括无法立即对其进行修复，由于存在其他缓解措施而没有计划对其进行修复，或者由于它们的严重性较低而没有对其进行修复。
Veracode 发布的2019年软件安全状态报告中，基于一年中，其对85,000个应用程序执行的扫描收集的数据结果显示，应用程序中发现漏洞的平均修复时间为171天，而平均时间为59天。但是，这会因应计的安全债务而歪曲，并且修复的平均时间实际上保持不变。
将扫描结果与特定应用程序的扫描频率相关联时，频率增加表明CI / CD工作流程中集成了自动扫描。数据显示，每天扫描的应用程序的中位时间为19天，而68天为对于每月扫描的应用程序。这表明扫描频率越高，修补漏洞的可能性就越大。
该公司在报告中总结道：“与金融债务一样，要摆脱担保债务，必然需要改变习惯以偿还余额。过去几年中，软件开发和IT运营(DevOps)的集成以及安全性在这些流程中的集成(通常称为DevSecOps)无疑已经改变了习惯。”
向DevSecOps进行真正的文化更改的另一个好处是，代码中存在的严重漏洞的数量也应该减少。Veracode的数据显示，与10年前相比，没有漏洞的应用程序的总体百分比实际上有所下降，这表明情况已经恶化，但是没有高严重漏洞的应用程序的百分比实际上已经从66%增加到80%。
福克斯说：“我看到许多组织仍在为这种模式而苦苦挣扎。” “他们正在朝着这个持续的开发环境迈进，他们拥有基础架构和CI，并且正在使用容器。然后，他们有一个应用程序安全团队，他们将在以后运行扫描，生成报告，有时甚至是纸质打印报告-并将它们带入开发中，而不是利用能够授权开发的工具来避免这些错误。我看到的大多数组织仍然属于我们，他们，开发人员或安全性方面。”
也就是说，即使使用DevSecOps，安全专家也仍然需要执行某些任务，而手动测试仍然可以发挥作用。例如：使用全自动扫描很难发现逻辑缺陷或设计缺陷。
Wysopal说：“我们开始看到的是，手动测试不是一年一次或每年两次。“它具有更大的迭代性。它是在DevOps流程中进行更多工作的，其中可能需要进行为期两周的冲刺，而他们正在执行一项新功能，该功能具有安全性，因为为此进行的少量手动测试如果安全支持者对手动测试有足够的了解，并且可以满足开发团队自己进行的目标，那么有时他们可以做到。
原文地址：https://www.csoonline.com/article/3245748/what-is-devsecops-developing-more-secure-applications.html
作者：Lucian Constantin
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
