考虑到 DevOps 对于大多数读者来说是全新的概念，所以在第一篇文章中我们分享了一个关于基本原则的讨论，以及 DevOps 是如何帮助解决软件交付中常见的许多问题的。你可以在上篇文章中找到你想要了解的更详细的背景资料。出于本文的目的，我们将讨论一些与安全团队集成和使用 DevOps 原则进行安全测试直接相关的原则。 这些概念为解决我们在第一部分中提出的问题奠定了基础，在我们讨论 DevOps 环境中的安全工具和方法时，读者需要理解这些概念。

DevOps 与安全

构建安全性

构建安全性，听起来是一个可怕的事实，但是在代码开发过程中广泛使用应用程序安全性技术，相对来说还是较新的事情。 当然，对这个领域的研究已经有几十年的历史了，但是应用程序安全性更多地是通过网络或应用程序防火墙加固的，而不是嵌入到代码本身。 安全产品供应商发现，在应用程序之外理解应用程序请求做安全检测并阻止攻击是非常困难的。 在可能的情况下，修复易受攻击的代码并关闭攻击载体要有效得多。 附加工具正在变得越来越好用——有些工作是在应用程序上下文中进行的——但是如果可能的话，最好能在代码中解决这些问题。

构建安全性的一个核心概念是“左移” ，或者是我们在软件开发生命周期(SDLC)中更早地集成安全测试的想法——这些阶段按照从左到右的顺序通常可以分为设计、开发、测试、预生产和生产。 从本质上讲，我们将更多的资源从生产转移到最右端，并将更多的资源投入到设计、测试和开发阶段。 这些思想诞生于精益生产，Kaizen 和 Deming 的原则，已被证明是有效的，但通常应用于实物制造行业。 DevOps 已经在软件开发领域得到了推广和应用，这证明我们可以通过在研发过程的早期将缺陷安全检测左移来实现以较低的成本提高安全性。

自动化

对于我们谈到的大多数公司来说，自动化是成功的关键之一，以至于工程团队常常将 DevOps 和自动化等同起来。 现实问题是随着 DevOps 而来的文化和组织上的变化同样重要，只是自动化有时候是最能量化收益。

自动化为相关各方带来了速度、一致性和效率。 和敏捷开发一样，DevOps 的目标是做得更少、更好、更快。 软件发布更有规律，代码变更更少。 更少的工作意味着更好的专注，每次发布的目的更明确，就能导致更少的错误。 这也意味着在发生错误时更容易回滚。 自动化帮助人们以较少的实际操作完成了工作，但是由于自动化软件每次都做完全相同的事情，所以，一致性是最为明显的一个好处。

首先应用自动化的地方是应用程序构建服务器，自动化的好处在这里最为明显。 构建服务器(例如: Bamboo，Jenkins,) ，通常称为持续集成(CI)服务器，在代码更改时自动构建一个应用程序——甚至可能是整个应用程序堆栈。 一旦构建了应用程序，这些平台还可能启动 QA 和安全测试，将失败的构建反馈给开发团队。 自动化有利于软件生产的其他方面，包括报告、度量、质量保证和发布管理，但是安全测试所带来的好处则是我们在这项研究中所关注的。

从一开始来看，调用安全测试工具代替手动运行测试所带来的好处并不是很多。 这种观点忽略了自动化安全测试的基本好处。 自动化是我们如何确保软件的每次更新都包括安全测试，以确保一致性。 自动化可以帮助我们避免重复的或者完全透明的人工任务中常见的错误和遗漏。 但最重要的是，由于开发人员通常比安全团队多100倍，自动化是扩大安全覆盖范围的关键因素，而无需扩大安全人员的规模。

论一个团队的重要性

一个关键的 DevOps 原则是打破孤岛，在开发人员和支持 QA、 IT、安全和其他团队之间有更好的合作。 我们经常听到这样的想法，这听起来很老套，但事实上在软件开发中很少有人能真正做出改变来实现这个想法。 大多数以 DevOps 为中心的公司正在改变开发团队的组成，以及包括来自所有学科的科代表; 这意味着每个团队都有一个了解一点安全或者是代表安全利益的人，即使是在一个小团队中。 对于那些做到这一点的人来说，他们不仅意识到了更好的沟通所带来的好处，还意识到了目标和激励的真正一致性。 孤立的开发模式可以激励开发人员编写出新的特性。 孤立的质量保证是为了获得各种测试的代码覆盖率。 当团队中的每个人都对新软件的成功发布负责时，优先级和行为的改变就会发生变化。

