系列文章（1）：浅谈企业 DevSecOps 实践：基本原则

系列文章（2）：浅谈企业 DevSecOps 实践: 安全测试集成 

在本文中，我们将向你展示如何在你的 DevOps 自动化框架中集成安全性。我们将要解决的问题是“我们希望将安全测试集成到开发管道中，并将从静态分析开始。我们该怎么做? ”、“我们理解“左移” ，但这些工具有效吗? ”以及“ 你建议我们从哪些工具开始，以及如何集成这些工具? 。由于 DevOps 鼓励在开发和部署的所有阶段进行测试，我们将讨论构建的管道会是什么样，以及适合不同阶段的工具。安全测试通常与质量保证团队可能已经部署的功能测试和回归测试并列。除了这些典型的在构建之后的测试点之外， 你还可以在构建之前在开发人员的桌面上进行测试，在构建之前和之后的代码库中进行测试，以及在预部署阶段进行测试。

构建过程

在我们接到的几个电话中，有几个高级安全主管不知道构建过程的组成。 这并不是一种谴责，因为许多安全人员并没有参与软件生产和交付，所以我们想粗略的阐述一下开发人员使用的过程和术语。 如果你对此已经很熟悉，那么请跳到“构建安全工具链”。

大多数读到这篇文章的人都会熟悉“夜间构建”，在这种模式中前一天检查的所有代码都是在夜间编译的。 当你习惯性的查看日志，看看构建是否失败以及为什么失败的时候就像你也同样熟悉早晨要喝咖啡的习惯。大多数开发团队已经这样做了十年或更长时间。 自动化构建是公司通向支持代码开发的流程的完全自动化道路上许多步骤中的第一步。在过去的几年里，我们已经把我们的“脚踩在地板上”，利用越来越多的自动化来加快软件交付的步伐。

通往 DevOps 的路径通常分为两个阶段: 首先是持续集成，它管理代码的构建和测试；然后是持续部署，它将整个应用程序堆栈组装成一个可执行的环境。与此同时，这个过程的所有阶段都在不断地改进，使其更容易、更快、更可靠。要达到这个目标需要大量的工作，使用的脚本和模板通常需要几个月的时间来构建基础，而将它们变得成熟最终成为可靠的软件交付基础设施则需要几年的时间。

持续集成

持续集成(CI)的本质是帮助开发人员定期检查小迭代代码的进展。对于大多数团队来说，这需要对一个共享的源代码储存库或服务器进行多次更新，每天还要进行一次或多次构建。在这里的关键是，通过更小、更简单的附加功能，我们就可以更容易、更快地发现代码缺陷。 这些本质上是敏捷概念，在驱动代码的过程中实现，而不是在驱动人的过程中实现(比如 scrums 和 sprints)。持续集成的定义在过去的十年里已经发生了变化，但是在 DevOps 的环境下，持续集成意味着代码不仅是使用支持的库构建和集成，而且是通过自动分发进行测试的。 此外，DevOps CI 意味着代码变更并不应用于分支，而是直接应用于代码的主体，减少了可能困扰开发团队的复杂性和集成噩梦。

这听起来很简单，但实际上需要大量的基础设施支持工作。构建必须完全脚本化，并且构建过程在代码变更时发生。 每次构建成功后，应用程序堆栈都会被打包并传递给测试用户。 测试代码在单元测试、功能测试、回归测试和安全测试之前构建，并成为存储库和自动化过程的一部分。 每当新的测试可用时，测试工作就会自动开始，但这也意味着每个新的构建都会应用新的测试。 这还意味着，在测试工作可以启动之前，必须自动设置、配置测试系统，并为其输入必要的数据。 自动化脚本必须为流程的每个部分提供监控能力，并在事件发生时将成功或失败的信息反馈给开发和运维团队。 要创建脚本和工具来实现这一切，需要运维、测试和开发团队紧密合作。

下图显示了容器的自动构建管道，包括安全测试点。 再次强调，这种层次的编排不是一蹴而就的，而是一个需要数月建立基础、数年才能成熟的渐进过程。 但这正是持续改进的本质所在。

持续部署

持续部署看起来非常类似于 CI，但是侧重于向终端用户发布软件，而不是构建软件。它包含了一些类似于包装、测试和监控的任务，但有一些额外的不同。在成功完成构建周期之后，结果将提供给持续部署(Continuous Deployment，CD)流程。 CD 在自动化和弹性方面又向前迈出了一大步，同时自动化了应用程序堆栈的发布管理、设置和最终配置，然后启动新的应用程序代码。

当我们谈论 CD 的时候，人们有两种方式来接受这个概念。 有些团队只是将新版本的应用程序启动到现有的生产环境中。CD 过程让应用层实现了自动化，但不能让服务器、数据或网络层实现自动化。我们发现这在本地应用程序和私有云部署中很常见，一些公有云部署也仍然使用这种模型。

与我们交谈过的安全团队中有很大一部分是真正害怕持续部署的。他们说“你怎么可能允许代码在没有检查和监督的情况下运行! ” ，他们忽略了一点，即代码在所有安全测试通过之前不会启动。一些 CI 管道包含一些测试的手动检查点。 根据我们的经验，CD 意味着更可靠和更安全的版本。CD 解决了困扰代码部署的几十个问题，特别是在容易出错的手工变更以及生产和开发之间支持库的修订方面。一旦进行了充分的测试，就没有理由不信任 CD。

