将DevSecOps方法分层进行，在强大的安全性需求和快速部署需求之间取得了适当的平衡。
DevOps运动改变了集成和发布工作的方式。将我们从缓慢的(有时是一年一次的)发布周期带到每天(在某些情况下甚至是每小时)发布。能够立即编写代码并查看生产中的更改。虽然这可以给客户和我们一个温暖和模糊的感觉，它也可以为恶意攻击者提供一个机会。
DevOps是打破壁垒并支持快速响应市场变化和客户需求的一个惊人的第一步，但仍需要打破一个重要的壁垒，引入一个重要的团队:安全操作(SecOps)。
为了将这个关键的组包含在对生产环境的变更的持续集成和部署(CI/CD)中，将DevOps重新定义为DevSecOps。在这方面所面临的挑战与在将开发和运维结合在一起时所面临的挑战是相同的:开发人员希望快速移动并经常更改，而运维则希望稳定和不经常更改。安全团队倾向于稳定性和不频繁的变更，因为变更可能意味着重复的安全测试和环境的认证。
当以DevOps的速度前进时，怎么能期望这些团队每天或每周都重做他们的工作呢?
安全层
在深入探讨这个问题之前，应该讨论一个关键的安全实践:层次安全或深度防御。分层安全是应用多种安全措施的实践，每一层都覆盖上一层和下一层，从而创建一个安全控制网络，共同保护技术系统。
在一种分层的安全方法中，公司通过使用访问控制(如WAN网关防火墙、现场钥匙卡输入和数据休眠加密)来减少对其技术系统的入侵。控制列表是广泛的，但重点是，没有一个控制可以充分保护技术系统。同样的方法也适用于对应用程序执行安全性分析。
联系公司的应用程序安全团队，询问他们使用什么扫描和工具来确保编写的应用程序是安全的。很有可能，他们不会用一个工具来回复，因为没有一个工具可以完成所有的工作。相反，可能会提供一个工具列表，或者使用的工具类型，或者希望开发团队使用的工具类型。
这又回到了之前的问题:如何在执行所有这些扫描和使用所有这些工具的同时，期望维护一个连续的部署周期?这是一项艰巨的任务;有些扫描和工具需要几个小时、几天甚至更长时间。
内联扫描
虽然一些安全工具和扫描器确实需要很长时间才能运行，但是可以并且应该在开发生命周期的早期利用一些更快的工具来形成DevSecOps的第一层。这就是shift-left背后的思想:将流程从开发生命周期的末端(或右侧)移动到开始或中间。,进一步了。
第一层应该包括运行几秒钟(或者几分钟)的工具和扫描程序。一些常见的例子有代码碎片化、单元测试、静态代码分析器(如SonarQube)、第三方依赖漏洞检查(如OWASP依赖检查器)，以及集成测试的一个子集。
可能会问，“linting代码和运行单元测试如何适合DevSecOps?”软件中的漏洞可以为对手提供一个完美的突破口。例如，在过去的两份重要的web应用安全报告(2013年和2017年)中，OWASP将代码注入列为头号漏洞。Linters、单元测试和静态代码分析可以帮助捕获一些错误，并可能有助于防止代码中的安全漏洞。记住，这是关于层的，这只是第一个。
由于这些工具和扫描花费的时间非常少，所以最好在开发生命周期中尽可能地将它们往左推。当开发人员将代码推入Git仓库并打开pull请求时，这些工具和扫描程序将运行，以确保代码在合并之前通过。除了确保主干分支处于可构建状态之外，在开发生命周期的早期使用这些工具还可以尽早地向开发人员提供反馈。
预部署扫描
DevSecOps的第二层包括与部署管道内联运行的工具，完成这些工具需要几分钟到一小时的时间。这可能包括更深入的第三方漏洞扫描、Docker图像扫描和恶意软件扫描。
这一层的一个关键是扫描器和工具在生成构建工件之后并在它们被存储到任何地方(如Artifactory或Amazon Elastic Container Registry)之前进行操作。更重要的是，这一层的任何失败都应该立即停止当前的部署，并向开发团队提供反馈。
另一个关键是并行化。开发人员希望尽可能快地部署他们的更改，并且连续运行多次扫描(每次扫描最长可花费一个小时)将不必要地降低部署周期。通过并行运行这些工具，部署速度的降低相当于运行时间最长的扫描。
部署后扫描
DevSecOps的下一层包含了可以并且应该在将代码部署到预生产环境之后使用的工具和扫描器。这些工具可能包括性能和集成测试以及像OWASP Zap这样的应用程序扫描程序。应该努力使这一层快速运行，希望在一个小时或更少的时间内，为开发人员提供快速的反馈，并限制对CD进程的影响。
以确保不误将脆弱的代码部署到生产,这一层应该运行的CD管道与目标被删除的工件,破坏了环境,或回滚的环境事件的任何扫描仪发现漏洞或者失败。
根据行业、安全性和法规需求，可以在这一层成功完成后将部署自动化到生产环境中。应该已经有足够的自动化扫描和测试在管道中，以合理地证明应用程序的安全性和坚固性。
连续扫描
讨论的大多数扫描器和工具都已经嵌入到CI/CD管道中。目标是提供应用程序安全性的合理保证，同时平衡这些工具对CI/CD管道时间线的影响。
DevSecOps的最后一层是连续扫描或连续安全(CS)。正如持续集成、测试和部署是DevOps的同义词一样，持续安全也是DevSecOps的同义词和基石。这一层包括Nessus、Qualys、IBM App Scan等工具，以及其他基础设施、应用程序和网络扫描工具。
CS并没有嵌入到CI/CD管道中，而是将其作为一个异步的、持续的过程，并向开发人员提供持续的反馈。开发人员如何接收和响应这些反馈需要讨论并达成一致。一种可能是将发现作为严重级别分类的开发团队的罚单进行归档。开发人员将在收到任何Sev1后立即开始工作，并在较长的周转时间内处理Sev2和Sev3。
这些工具和扫描器如何启动以及它们运行的频率是CS的另一个方面，涉众应该对此达成一致。具有API的工具可以在部署完成后通过CI/CD管道启动。其他可能需要做的需要或基于一些时间节奏。不管怎么做，重要的是这些工具和扫描器不是一年运行一次，甚至是一年一次或两次。相反，这些工具和扫描器应该尽可能频繁地运行，并且尽可能频繁地对应用程序有意义。
结论
正如不能通过使用一两个工具或安全原则来确保技术系统的安全性一样，应用程序的安全性也不能仅仅依赖于一两个工具或扫描仪的类型。它采用一种分层的方法来应用不同的工具和扫描器，从而合理地确保应用程序和其所运行的基础设施的安全性。
通过将DevSecOps方法分层，可以更容易地在安全性、行业和法规需求之间取得平衡，并希望快速地进行部署。毕竟，能够一天部署许多次的好处之一是，不需要等到下一个发布周期，也就是三到六个月之后，才推动对Sev1安全漏洞的修复。