对于我们采访过的许多公司来说，这个问题依然存在。 我们接触过的大多数公司规模都很大，有数百个开发团队分布在不同的国家，其中一些是第三方(即外部)咨询公司。 所有这些团队都很难保持一致性，更加难以获得普遍参与。 管理结构的建立使开发经理管理开发人员，而不是 IT 人员。 用于特性跟踪、故障排除和资源分配的管理工具是面向孤岛结构的。 许多领先的安全工具被设置为用于分析和向安全专业人员报告缺陷，而不是向解决问题的开发人员或 IT 人员报告。 进度仍然是通过功能输出和代码覆盖率来衡量的，并且相应地发放奖金。

这里的要点是，如果不对支持安全的系统和结构进行一些改变，这种文化变革和由此产生的巨大利益是无法实现的。 这是一个非常艰难的调整，各种各样的管理者都希望实施策略，就好像他们拥有完全的监督权一样，可是他们忽略了一点，那就是他们也需要与他们的同行一起采用‘一个团队'的方法来有效地进行改革。

安全从业人员及应用程序安全

为什么安全人员要与 DevSecOps，甚至是一般的应用程序安全做斗争，因为他们没有软件开发的背景。 大多数安全从业人员来自网络安全背景，我们谈到的许多 CISO 更加注重风险和合规性，因此普遍缺乏对软件开发的理解。 缺乏开发工具和过程的知识，以及开发人员试图克服的常见挑战，就意味着安全团队很少理解为什么自动化构建服务器、中央代码库、容器、敏捷和 DevOps 能在很短的时间内被广泛采用。 在这里，我们将讨论开发实践中的一些变化驱动因素，以及安全团队在尝试处理应用程序安全性时需要理解的关键领域。

· 对过程的认识: 我们在这里不是要教各位开发过程中的细微差别，而是要指出过程变化的原因: 速度。 瀑布法、螺旋法、原型演进法、极限编程、敏捷开发以及Scrum敏捷开发都是在过去20年中形成的过程变体。 每一个都有相同的目标: 减少复杂性(即: 简化需求)和加速软件交付。 当你明白在过去的20年里我们在实现如何构建软件的大多数改变都是为了实现这两个目标时，你就会开始明白这个过程本身并不重要; 更快、更好的交付软件才是最重要的目标。 每日例会、两周一次的软件交付(例如: Sprints)、看板(Kanban)、敏捷、测试驱动开发和自动化构建服务器都是提升技术水平的工具。 因此，对于安全专业人员来说，理解安全测试和策略应该包含这些相同的理念是至关重要的。 最后，DevOps 是独立于过程的; 你可以接受 DevOps，并且仍然保留一个瀑布式的过程，不过 DevOps 更适合敏捷开发。

· 对工具的认识: 软件开发利用许多工具来管理代码和过程。 其中，对安全性最重要的两个是代码存储库和代码构建工具。 像 Git 这样的存储库实质上是管理应用程序代码，为开发人员提供一个共享位置来存储代码、跟踪版本以及变更代码。 其他的，如 Docker Registry，则专门用于容器。 这些工具对于开发人员管理他们正在构建的代码至关重要，但对于安全性也很重要，因为它提供了一个可以检查代码的地方。 构建像 Jenkins 和 Bamboo 这样的服务器来自动化代码的构建、测试和交付。 但是，它们通常用于完整的应用程序堆栈测试，而不是在组件或模块级别。 开发人员和质量保证团队使用构建服务器来启动功能、回归和单元测试; 安全团队还应该利用这些构建服务器来集成安全测试(。 例如: SAST，DAST，成分分析，安全单元测试) ，因此它适用于相同的构建过程，并使用所有相同的管理和通信工具。 对于安全团队来说，了解开发团队使用哪些工具、谁控制这些资源以及安排安全测试的集成非常重要。

· 一切都是代码: 应用程序就是软件。 这是相当容易理解的，但是在许多环境中——特别是公共云环境中——你的服务器、网络、消息、 IAM 和其他基础设施的每一个都可能被定义为配置脚本、模板或应用程序代码。 IT 团队现在使用由几百行脚本组成的模板定义整个数据中心。 安全从业人员的想法是双重的: 安全策略也可以在脚本或代码中定义，并且你可以检查代码的存储库，以确保模板、脚本和代码在运行之前是安全的。 这是对于如何进行安全审计需要做出的根本改变。

