devops 分层测试
DevOps运动改变了我们整合和发布工作的方式。 它使我们从缓慢的发行周期（有时是每年的发行周期）过渡到每天（甚至在某些情况下甚至每小时）发行。 我们能够编写代码并几乎立即看到生产中的变化。 虽然这可以给我们和我们的客户一种温暖而模糊的感觉，但它也可以为恶意攻击者提供机会。
DevOps是突破壁垒并支持对市场变化和客户需求的快速响应的令人惊叹的第一步，但是我们仍然需要打破一堵重要的壁垒，我们需要折中的重要一环：安全运营（SecOps）。
为了在生产的变更的持续集成和部署（CI / CD）中包括这个至关重要的小组，我们将DevOps重新定义为DevSecOps。 我们在这项工作中面临的挑战与在将开发和运营整合在一起时所面临的挑战相同：开发人员希望快速行动并经常进行更改，而运营则需要稳定和不频繁的更改。 安全团队倾向于支持稳定性和不频繁的更改，因为更改可能意味着重复安全测试并再次对环境进行认证。
当我们以DevOps的速度前进时，我们如何期望这些团队每天或每周重做他们的工作？
分层安全
在深入探讨这个问题之前，我们应该谈谈一种关键的安全实践：分层安全或深度防御。 层级安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可一起工作以保护技术系统。
在分层安全性方法中，公司通过使用诸如WAN网关防火墙，本地钥匙卡输入和静态数据加密之类的访问控制来减轻对技术系统的入侵。 控件列表很广泛，但要点是，没有任何控件可以充分保护技术系统。 同样的方法适用于对我们的应用程序执行安全性分析。
与公司的应用程序安全团队联系，并询问他们使用哪些扫描和工具来确保编写的应用程序安全。 可能的是，他们不会使用一种工具进行答复，因为没有一种工具可以全部完成。 相反，他们可能会向您提供他们使用或期望开发团队使用的工具列表或工具类型。
这使我们回到了之前的问题：在进行所有这些扫描并使用所有这些工具时，我们如何期望维持一个连续的部署周期？ 这是一项艰巨的任务。 其中一些扫描和工具需要花费数小时，数天或更长时间。
内联扫描
尽管某些安全工具和扫描器需要很长时间才能运行，但仍有一些更快的工具可以并且应该在开发生命周期的早期使用，以形成我们的第一层DevSecOps。 这就是左移背后的想法：将流程从开发生命周期的末尾（或右侧）移到开始或中间，即再往左移。
第一层应包括需要花费几秒钟（或几分钟）才能运行的工具和扫描程序。 一些常见的示例是代码linter，单元测试，诸如SonarQube之类的静态代码分析器，诸如OWASP Dependency Checker之类的第三方依赖项漏洞检查，以及可能的一部分集成测试。
OWASP将代码注入列为第一漏洞。 短绒，单元测试和静态代码分析可以帮助捕获我们的一些错误，并可能有助于防止代码中的安全漏洞。 请记住，这全都与图层有关，而这仅仅是第一步。由于这些工具和扫描只需要很少的时间，因此最好将它们推到开发生命周期中的最左侧。 当开发人员将代码推送到我们的Git存储库并打开请求请求时，这些工具和扫描程序将运行以确保代码在合并之前通过。 除了确保我们的主干分支保持可构建状态外，在开发生命周期的早期就拥有这些工具还可以尽早且经常向开发人员提供反馈。
部署前扫描
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的另一个方面。 部署完成后，可以通过CI / CD管道启动具有API的工具。 其他可能需要根据需要或基于一定的时间节奏来完成。 无论如何完成，重要的是这些工具和扫描仪不会仅运行一次，甚至每年运行一次或两次。 相反，这些工具和扫描仪应尽可能频繁地运行，并应对应用程序有意义。
结论
正如我们不能通过使用一两种工具或安全性原则来确保技术系统的安全性一样，我们应用程序的安全性也不能仅取决于一两种工具或扫描仪的类型。 它采用分层的方法来应用不同的工具和扫描程序，以合理地确保我们的应用程序及其运行的基础结构的安全性。
通过将我们的DevSecOps方法分成几层，我们可以更轻松地在安全性，行业和法规要求以及快速迁移和经常部署的愿望之间取得平衡。 毕竟，每天能够部署多次的好处之一是，我们无需等到下一个发布周期（即三到六个月）就推出该Sev1安全漏洞的修复程序。
翻译自: https://opensource.com/article/19/9/layered-security-devops
devops 分层测试