并不是所有的公司每天都会在发布产品的过程中发布代码；事实上，只有不到10% 的公司会持续发布产品代码，但是一些著名的公司，如 Netflix，Google 和 Etsy，一旦测试完成，就会自动发布产品代码。 但是大多数公司(例如: 那些不在内容或零售垂直领域的公司)没有一个好的业务需要每天发布多次更新，所以他们不需要发布代码。

管理和蓝绿部署

大多数公司都有一个较慢的发布周期，通常每一到三个 sprint 就会有一个“上线”的节奏。我们称这些为“托管发布”，因为执行和计时是手动操作的，不过大多数操作是自动的。此外，这些公司还采用了另一种非常强大的技术：自动化基础设施部署。在这一阶段， 你可以循环整个基础结构堆栈与应用程序。这些类型的部署依赖于软件运行环境的自动化；这可以很简单的实现，比如支持一个 Kubernetes 集群，或者利用 Openshift 在 Google GCP 中运行 Terraform 模板，或者通过 Cloudformation 模板启动一个完整的 AWS 环境。 基础设施和应用程序都是代码，因此两者都是同时启动的。这在公有云部署中正变得越来越普遍。

但是这种发布方法提供了显著的优势，并为所谓的“蓝-绿”或“红-黑”部署提供了基础。新旧代码并排运行，近似于镜像，各自在自己的一组服务器上运行。旧的代码(即: 蓝色)继续服务于用户请求，而新的代码(即: 绿色)只由选定的用户或测试工具执行。 部署是负载均衡级别上的一个简单的重定向，内部用户和活动客户可以慢慢地重定向到 绿色 服务器，本质上是将这些用户作为新系统的测试人员。如果新代码通过了所有需要的测试，负载均衡器将所有流量发送到绿色服务器，蓝色服务器就会下线，然后绿色服务器成为了新的 蓝色服务器。如果发现错误，负载均衡器会被指向原来的“蓝色”代码，直到有新的修补程序可用。这基本上是生产中的预发布测试，即使发现了缺陷或安全问题，也可以立即进行回滚。

安全测试阶段

桌面安全测试

集成开发环境(Integrated Development environment，IDE)是大多数开发人员的标准。 Visual Studio，Eclipse，IntelliJ 等等，一些是针对特定的语言或环境定制的。这些桌面工具不仅有助于构建代码，而且它们集成了语法检查器、运行时、终端、包和许多其他功能，使构建代码更加容易。商业安全性供应商为流行工具提供插件，通常提供一种静态分析形式。有时这些工具是交互式的，在编写代码时提供建议，而其他工具在提交代码之前根据需要检查当前修改的文件。甚至有一两个工具实际上并不是作为 IDE 的插件，而是作为一个独立的工具工作，并在代码提交到仓库之前运行。由于代码扫描通常只是开发人员正在处理的模块或容器，因此代码扫描的速度非常快。在这个阶段正确地进行安全扫描可以降低构建服务器在代码提交后发现安全问题并失败的可能性。

我们与使用这些工具的开发团队合作，他们发现这些工具是有效的，并且能够按照承诺交付。与我们交谈的许多开发人员并不喜欢这些安全插件，因为他们觉得这些插件噪音大、让人分心。我们建议尽可能使用这些桌面扫描器，但要认识到使用时的文化障碍，并提醒安全团队可能需要帮助改变文化，并允许随着时间的推移逐渐采用。

代码库扫描

源代码管理、配置管理数据库、容器注册中心和类似于这些类型的工具存储代码，并帮助管理任务，如版本控制，IAM 和审批流程。 从安全的角度来看，一些成分分析供应商已经集成了他们的产品，以检查开源版本控制是否正确，以及使用的平台是否包含已知的 CVE。 为已知的好版本和其他版本控制特性创建数字指纹的附加设施正变得越来越普遍。

构建服务器集成

构建服务器构建应用程序。通常由内部开发的多个源代码和开放源代码组成，在构建应用程序时使用许多“工件”是很常见的。幸运的是，像 Jenkins 和 Bamboo 这样的构建服务器在建立之前和之后都有处理这些工件所需的钩子。这通常是测试集成到构建管道中的方式。利用此功能将是安全测试集成的核心。 在这个阶段通常集成了成分分析、SAST 和自定义测试。

预发布

对于“代码完成”或系统测试，将应用程序的所有部分和支持的应用程序堆栈组装在一起，设置一个预生产“准备区域”来模拟生产环境，并促进完整的测试。我们发现了几个最近的趋势，预生产测试就是其中之一。由于公有云资源允许快速弹性和随需应变的资源采购，公司正在开发测试环境，运行 QA 和安全测试，然后再次关闭它们以降低成本。这用于执行以前在生产中执行的DAST测试。在大多数情况下，在大多数情况下，这是利用蓝绿部署模型在与现有的生产环境并行的新环境上运行许多不同类型测试的方法。