· 对开源代码的认识: 开放源码软件在应用程序开发中扮演着重要的角色，在开发社区中得到了广泛的接受，几乎不可能找到一个不利用它的新的应用程序开发项目。 这意味着很大一部分代码可能没有按照你认为的方式进行测试，或者开发人员可能故意使用老的、易受攻击的版本。 为什么？ 因为旧版本与他们的代码可以很好的一起工作。 如果他们更改某个库，可能会破坏应用程序并需要更多的编码工作。 我们鼓励开发人员让代码正常工作，我们也见证了他们为了稳定而努力避免引入新的(例如: 补丁)开源版本。 因此，我们希望你能够明白两点: 你需要在开源代码投入生产之前对其进行测试，并且你需要确保开发人员不会偷偷地将受信任的开源库版本替换为较老的、可能易受攻击的版本。

· 工具选择与开发过程 : 大多数安全团队在将安全性引入应用程序开发时采取的第一步是运行静态分析扫描。 这种做法好的一面是大多数安全从业人员都知道什么是 SAST 以及它是做什么的。 糟糕的是，大多数时候安全性始于老式的 SAST 工具，这些工具很慢，产生的输出只能被安全人员理解，并且会产生误报警报，而且他们没有与构建过程的其余部分完全集成所需的关键 API。 总而言之，他们的努力是对开发人员的敌意，大多数开发团队的反应是忽略扫描或从构建过程中移除工具。 这里有两个关键方面: 你希望选择操作上适合开发模型的工具(更快、更简单、更好) ，并使用实际上能真正有效的工具。 让开发人员自己决定，他们总是选择最容易集成的工具，而不是最有效的安全扫描工具。 但重要的是，安全团队是安全工具选择过程的一部分，以确保安全扫描提供足够的分析。

· 安全摩擦和文化动态: 大多数应用程序安全团队正在追赶潮流。 开发模式(通常)已经变为敏捷开发模式，如果你的一些开发组织支持 DevOps，那么 IT 和 QA 也可能是敏捷模式的。 这意味着安全人员是异常的非敏捷; 你所做的或要求的任何事情都会增加时间和复杂性，这与软件工程的目标正好相反。 这个主题是如此重要，以至于我已经准备在本文的下一节重点阐述“伸缩安全性” ，讨论如何解决安全性和开发之间的文化摩擦。

· SDLC 和 S-SDLC: 许多应用程序安全团队通过观察软件开发生命周期(SDLC)来处理应用程序安全性，目的是在生命周期的每个阶段应用某种形式的安全性分析。 安全 SDLC (S-SDLC)通常包括设计期间的威胁建模、开发期间的成分分析、构建阶段的静态分析以及任意数量的预生产测试。 这是一个设置独立于的过程的应用程序安全性程序的好方法。 正如许多大型组织开始理解的那样，你的每个开发团队都使用一个略有不同的过程，而且你的公司完全有可能使用现有的每一个已知的开发过程。 这是一个非常头疼的问题，但是 S-SDLC 成为了你的标准: 使用 S-SDLC 作为策略模板，然后将安全控制映射到不同过程中的适当位置。

扩展安全性

正如我们在前文中提到的，大多数安全团队在数量上远远超过了安全团队。 例如，本周我与三家中型公司进行了交谈; 开发人员从800人到2000人不等，而安全团队的规模从12人到25人不等。 在安全人员中，他们通常有两个或三个人具有应用程序安全背景。 虽然他们可能像独角兽一样罕见，但这并不意味着他们有神奇的力量覆盖所有的开发操作，所以他们需要学习如何在整个企业中扩展他们的经验。 此外，他们需要以一种与开发理念相融合的方式进行智慧操作，让软件开发团队执行他们设计的安全控制。 以下是几种比较有效的方法。

