什么是DevSecOps？

　　随着每个人都转向云计算，人们对DevOps进行了大量宣传：如何使流程更快，更轻松，更高效，作为一名开发人员，我喜欢事情变得更容易,作为安全人员，太容易却让我感到害怕，Devops没有强调安全地迁移到云端，这就需要DevSecOps。

　　DevSecOps是在软件开发生命周期（SDLC）的早期引入安全性，目标是让参与SDLC的每个人负责安全来开发更安全的应用程序。让业务，技术和安全协同工作以生产更安全的产品似乎梦想成真，也许好得令人难以置信？让我们进行更多研究探讨，看看DevSecOps是否是构建安全产品所需的银弹。

　　首先，我们来谈谈为什么我们需要DevSecOps。
　　多年前，软件产品遵循瀑布式方法，这是一种线性顺序方法，随着向云计算和动态资源配置的转变，开发人员在应用程序开发的速度、规模和成本方面获得了许多好处。这些好处非常适合采用DevOps运动。

　　DevOps强烈主张SDLC所有步骤的自动化和监控，目标是缩短开发周期，增加部署频率和更可靠的版本，所有这些都与业务目标保持一致。但稳定的基础架构和应用并不等同于安全的基础架构和应用，在瀑布生命周期中，安全检查是在产品发布之前就已经完成了，在发布产品的过程中，安全被视为一个障碍，也就是最后一次检查。

　　目前，大多数团队都使用敏捷方法进行软件开发，在敏捷环境中，重点是快速交付，使用迭代计划和反馈结果，团队可以不断将产品变成可交付成果，从而与业务需求保持一致。

　　适应不断变化的需求对于提供有意义的产品是非常有用的，但如果你每周发布一个新版本产品，那么何时测试安全漏洞？遗憾的是，传统的安全流程并没有跟上敏捷/ DevOps环境的步伐，使得安全性成为软件开发中的主要障碍，通常会绕过它。如果它没有被绕过，开发团队也很少有足够的时间在产品上线之前解决所有问题，这意味着一个不安全的应用程序存在于互联网上的某个地方。

　　具有讽刺意味的是，忽略安全性以避免错过最后期限的风险实际上会给应用程序带来更多风险，SDLC中的安全缺陷可能导致严重漏洞，例如由错误代码导致的漏洞。这就是我们需要DevSecOps的原因。

　　在DevSecOps中，两个看似相反的目标，即“交付速度”和“安全代码”，被合并为一个简化/自动化流程，DevSecOps的目的是建立在“每个人都对安全负责”的思维模式上，它是关于推动安全性并自动执行核心安全任务。

　　我们希望将安全性推到SDLC的整个过程开始，以确保应用程序安全性作为一个代码开始，通过向前部移动，团队可以快速发现和分析漏洞，然后调整其代码以减轻这些漏洞。

　　DevSecOps允许开发人员专注于编写高质量和安全的代码，使团队能够发布高安全应用程序，好处很简单：

从一开始的安全性可以最大限度地减少漏洞的可能性
拥有在管道中运行的自动化安全工具，它可以让安全团队成员专注于悬而未决的成果
开发人员和安全团队之间更好的协作和沟通
提高安全性和企业的运营效率

　　但是，DevSecOps也存在一些挑战，即使将安全性融入发布管道，仍然存在绕过安全检查点的方法，让我们举一个例子，如果发现某个漏洞，则使用漏洞扫描程序来阻止构建/部署，作为开发人员，你知道该漏洞是什么，并且知道自己的代码存在这样漏洞，但你确实需要马上发布版本，因此，你可以找到躲过安全扫描的方法，从而实现成功构建。

　　另一种常见情况是，如果存在一个或多个某种严重程度的发现，团队决定停止他们的构建，但是，另外一个团队可能会说他们不想停止他们的构建，除非这个发现很高或很关键，停止构建虽然这有助于立即识别和解决高优先级问题，但是也有影响发布效率的问题。

　　现在我们已经了解了DevSecOps的优点和缺点，如何实际实现它？传统的DevOps工具（如Jenkins和Git）是构建DevOps管道的基础，市场上有许多安全工具，从开源到专有解决方案，其中许多可以集成到现有的管道中。以下是我根据经验和互联网编制的列表：

Checkmarx：一种SAST（静态应用程序安全测试）工具，用于分析应用程序的代码，指出存在安全漏洞的缺陷。
WhiteSource：一种开源漏洞扫描程序，可在后台自动连续运行，跟踪开源组件的安全性，许可和质量，并将它们与WhiteSource的开源存储库综合数据库进行匹配。
Zaproxy：OWASP Zed攻击代理（ZAP）是一种易于使用的集成渗透测试工具，用于查找Web应用程序中的漏洞。

DevSecOps不是解决我们所有问题的神奇方法，但对我和其他许多人来说，这是不可替代的。