· 实现自动化安全分析: 我们已经在某种程度上讨论过了自动化，所以我在这里就长话短说。 自动化是帮助安全分析更快、更频繁地执行，而且不需要安全团队的直接操作。 执行自动化分析(开箱即用或自定义检查)的安全工具对于跨多个开发团队的扩展至关重要。 没错，这意味着对于你公司中的任何一个构建管道，你都必须将工具集成到这个管道中，所以这需要时间。 这意味着不仅扫描是自动化的，而且结果的分发是与其他工具和过程集成的。 这就是团队的扩展，也是我们列表中接下来两个项目的工具。

· 让工程构建失败: 开发团队和安全团队之间通常有摩擦。 安全团队通常为开发经理提供带有数千个缺陷的安全扫描结果。 开发经理将其解释为“伙计，你的代码糟透了，你在开发过程中犯了什么错误，现在就修复漏洞! ” 减少两个团队之间摩擦的方法之一是从静态或动态扫描中获取输出，讨论问题的范围，高危缺陷的含义，并就中期修复的合理性达成一致。 一旦每个人都同意什么是高危缺陷，以及在什么时间段内修复漏洞是合理的，你就可以指示安全工具在发现关键错误时使工程构建失败。 虽然这个过程需要一些时间来实现，也需要承受一些痛苦来完成，但这种做法改变了安全性和开发之间关系的性质。 让工程构建失败不再是安全说“代码是有缺陷的”，而是让这种做法成为一个公正的工具，报告开发中的缺陷。 安全不再是阻碍进步的坏家伙，而是开发现在必须满足的一个新的质量标准以及一个关注代码质量的标准，因为这涉及到安全缺陷。 这样的做法还改变了两个团队之间的关系的本质，因为开发人员经常需要帮助来理解缺陷的本质，寻找解决某类缺陷的方法而不是单个缺陷的解决方法，开发人员需要安全团队的帮助。 如果构建失败，那么两个团队之间的关系将发生翻天覆地的变化。 要实现这一点需要一些时间，并且任何产生误报的安全工具都会放大改变的难度，但是这一步对于 DevOps 团队来说是至关重要的。

· 度量标准: 度量对于理解当前应用程序安全问题的范围至关重要，而安全工具是你收集大多数度量标准的方式。 即使你没有让工程构建失败，即使结果没有与任何外部安全共享，集成安全测试到构建服务器和代码存储库是获得可见性和度量的关键。 这些指标将帮助你决定将预算花在哪里，是否需要额外的工具、开发人员教育或运行时保护。 这些度量标准将是你实现工具、教育和运行时保护的有效性的指南。 没有度量标准，你就只是在猜测。

· 安全冠军: 我发现衡量安全性最有效的方法之一是委托自愿的开发人员——那些对安全性有积极兴趣的开发人员——让这个人成为他们开发团队的“安全冠军”。 大多数开发人员其实对安全很感兴趣，他们知道安全教育使他们对公司更有价值，这通常意味着加薪。 出于安全考虑，这意味着你在安全团队中有了一名联络员，你可以向他们提问，如果他们有问题，他们也会主动来找你。 通常情况下，安全团队通过教育来培养这些关系，拥有一个“卓越中心”，在这个虚拟组织中开发人员和安全专家可以提出一些问题(例如：Slack 频道)，将开发人员派去参加安全会议，或者仅仅是像赞助午餐这样的讨论安全主题的活动。 不管你怎么做，这都是一个很好的方法来扩展安全性而不需要扩展安全人数，我们建议你留出一些预算和资源，因为它带来的好处远远大于它的成本。

· 教育培训: 如果你想让开发人员了解安全和应用程序面临的威胁，那么你就需要对他们进行教育培训。 对工程团队的领导和工程团队的副总裁来说，因为人员的费用问题，所以他们通常受到严格的教育预算限制。 为了填补这一空白，安全团队承担培训特定开发人员的费用，教授这些开发人员缺乏的安全技能，这种情况并不少见。 有时是购买与安全有关的 CBT 来实现，有时是购买安全工具供应商提供的专业服务，有时是 SANS 或其他机构提供的特定类别。 了解如何修复应用程序的安全问题、安全参考体系结构、如何执行威胁建模以及如何使用安全工具都是很常见的培训主题。

这个系列文章比大多数其他文章都要长一点。 在过去的几年里，我们进行了大量的研究。 尽管我们试图简明扼要的说出重点，但是为了回答第一部分的问题，我们需要涵盖大量的材料。

接下来，我将讨论如何组合一个安全的 SDLC，以及如何在开发过程中集成安全测试。