共计 27070 个字符，预计需要花费 68 分钟才能阅读完成。
本文译自 Securosis 网站 Adrian Lane 的系列博客文章，内容包含：
- 根本准则
- 平安人员如何与开发协同工作
- 平安测试集成
- 构建平安工具链
- 平安打算
- 平安人员在 DevOps 中的作用
一、根本准则
1.1 导语
DevOps 是一个操作框架，通过自动化来促成软件的一致性和标准化。通过突破不同开发团队之间的阻碍，同时通过优先思考使软件开发更快更容易的事件，该框架帮忙解决了围绕集成、测试、打包和部署的许多噩梦般的开发问题。
DevSecOps 是将平安团队和平安工具间接集成到软件开发生命周期中，利用 DevOps 的自动化和效率，确保每个构建周期都进行应用程序平安测试。这促成了安全性、一致性，并确保安全性与其余质量指标或个性同样重要。自动化的安全性测试，就像自动化的应用程序构建和部署一样，必须与基础设施的其余部分一起组装。
但这就是问题所在。软件开发人员传统上并不反对安全性。这并不是因为他们不关怀平安问题，而是因为他们被激励去关注新个性和性能的交付。DevOps 正在扭转自动化构建过程的优先级，使它们更快、更简略并且更统一。
然而，这并不意味着他们会特意退出平安或平安工具。这是因为平安工具不容易与开发工具和流程很好地集成，咱们常常会发现大量队列沉积，并且以开发为核心的过滤器难以帮忙优先平安工作。更蹩脚的是，平安平台——以及举荐它们的平安业余人员——很难应用，甚至无奈提供 API 反对来提供集成。
另一方面在于平安团队，他们胆怯自动化的软件过程，常常会问“咱们如何管制开发”这样的问题。这一问题的实质既疏忽了 DevSecOps 的精力，也疏忽了开发组织为使每个软件版本更快、更高效和更统一所做的致力。对于平安团队来说，应答软件开发中产生的变动，并扩大他们绝对较小的组织的惟一办法，就是变得和开发团队一样麻利，并且拥抱自动化。
1.2 为什么我要写这篇文章？
咱们通常探讨咱们做钻研背地的动机，以帮忙读者了解咱们的指标和心愿传播的内容。当咱们更新一份钻研报告时，状况就更加简单了，因为它有助于咱们聚焦最近行业的变动，这些变动导致旧的论文在形容最近的趋势方面存在不精确或有余的问题。因为 DevOps 和 DevSecOps 选项在近四年曾经相当成熟，所以，对于这一方面咱们有很多要谈的。
这项工作将是对咱们 2015 年对于将平安构建到 DevOps 中的钻研工作的重大改写，包含围绕平安团队询问的对于 DevSecOps 的常见问题的重大增补，以及对集成工具和办法的彻底更新。
这篇钻研论文的大部分内容将反映的是 2017 年以来财产 2000 强公司的 200 多个平安团队的 400 屡次谈话。因而，咱们将包含泛滥从这些对话中衍生进去的探讨要点。因为 DevOps 曾经存在了很多年，咱们将不过多探讨什么是 DevSecOps 或者它是如何对咱们无益的，更多的是对于如何组合一个 DevSecOps 程序的求实的内容。
当初，让咱们开始扭转！
1.3 不同的焦点，不同的价值
有大量新的考察和钻研论文可用，其中一些是十分好的。还有更多的会议和在线资源涌现进去，资源多到我都数不过去了。例如，Veracode 最近公布了他们的软件平安状态 (SoSS) 报告的最新版本，这份报告是一个大部头读物，带有大量的数据和察看。要害的要点是 DevSecOps 团队应用的灵活性和自动化提供了显著的平安劣势，包含更快的修补周期，更短的缺点持续时间，更快的技术债权缩小，以及更容易的扫描意味着更快的问题辨认。
最近公布的 2019 年软件供应链状态报告显示，团队示意，典范我的项目团队利用 DevOps 准则大大降低了代码部署失败率，补救破绽的工夫只有平均水平的一半。
咱们还有像 DevOps 全天的流动，数以百计的 DevOps 从业者在这里分享对于文化转型、继续集成 / 继续部署 (CI/CD) 技术、SRE 以及 DevSecOps 的故事。
所有这些都很棒，并且提供了一系列定性和定量的数据来阐明为什么 DevOps 可行，以及从业人员是如何演变他们的程序的。
这不是这篇文章的主题。这些资源并没有解决我每周都被问到的问题。
留神，本文是对于如何整合一个全面的 DevSecOps 我的项目。因为咱们总是被问到“我如何把一个 DevSecOps 我的项目组合在一起?”以及“安全性与 DevOps 有什么关系?”。他们不是在寻找正当理由，也不是在寻找对于细微差别的故事来解决具体的阻碍。他们须要一个与同行组织保持一致的平安程序，并拥戴“平安最佳实际”。这些受众绝大多数是平安和 IT 从业者，很大水平上被开发团队所忘记，他们至多承受了麻利概念，如果不是齐全承受 DevOps 的话。面临的挑战是了解开发试图实现什么，以某种形式与这些团队集成，并弄清楚如何利用自动化平安测试，使其至多像开发团队一样麻利。
1.4 DevOps vs DevSecOps
这就引出了另一个有争议的话题，以及为什么这项钻研不同凡响: DevSecOps 这个名字。咱们的论点是，鉴于在这个问题上不足成熟与了解，调用安全性 (“DevSecOps”中的“Sec”) 是必要的。
换句话说，齐全反对 DevOps 这一静止的实践者会通知你，没有理由在 DevOps 中退出 Sec，因为平安只是其中一个因素。DevOps 的现实是突破单个团队之间的隔膜(例如: 架构、开发、IT、平安和 QA)，以更好地促成团队单干，更好地激励每个团队成员朝着雷同的指标后退。
如果安全性只是交融在构建和交付软件的总体工作中的一组技能，那么咱们就没有理由称之为平安保障。
从哲学层面讲，这些支持者是对的。但实际上，咱们还没有到那个境地。兴许开发人员可能承受这个想法 —- 他们其实并不善于促成团队集成。当然，平安是能够自在参加的，但这取决于他们理解在哪里能够集成，并通常要求将他们可能不具备的技能带到团聚上。这是被动攻击型的团队建设！
自动化的安全性测试，就像自动化的应用程序构建和部署一样，须要工夫和技能来构建。在咱们与客户典型的平安会议中，开发人员并不怎么参加。因而一致依然存在，平安团队和通常有几十到几百个扩散的开发团队之间简直没有交换。当开发人员在场时，他们申明平安团队能够创立脚本，将平安测试集成到构建服务器中; 他们能够编写安全策略; 平安能够将平安剖析工具与故障检测以及几行 python 代码的度量联合在一起。
毕竟，许多 IT 从业者正在学习为组态治理编写脚本，并构建模板来定义基础设施部署，那么为什么不提供安全性呢？这齐全疏忽了一个事实，即很少有平安从业人员可能在这个级别编写代码。更蹩脚的是，与咱们交谈的大多数公司的开发人员与平安从业人员的比例约为 100:1，而且基本没有方法在所有开发我的项目中扩大平安资源。
许多平安专家还处在了解 DevOps 的晚期阶段，以及开发人员在过来十年中为了变得更加麻利而采纳的各种办法。平安的确落后于局势，而且仿佛现有的大部分钻研 (上文提到的) 并不是为了解决平安的引入和整合问题。
最初，咱们抉择应用 DevSecOps 名称还有一个十分重要的起因: 代码平安方面的平安工作与基础设施和反对组件的平安工作十分不同。用于验证利用程序代码的安全性查看是平安的 (即: DevSec)，但与应用的工具和过程不同，它们用于验证反对基础架构(即: SecOps) 是平安的。这是两个不同的规程，具备不同的工具和办法，应该作为独自的工作进行探讨。
1.5 常见问题
咱们查看了过来三年所有的电话记录，并记录了咱们被问到的问题。上面的列表是最常见的问题，按问题被问到的频率排序如下。
- 咱们心愿将安全性测试集成到开发管道中，并将从动态剖析开始。咱们该怎么做？
- 咱们如何依据自动化、CI/CD 和 DevOps 构建应用程序安全策略？
- 如何开始构建一个应用程序策略? 我应该遵循什么应用程序平安规范？
- 开发部门每天都在向生产环境公布代码。咱们如何管制开发？咱们真的可能扭转开发人员的行为吗？
- 引入 DevSecOps 的最佳形式是什么？我该从哪里开始呢？最根本的局部是什么？
- 现状有些是瀑布式的，有些是麻利的，有些是 DevOps 的时候，咱们如何让不同的单位采纳同一个流程(不同的团队做事件的形式不同)？
- 咱们 (平安) 应该如何与开发人员一起工作？
- 咱们了解左移，然而这些工具无效吗？你倡议从哪些工具开始呢？
这些问题都有一些独特的线索：它们都来自至多有一些团队 DevOps 实际曾经发展的公司，安全部门对 DevOps 的用意有一些理解，然而平安都是从零开始的。即便曾经在开发管道中内置了平安测试的团队也在为每个工具提供的价值、开发人员对于误报的冲突、如何与开发人员单干或者如何在多个开发团队之间进行扩大以放弃一致性而苦苦挣扎。
咱们发现，在调用和约定期间，平安人员与开发人员承受 DevOps 的起因并不完全一致，并且错过了工作的重点，这就是为什么它们通常不同步的起因。
以下是咱们提出的安全性问题清单，平安团队应该问这些问题，然而没有解决。
- 咱们在文化上和操作上如何适应 DevSecOps？
- 咱们该如何使开发和开发实际具备可见性？
- 咱们如何晓得变动是无效的? 咱们应该收集和监控哪些指标？
- 咱们该如何反对开发部门？
- 咱们须要晓得如何编码吗？
在本文中，咱们将探讨这两个问题列表。接下来，咱们将简要介绍 DevOps 准则和平安在 DevOps 中的作用。
二、平安如何与研发协同工作
思考到 DevOps 对于大多数读者来说是全新的概念，所以在第一节章咱们分享了一个对于根本准则的探讨，以及 DevOps 是如何帮忙解决软件交付中常见的许多问题的。你能够从中找到想要理解的更具体的背景材料。
出于本章的目标，咱们将探讨一些与平安团队集成和应用 DevOps 准则进行平安测试间接相干的准则。这些概念为解决咱们在第一局部中提出的问题奠定了根底，在咱们探讨 DevOps 环境中的平安工具和办法时，读者须要了解这些概念。
2.1 DevOps 与平安
2.1.1 构建安全性
构建安全性，听起来是一个可怕的事实，然而在代码开发过程中宽泛应用应用程序安全性技术，相对来说还是较新的事件。当然，对这个畛域的钻研曾经有几十年的历史了，然而应用程序安全性更多地是通过网络或应用程序防火墙加固的，而不是嵌入到代码自身。
平安产品供应商发现，在应用程序之外了解应用程序申请做平安检测并阻止攻打是十分艰难的。在可能的状况下，修复易受攻击的代码并敞开攻打载体要无效得多。附加工具正在变得越来越好用——有些工作是在应用程序上下文中进行的——然而如果可能的话，最好能在代码中解决这些问题。
构建安全性的一个外围概念是“左移”，或者是咱们在软件开发生命周期 (SDLC) 中更早地集成平安测试的想法——这些阶段依照从左到右的程序通常能够分为设计、开发、测试、预生产和生产。
从实质上讲，咱们将更多的资源从最右端的生产进行左移，将更多的资源投入到设计、测试和开发阶段。这些思维诞生于精益生产，Kaizen 和 Deming 的准则，已被证实是无效的，但通常利用于制作行业。DevOps 曾经在软件开发畛域失去了推广和利用，证实咱们能够通过在研发过程的晚期将缺点平安检测左移来实现以较低的老本进步安全性。
2.1.2 自动化
对于咱们谈到的大多数公司来说，自动化是胜利的要害之一，以至于工程团队经常将 DevOps 和自动化等同起来。事实问题是随着 DevOps 而来的文化和组织上的变动同样重要，只是自动化有时候最能量化收益。
自动化为相干各方带来了速度、一致性和效率。和麻利开发一样，DevOps 的指标是做得更少、更好、更快。软件公布更有法则，代码变更更少。更少的工作意味着更好的专一，每次公布的目标更明确，就能导致更少的谬误。这也意味着在产生谬误时更容易回滚。自动化帮忙人们以较少的实际操作实现了工作，然而因为自动化软件每次都做完全相同的事件，所以，一致性是最为显著的一个益处。
首先利用自动化的中央是应用程序构建服务器，自动化的益处在这里最为显著。构建服务器 (例如: Bamboo，Jenkins,)，通常称为继续集成(CI) 服务器，在代码更改时主动构建一个应用程序——甚至可能是整个应用程序堆栈。一旦构建了应用程序，这些平台还可能启动 QA 和平安测试，将失败的构建反馈给开发团队。自动化有利于软件生产的其余方面，包含报告、度量、质量保证和公布治理，然而平安测试所带来的益处则是咱们在这项钻研中所关注的。
从一开始来看，调用平安测试工具代替手动运行测试所带来的益处并不是很多。这种观点疏忽了自动化平安测试的根本益处。自动化是咱们如何确保软件的每次更新都包含平安测试，以确保一致性。自动化能够帮忙咱们防止反复的或者齐全通明的人工工作中常见的谬误和脱漏。但最重要的是，因为开发人员通常比平安团队多 100 倍，自动化是扩充平安覆盖范围的关键因素，而无需扩充平安人员的规模。
2.1.3 论一个团队的重要性
一个要害的 DevOps 准则是突破孤岛，在开发人员和反对 QA、IT、平安和其余团队之间有更好的单干。咱们常常听到这样的想法，这听起来很老套，但事实上在软件开发中很少有人能真正做出扭转来实现这个想法。大多数以 DevOps 为核心的公司正在扭转开发团队的组成，以及包含来自所有学科的科代表; 这意味着每个团队都有一个理解一点平安或者是代表平安利益的人，即便是在一个小团队中。
对于那些做到这一点的人来说，他们不仅意识到了更好的沟通所带来的益处，还意识到了指标和激励的真正一致性。孤立的开发模式能够激励开发人员编写出新的个性。孤立的质量保证是为了取得各种测试的代码覆盖率。当团队中的每个人都对新软件的胜利公布负责时，优先级和行为的扭转就会发生变化。
对于咱们采访过的许多公司来说，这个问题仍然存在。咱们接触过的大多数公司规模都很大，有数百个开发团队散布在不同的国家，其中一些是第三方 (即内部) 征询公司。所有这些团队都很难放弃一致性，更加难以获得广泛参加。
治理构造的建设使开发经理治理开发人员，而不是 IT 运维人员。用于个性跟踪、故障排除和资源分配的管理工具是面向孤岛构造的。许多当先的平安工具被设置为用于剖析和向平安业余人员报告缺点，而不是向解决问题的开发人员或 IT 人员报告。进度依然是通过性能输入和代码覆盖率来掂量的，并且相应地发放奖金。
这里的要点是，如果不对反对平安的零碎和构造进行一些扭转，这种文化改革和由此产生的微小利益是无奈实现的。这是一个十分艰巨的调整，各种各样的管理者都心愿施行策略，就如同他们领有齐全的监督权一样，可是他们疏忽了一点，那就是他们也须要与他们的同行一起采纳‘一个团队 ’ 的办法来无效地进行改革。
2.1.4 平安从业人员及应用程序平安
为什么平安人员要与 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 作为策略模板，而后将安全控制映射到不同过程中的适当地位。
2.1.5 扩大安全性
正如咱们在前文中提到的，大多数开发团队在数量上远远超过了平安团队。例如，本周我与三家中型公司进行了交谈; 开发人员从 800 人到 2000 人不等，而平安团队的规模从 12 人到 25 人不等。
在平安人员中，他们通常有两个或三个人具备应用程序平安背景。尽管他们可能像独角兽一样常见，但这并不意味着他们有神奇的力量笼罩所有的开发操作，所以他们须要学习如何在整个企业中扩大他们的教训。此外，他们须要以一种与开发理念相交融的形式进行智慧操作，让软件开发团队执行他们设计的安全控制。
以下是几种比拟无效的办法。
- 实现自动化平安剖析
咱们曾经在某种程度上探讨过了自动化，所以我在这里就长话短说。自动化是帮忙平安剖析更快、更频繁地执行，而且不须要平安团队的间接操作。执行自动化剖析 (开箱即用或自定义查看) 的平安工具对于跨多个开发团队的扩大至关重要。
没错，这意味着对于你公司中的任何一个构建管道，你都必须将工具集成到这个管道中，所以这须要工夫。这意味着不仅扫描是自动化的，而且后果的散发是与其余工具和过程集成的。这就是团队的扩大，也是咱们列表中接下来两个我的项目的工具。
- 让工程构建失败
开发团队和平安团队之间通常有摩擦。平安团队通常为开发经理提供带有数千个缺点的平安扫描后果。开发经理将其解释为“伙计，你的代码糟透了，你在开发过程中犯了什么谬误，当初就修复破绽!”缩小两个团队之间摩擦的办法之一是从动态或动静扫描中获取输入，探讨问题的范畴，高危缺点的含意，并就中期修复的合理性达成统一。一旦每个人都批准什么是高危缺点，以及在什么时间段内修复破绽是正当的，你就能够批示平安工具在发现要害谬误时使工程构建失败。尽管这个过程须要一些工夫来实现，也须要接受一些苦楚来实现，但这种做法扭转了安全性和开发之间关系的性质。
让工程构建失败不再是平安说“代码是有缺点的”，而是让这种做法成为一个公正的工具，报告开发中的缺点。平安不再是妨碍提高的坏家伙，而是开发当初必须满足的一个新的质量标准以及一个关注代码品质的规范，因为这波及到平安缺点。这样的做法还扭转了两个团队之间的关系的实质，因为开发人员常常须要帮忙来了解缺点的实质，寻找解决某类缺点的办法而不是单个缺点的解决办法，开发人员须要平安团队的帮忙。如果构建失败，那么两个团队之间的关系将产生天翻地覆的变动。要实现这一点须要一些工夫，并且任何产生误报的平安工具都会放大扭转的难度，然而这一步对于 DevOps 团队来说是至关重要的。
- 度量规范
度量对于了解以后应用程序平安问题的范畴至关重要，而平安工具是你收集大多数度量规范的形式。即便你没有让工程构建失败，即便后果没有与任何内部平安共享，集成平安测试到构建服务器和代码存储库是取得可见性和度量的要害。这些指标将帮忙你决定将估算花在哪里，是否须要额定的工具、开发人员教育或运行时爱护。这些度量规范将是你实现工具、教育和运行时爱护的有效性的指南。没有度量规范，你就只是在猜想。
- 平安冠军
我发现掂量安全性最无效的办法之一是委托被迫的开发人员——那些对安全性有踊跃趣味的开发人员——让这个人成为他们开发团队的“平安冠军”。大多数开发人员其实对平安很感兴趣，他们晓得平安教育使他们对公司更有价值，这通常意味着加薪。出于平安思考，这意味着你在平安团队中有了一名联络员，你能够向他们发问，如果他们有问题，他们也会被动来找你。
通常状况下，平安团队通过教育来造就这些关系，领有一个“卓越核心”，在这个虚构组织中开发人员和平安专家能够提出一些问题(例如：Slack 频道)，将开发人员派去加入平安会议，或者仅仅是像资助午餐这样的探讨平安主题的流动。不论你怎么做，这都是一个很好的办法来扩大安全性而不须要扩大平安人数，咱们倡议你留出一些估算和资源，因为它带来的益处远远大于它的老本。
- 教育培训
如果你想让开发人员理解平安和应用程序面临的威逼，那么你就须要对他们进行教育培训。对工程团队的领导和工程团队的副总裁来说，因为人员的费用问题，所以他们通常受到严格的教育估算限度。
为了填补这一空白，平安团队承当培训特定开发人员的费用，传授这些开发人员不足的平安技能，这种状况并不少见。有时是购买与平安无关的 CBT 来实现，有时是购买平安工具供应商提供的业余服务，有时是 SANS 或其余机构提供的特定类别。理解如何修复应用程序的平安问题、平安参考体系结构、如何执行威逼建模以及如何应用平安工具都是很常见的培训主题。
这个系列文章比大多数其余文章都要长一点。在过来的几年里，咱们进行了大量的钻研。只管咱们试图简明扼要的说出重点，然而为了答复第一局部的问题，咱们须要涵盖大量的资料。
接下来，我将探讨如何组合一个平安的 SDLC，以及如何在开发过程中集成平安测试。
三、平安测试集成
在本章中，咱们将向你展现如何在你的 DevOps 自动化框架中集成安全性。咱们将要解决的问题是“咱们心愿将平安测试集成到开发管道中，并将从动态剖析开始。咱们该怎么做?”、“咱们了解“左移”，但这些工具无效吗?”以及“你倡议咱们从哪些工具开始，以及如何集成这些工具?。
因为 DevOps 激励在开发和部署的所有阶段进行测试，咱们将探讨构建的管道会是什么样，以及适宜不同阶段的工具。平安测试通常与质量保证团队可能曾经部署的功能测试和回归测试并列。除了这些典型的在构建之后的测试点之外，你还能够在构建之前在开发人员的桌面上进行测试，在构建之前和之后的代码库中进行测试，以及在预部署阶段进行测试。
3.1 构建过程
在咱们接到的几个电话中，有几个高级平安主管不晓得构建过程的组成。这并不是一种谴责，因为许多平安人员并没有参加软件生产和交付，所以咱们想粗略的论述一下开发人员应用的过程和术语。如果你对此曾经很相熟，那么请跳到“构建平安工具链”。
大多数读到本章的人都会相熟“夜间构建”，在这种模式中前一天查看的所有代码都是在夜间编译的。当你习惯性的查看日志，看看构建是否失败以及为什么失败的时候就像你也同样相熟晚上要喝咖啡的习惯。大多数开发团队曾经这样做了十年或更长时间。自动化构建是公司通向反对代码开发的流程的齐全自动化路线上许多步骤中的第一步。在过来的几年里，咱们曾经把咱们的“脚踩在地板上”，利用越来越多的自动化来放慢软件交付的步调。
通往 DevOps 的门路通常分为两个阶段: 首先是继续集成，它治理代码的构建和测试；而后是继续部署，它将整个应用程序堆栈组装成一个可执行的环境。与此同时，这个过程的所有阶段都在一直地改良，使其更容易、更快、更牢靠。要达到这个指标须要大量的工作，应用的脚本和模板通常须要几个月的工夫来构建根底，而将它们变得成熟最终成为牢靠的软件交付基础设施则须要几年的工夫。
3.2 继续集成
继续集成 (CI) 的实质是帮忙开发人员定期检查小迭代代码的停顿。对于大多数团队来说，这须要对一个共享的源代码储存库或服务器进行屡次更新，每天还要进行一次或屡次构建。在这里的要害是，通过更小、更简略的附加性能，咱们就能够更容易、更快地发现代码缺点。这些实质上是麻利概念，在驱动代码的过程中实现，而不是在驱动人的过程中实现(比方 Scrums 和 Sprints)。
继续集成的定义在过来的十年里曾经产生了变动，然而在 DevOps 的环境下，继续集成意味着代码不仅是应用反对的库构建和集成，而且是通过主动散发进行测试的。此外，DevOps CI 意味着代码变更并不利用于分支，而是间接利用于代码的主体，缩小了可能困扰开发团队的复杂性和集成噩梦。
这听起来很简略，但实际上须要大量的基础设施反对工作。构建必须齐全脚本化，并且构建过程在代码变更时产生。每次构建胜利后，应用程序堆栈都会被打包并传递给测试用户。测试代码在单元测试、功能测试、回归测试和平安测试之前构建，并成为存储库和自动化过程的一部分。
每当新的测试可用时，测试工作就会主动开始，但这也意味着每个新的构建都会利用新的测试。这还意味着，在测试工作能够启动之前，必须主动设置、配置测试零碎，并为其输出必要的数据。自动化脚本必须为流程的每个局部提供监控能力，并在事件产生时将胜利或失败的信息反馈给开发和运维团队。要创立脚本和工具来实现这所有，须要运维、测试和开发团队严密单干。
下图显示了容器的主动构建管道，包含平安测试点。再次强调，这种档次的编排不是欲速不达的，而是一个须要数月建设根底、数年能力成熟的渐进过程。但这正是继续改良的实质所在。
3.3 继续部署
继续部署看起来十分相似于 CI，然而侧重于向终端用户公布软件，而不是构建软件。它蕴含了一些相似于包装、测试和监控的工作，但有一些额定的不同。在胜利实现构建周期之后，后果将提供给继续部署 (Continuous Deployment，CD) 流程。CD 在自动化和弹性方面又向前迈出了一大步，同时自动化了应用程序堆栈的公布治理、设置和最终配置，而后启动新的利用程序代码。
当咱们议论 CD 的时候，人们有两种形式来承受这个概念。有些团队只是将新版本的应用程序启动到现有的生产环境中。CD 过程让应用层实现了自动化，但不能让服务器、数据或网络层实现自动化。咱们发现这在本地应用程序和公有云部署中很常见，一些私有云部署也依然应用这种模型。
与咱们交谈过的平安团队中有很大一部分是真正胆怯继续部署的。他们说“你怎么可能容许代码在没有检查和监督的状况下运行!”，他们疏忽了一点，即代码在所有平安测试通过之前不会启动。一些 CI 管道蕴含一些测试的手动检查点。依据咱们的教训，CD 意味着更牢靠和更平安的版本。CD 解决了困扰代码部署的几十个问题，特地是在容易出错的手工变更以及生产和开发之间反对库的订正方面。一旦进行了充沛的测试，就没有理由不信赖 CD。
并不是所有的公司每天都会在公布产品的过程中公布代码；事实上，只有不到 10% 的公司会继续公布产品代码，然而一些驰名的公司，如 Netflix，Google 和 Etsy，一旦测试实现，就会主动公布产品代码。然而大多数公司 (例如: 那些不在内容或批发垂直畛域的公司) 没有一个好的业务须要每天公布屡次更新，所以他们不须要公布代码。
3.3.1 治理和蓝绿部署
大多数公司都有一个较慢的公布周期，通常每一到三个 sprint 就会有一个“上线”的节奏。咱们称这些为“托管公布”，因为执行和计时是手动操作的，不过大多数操作是主动的。此外，这些公司还采纳了另一种十分弱小的技术：自动化基础设施部署。
在这一阶段，你能够循环整个根底构造堆栈与应用程序。这些类型的部署依赖于软件运行环境的自动化；这能够很简略的实现，比方反对一个 Kubernetes 集群，或者利用 Openshift 在 Google GCP 中运行 Terraform 模板，或者通过 Cloudformation 模板启动一个残缺的 AWS 环境。基础设施和应用程序都是代码，因而两者都是同时启动的。这在私有云部署中正变得越来越广泛。
这种公布办法提供了显著的劣势，并为所谓的“蓝 - 绿”或“红 - 黑”部署提供了根底。新旧代码并排运行，近似于镜像，各自在本人的一组服务器上运行。旧的代码 (即: 蓝色) 持续服务于用户申请，而新的代码 (即: 绿色) 只由选定的用户或测试工具执行。部署是负载平衡级别上的一个简略的重定向，外部用户和流动客户能够缓缓地重定向到绿色服务器，实质上是将这些用户作为新零碎的测试人员。
如果新代码通过了所有须要的测试，负载均衡器将所有流量发送到绿色服务器，蓝色服务器就会下线，而后绿色服务器成为了新的蓝色服务器。如果发现错误，负载均衡器会被指向原来的“蓝色”代码，直到有新的修补程序可用。这基本上是生产中的预公布测试，即便发现了缺点或平安问题，也能够立刻进行回滚。
3.4 平安测试阶段
3.4.1 桌面平安测试
集成开发环境 (Integrated Development environment，IDE) 是大多数开发人员的规范。Visual Studio，Eclipse，IntelliJ 等等，一些是针对特定的语言或环境定制的。这些桌面工具不仅有助于构建代码，而且它们集成了语法查看器、运行时、终端、包和许多其余性能，使构建代码更加容易。
商业安全性供应商为风行工具提供插件，通常提供一种动态剖析模式。有时这些工具是交互式的，在编写代码时提供倡议，而其余工具在提交代码之前依据须要查看以后批改的文件。甚至有一两个工具实际上并不是作为 IDE 的插件，而是作为一个独立的工具工作，并在代码提交到仓库之前运行。因为代码扫描通常只是开发人员正在解决的模块或容器，因而代码扫描的速度十分快。在这个阶段正确地进行平安扫描能够升高构建服务器在代码提交后发现平安问题并失败的可能性。
咱们与应用这些工具的开发团队单干，他们发现这些工具是无效的，并且可能依照承诺交付。与咱们交谈的许多开发人员并不喜爱这些平安插件，因为他们感觉这些插件乐音大、让人分心。咱们倡议尽可能应用这些桌面扫描器，但要意识到应用时的文化阻碍，并揭示平安团队可能须要帮忙扭转文化，并容许随着工夫的推移逐步采纳。
3.4.2 代码库扫描
源代码治理、配置管理数据库、容器注册核心和相似于这些类型的工具存储代码，并帮忙治理工作，如版本控制，IAM 和审批流程。从平安的角度来看，一些成分剖析供应商曾经集成了他们的产品，以查看开源版本控制是否正确，以及应用的平台是否蕴含已知的 CVE。为已知的好版本和其余版本控制个性创立数字指纹的附加设施正变得越来越广泛。
3.5 构建服务器集成
构建服务器构建应用程序。通常由外部开发的多个源代码和凋谢源代码组成，在构建应用程序时应用许多“工件”是很常见的。侥幸的是，像 Jenkins 和 Bamboo 这样的构建服务器在建设之前和之后都有解决这些工件所需的钩子。这通常是测试集成到构建管道中的形式。利用此性能将是平安测试集成的外围。在这个阶段通常集成了成分剖析、SAST 和自定义测试。
3.6 预公布
对于“代码实现”或零碎测试，将应用程序的所有局部和反对的应用程序堆栈组装在一起，设置一个预生产“筹备区域”来模仿生产环境，并促成残缺的测试。咱们发现了几个最近的趋势，预生产测试就是其中之一。因为私有云资源容许疾速弹性和随需应变的资源洽购，公司正在开发测试环境，运行 QA 和平安测试，而后再次敞开它们以降低成本。这用于执行以前在生产中执行的 DAST 测试。在大多数状况下，在大多数状况下，这是利用蓝绿部署模型在与现有的生产环境并行的新环境上运行许多不同类型测试的办法。
四、构建平安工具链
4.1 动态剖析
动态应用程序平安测试 (SAST) 查看所有代码或运行时二进制文件，以反对对常见破绽的彻底搜寻。这些工具在发现缺点方面十分无效，即便是曾经通过人工审计后的代码也是如此。你的抉择规范可能归结为扫描的速度，易于集成，后果的可读性和较少的误报。
这些平台中的大多数曾经在提供对开发人员有用的剖析后果方面做得很不错了，而不仅仅是平安极客。许多产品正在降级，通过 API 或构建脚本提供残缺的性能。如果能够抉择，能够抉择带有 API 的工具集成到 DevOps 流程中，这些工具不须要“代码实现”。
咱们曾经看到这些测试的应用略有缩小，因为它们通常须要几个小时或几天能力运行——在 DevOps 环境中能够避免它们作为认证或部署的通道而内联运行。正如咱们在下面的“其余”局部所提到的，大多数团队正在调整以反对带外 (或者咱们称之为“并行化”) 的动态分析测试。如果可能的话，咱们强烈建议尽可能内联 SAST 测试，并且关注新增的代码局部以缩小运行工夫。
4.2 动态分析
动静应用程序平安测试 (Dynamic Application Security Testing，DAST) 不是扫描代码或二进制程序(如 SAST)，而是动静地“匍匐”应用程序的接口，测试它对各种输出的反馈。这些扫描器不能看到幕后产生了什么，然而它们提供了对代码行为的有价值的洞察力，并且能够革除其余测试在动静代码门路中可能看不到的谬误。好消息是它们的误报率很低。
这些测试通常是针对齐全构建的利用程序运行的，并且具备破坏性，因而这些工具为了可能在测试环境中更踊跃地运行，通常须要提供一些设置。就像 SAST 可能须要一些工夫来齐全扫描代码，因而在测试中，一个版本通常只针对新代码运行，而整个应用程序扫描是“并行”运行的。
4.3 成分和脆弱性剖析
成分剖析工具查看凋谢源码库的版本，以评估开放源码的危险，包含安全漏洞和潜在的许可问题。像 Heartbleed、配置谬误的数据库和 Struts 破绽可能基本不是应用程序测试的一部分，但它们都是要害的应用程序栈破绽。有些人将破绽测试等同于 DAST，然而还有其余办法来辨认破绽。
事实上，破绽扫描有几种类型; 一些看起来像平台配置、补丁级别或应用程序组合等设置来检测已知的破绽。确保扩充扫描范畴，以包含应用程序、应用程序堆栈和反对它的开源平台。
4.4 人工代码审计
一些组织发现齐全实现自动化部署有点吓人，因而他们心愿在新代码上线之前有人来审计变更——咱们了解这一点。但也有很好的平安理由进行审计。在一个像 DevOps 这样以自动化为核心的环境中，应用或认可人工代码审计或安全检查可能看起来是与之绝对立的，然而人工代码审计依然是十分可取的。某些类型的破绽不是扫描工具能够辨认的。
人工代码审计常常捕捉到测试脱漏的显著内容，而开发人员在第一次 (惟一一次) 通过时可能会脱漏。开发人员编写平安单元测试的能力各不相同。无论是因为开发人员的谬误还是审计人员的技能，编写测试用例的人员都可能会脱漏人工审计所捕捉的内容。你的工具应该包含人工代码审计——至多对新代码进行定期抽查，或者像 Dockerfile 之类的扫描中常常省略的货色。
4.5 运行时爱护
许多公司仍在利用 Web 应用程序防火墙，但 Web 防火墙的应用正在降落。咱们看到越来越多地公司在生产环境中应用运行时应用程序自我爱护来增强日志记录和爱护工作。这些平台提供工具代码，提供运行时爱护，并在某些状况下辨认应用程序里了哪些代码行是易受攻击的。
DevOps 要求你进行更好的监控，以便收集指标，从而能够依据操作数据进行调整。为了验证新的应用程序部署是否失常运行，通常内置监督和检测。在某些状况下，这些是应用自定义包和 ELK 堆栈实现的，在另一些状况下，则只需在生产环境中关上日志记录和“调试”格调的语句(通常在开发阶段应用)。这在私有云 IaaS 中更为突出，在本地日志不能提供充沛可见性的状况下，你齐全负责数据和应用程序平安。
4.6 平安单元测试
单元测试是查看应用程序中较小的子组件或片段(“单元”)。这些测试由程序员在开发新性能时编写，通常由开发人员在代码提交到仓库之前运行，但也可能在构建管道中运行。这些测试应该是长期的，与新代码一起存入代码存储库，并由每个后续的开发人员运行，这些开发人员为代码模块做出了奉献。
对于安全性来说，这些攻打可能很简略(比方针对 web 表单的 SQL 注入)，也可能是针对被测性能的更简单的攻打(比方业务逻辑攻打)，所有这些都是为了确保每一段新代码都能正确反映开发人员的用意。每个单元测试都侧重于特定的代码片段，而不是零碎或事务。
单元测试试图在过程的晚期捕获谬误，依照 Deming 的说法，越早辨认出缺点，修复它们的老本就越低。在构建单元测试时，你将须要反对开发人员和基础设施来体现你的测试，并且还要激励团队足够认真地看待测试以构建良好的测试。让多个团队成员编写雷同的代码并编写单元测试，有助于辨认出单个程序员可能没有思考到的弱点。
4.7 平安回归测试
回归测试验证最近更改的代码是否依然按预期的形式运行。在平安方面，这对于确保破绽失去修复尤为重要。DevOps 回归测试通常与功能测试并行运行ーー在构建了代码堆栈之后。
在某些状况下，这可能须要在一个专用的环境中进行，在这种环境中，平安测试可能具备破坏性，并在具备实在客户数据的生产服务器上产生一些不可承受的副作用。利用虚拟化和云基础设施能够放慢新测试环境的实例化。
测试工作自身通常就是通过本人构建的测试用例利用以前发现的破绽，无论是作为单元测试还是零碎测试都是如此。测试用例的编写人员应用这类测试来确保像明码和证书这样的凭据不蕴含在文件中，并且基础架构不容许拜访端口 22 或 3389。
4.8 混沌工程
混沌工程通常在生产环境中引入随机故障，以理解应用程序环境如何解决不利条件。像 Netflix 这样的公司曾经率先在这个畛域做出致力，以迫使他们的开发团队了解常见的故障类型，并在他们的代码中构建优雅的故障和复原。
从安全性的角度来看，如果攻击者能够强制应用程序进入坏的状态，那么他们通常能够强制应用程序执行不打算执行的工作。将坚硬性构建到代码中能够进步可靠性和安全性。
4.9 含糊测试
最简略的含糊测试本质上是向应用程序抛弃大量随机的垃圾，看看是否有任何特定 (类型) 的垃圾会导致谬误。许多动静扫描供应商会通知你他们提供了含糊测试。实际上并非这样。
去加入任何平安会议，比方 Black Hat、DefCon、RSA 或 B-Sides 后你都会发现，大多数平安钻研人员更喜爱通过含糊测试查找易受攻击的代码。这种形式已成为辨认可能被攻击者利用的存在缺点的代码的要害。
在过来的 10 年里，随着麻利开发过程，甚至是 DevOps 的呈现，开发团队和 QA 团队对含糊测试的应用逐步缩小。这是因为它很慢; 执行一个大型歹意输出测试工作运行须要大量的工夫。
这对于 web 应用程序来说不是什么大问题，因为攻击者不可能把所有货色都扔进代码里，然而对于交付给用户的应用程序 (包含挪动应用程序、桌面应用程序和汽车零碎) 来说，问题就很大。咱们简直排除了这一部分，因为在应用中很少看到真正的含糊测试，然而对于要害零碎，定期和带外含糊测试应该是你的平安测试工作的一部分。
4.10 危险及裸露剖析
将来自应用程序扫描中发现的平安问题集成到 bug 跟踪零碎中，在技术实现上并不艰难。大多数产品都将其作为一个内置的个性提供。艰难的局部是弄清楚一旦取得数据后该如何解决。被发现的安全漏洞真的是一个问题吗？如果不是误报，是否能够利用破绽？绝对于其余所有，它的临界性和优先性是什么？如果咱们抉择解决这个破绽，咱们又该如何从一系列选项(单元测试，补丁，RASP) 中抉择一种形式来进行解决？
另一个须要思考的方面是，这种信息的散布不会使利益相关者超负荷。应用 DevOps，你须要敞开基础设施、平安测试以及代码等问题的循环。Dev 和 Ops 为大多数破绽提供了不同的可能无效的解决方案，因而治理平安的人员外面也须要包含经营团队。修补、代码变更、阻断和功能性白名单都是敞开安全漏洞的选项; 所以你须要 Dev 和 Ops 来权衡利弊。
五、平安打算
本章旨在帮忙平安人员为应用程序平安程序创立一个纲要或构造。咱们将答复一些常见的问题，比方“咱们如何开始构建应用程序安全策略?”“我如何开始合并 DevSecOps?”及”我应该恪守什么样的应用程式平安规范?”我将探讨软件开发生命周期(SDLC)，介绍在施行打算时须要思考的平安事项，并参考一些应用程式平安规范，作为应采取哪些安全措施的指引。本章将帮忙你制订策略; 下一章将介绍战术工具的抉择。
5.1 平安打算和你的 SDLC
平安软件开发生命周期 (S-SDLC) 实质上形容了平安该如何适应软件开发生命周期的不同阶段。咱们将钻研 SDLC 中的每个阶段，并探讨哪些平安工具和技术是适当的。
请留神，S-SDLC 通常是作为一个瀑布开发过程描述的，具备线性过程中的不同阶段，但这实际上只是为了更清晰地形容——理论的 SDLC 可能是麻利的、极限的，或者像瀑布一样的螺旋式的。有充沛的理由将 S-SDLC 基于更古代的 SDLC 之上; 然而架构、设计、开发、测试和部署阶段都能够很好地映射到任何开发过程中的开发阶段。它们提供了一个很好的终点，能够将以后的模型和流程适应到 DevOps 框架中。
在咱们之前的文章中，咱们心愿你将 S-SDLC 看作是构建你的平安程序的框架，而不是一个残缺的循序渐进的过程。咱们意识到这与课堂教学和维基教学有所不同，然而对于每个阶段的平安打算来说更好一些。
5.2 定义和架构
- 参考平安体系架构
参考平安体系架构实用于不同类型的应用程序和服务，包含 web 应用程序、数据处理应用程序、应用程序的身份和拜访治理服务、流或事件处理、消息传递等。架构在公共云环境、Kubernetes 集群和服务网格环境中甚至更无效——在这些环境中，咱们能够通过策略严格控制每个应用程序的操作和通信形式。
对于云服务，咱们倡议你利用服务提供商对于部署平安的指导方针，只管他们可能不会称之为“参考平安体系架构”，但他们的确提供了这些指导方针。理解应用程序平台，并询问软件设计师和架构师他们应用了哪些办法。如果对于传统的应用程序，如果他们给你一个茫然的眼神，不要感到诧异。然而新的应用程序应该包含流程隔离、拆散和数据安全打算，以及残缺的 IAM 模型，以促成职责拆散和数据访问控制。
- 操作规范
与你的开发团队一起定义最小的平安测试需要，以及要害的和高优先级的问题。你将须要协商哪些平安缺点将导致构建失败，并提前定义流程。你可能须要就修复问题的工夫框架达成统一，并须要某种类型的虚构补丁来解决难以修复的应用程序平安问题。你须要事后定义这些事件，并确保你的开发人员和 IT 合作伙伴批准这些事件。
- 平安需要
就像在代码验收之前必须运行的最小功能测试一样，你将在部署之前运行一组平安测试。这些可能是针对你的团队所写的具体威逼而约定的一系列单元测试。或者你可能要求所有 OWASP 十大破绽在代码或反对产品中失去缓解，将每个威逼映射到所有 web 应用程序的特定安全控制。
不论你抉择什么，你的基准需要应该既思考到旧的性能，也思考到新的性能。越来越多的测试须要更多的资源进行验证，并且随着工夫的推移可能会减慢测试和部署周期，因而你能够决定哪些测试能够阻止公布，哪些测试能够扫描以便进行前期生产。
- 监控和度量
如果你将在每个版本中进行小的迭代改良，那么须要修复什么？哪些代码模块对平安有问题？什么是无效的，你如何证实它？度量规范是答复所有这些问题的要害。
你须要思考须要收集哪些数据，并将其构建到 CI:CD 和生产环境中，以度量脚本和测试的执行状况。这意味着你须要让开发人员和 IT 人员参加收集数据。你将不断改进度量规范的收集和应用，然而从一开始就要对数据的根本收集和流传进行布局。
5.3 设计
- 平安设计准则
一些应用程序的平安设计和操作准则提供了重大的平安改良。例如用于帮忙修补和缩小攻击者持久性的长期实例、用于移除攻打外表的不可变服务、用于确保服务器和应用程序正确设置的配置管理、用于配置统一的云环境部署的模板、自动化修复、通过锁定开发人员和 QA 人员而将职责拆散出生产资源等等。
同样重要的是，这些办法是 DevOps 的要害，因为它们使软件的交付和治理变得更快更容易。这听起来仿佛有很多须要解决的问题，但 IT 和开发人员也投入其中，因为这也使他们的生存变得更加容易。
- 确保部署管道的平安
随着开发和生产环境更加固定，开发和测试服务器成为更具吸引力的指标。传统上，这些运行环境的安全性很低或基本没有安全性可谈。然而，对平安源代码治理、构建服务器和部署管道的需要正在增长。因为 CI/CD 管道提供了进入生产的自动化门路，你至多须要对这些零碎进行更严格的访问控制——特地是构建服务器和代码库。
而且，如果脚本在后盾间断运行，并且人工监督很少，那么你将须要额定的监督来捕获谬误和不当应用。许多工具提供了良好的安全性，具备数字指纹、2FA、日志、以角色为根底的访问控制和其余平安个性。当部署在云环境中时，治理台容许管制整个环境，必须十分小心地进行访问控制和职责拆散。
- 威逼建模
威逼建模依然是最有功效的平安实际之一。尽管 DevOps 没有扭转这一点，但它的确为平安团队成员提供了机会，能够领导开发团队成员解决常见的威逼类型，并帮忙打算单元测试来应答攻打。
这个时候你须要决定是否在公司外部造就这个人才，还是延聘一个参谋，因为没有哪个产品能够为你做到这一点。威逼建模通常在设计阶段执行，但也能够在开发较小的代码单元时执行，有时也能够通过自建单元测试执行。
5.4 开发
- 基础架构和自动化优先
自动化和继续改良是要害的 DevOps 准则，对于平安也同样重要。正如后面的文章所探讨的，自动化是必不可少的，因而你须要抉择和部署平安工具。咱们强调这一点是因为打算很重要，有助于开发人员在交付新代码之前打算出他们须要部署的工具和测试工作。
请记住，许多平安工具须要集成一些开发技能，因而要么打算让你的员工提供帮忙，要么参加业余服务。坏消息是，在筹备过程中须要事后领取费用和实现工作; 好消息是，将来的每一个构建都将从这些致力中受害。
- 自动化优先
请记住，开发并不是编写代码和构建脚本的惟一团队——当初操作也是如此。这就是 DevOps 如何将修复和加固带到一个新的程度。运维的 DevOps 角色是提供构建脚本，用于构建开发、测试和生产服务器的基础设施。
好消息是，你当初正在测试的是生产环境的准确正本。模板和配置管理解决了传统 IT 多年来始终致力解决的一个问题: 临时性的无文档的工作“调整”环境使得环境可能失常工作。
同样，要使环境齐全自动化须要做大量的工作——在服务器、网络配置、应用程序等等下面——然而它使将来的工作更快、更统一。咱们采访的大多数团队每周都会构建新的机器镜像，并更新他们的脚本以利用补丁、更新配置和构建脚本以适应不同的环境。这项工作确保了一致性和平安的基线。
- 平安代码存储库
你心愿为开发人员提供一种简便的办法来取得平安的和 (外部) 批准的凋谢源码库。咱们的许多客户都保留了通过批准的库的本地正本，使得拜访这些资源变得很容易。而后，在将代码部署到生产环境之前，他们应用成分剖析工具和脚本的组合，以确保开发人员应用的是通过批准的版本。这有助于缩小易受攻击的开放源码的应用。
- Scrum 中的安全性
如前一章节所述，DevOps 是与流程无关的。你能够依据本人的爱好应用螺旋式，麻利，或手术团队的办法。然而麻利 Scrum 和看板技术非常适合 DevOps。他们专一于较小的、重点突出的、疾速可证实的工作上，这很好地实现了协调一致。咱们倡议在这个时候设置你的“平安冠军”程序，在每个团队中至多培训一个人学习平安基础知识，并确定哪个团队成员对平安主题感兴趣。通过这种形式，平安工作能够很容易地调配给那些有趣味并且有肯定的技能解决这些工作的团队成员。
- 测试驱动开发
继续集成的一个外围准则是永远不要将有谬误或未经测试的代码提交到代码库中。谬误和未经测试的定义取决于你。与编写微小的瀑布式标准文档以进步代码品质或安全性不同，你正在用函数脚本和程序编写策略文档。单元测试和功能测试不仅定义而且加强平安需要。
许多开发团队应用所谓的“测试驱动开发”，其中的测试确保所需的性能——并防止不须要的后果——与代码一起构建。这些测试用例被存入代码库，并成为应用程序测试套件的永恒局部。平安团队没有充分利用这种类型的测试，然而这是检测特定于代码的平安问题的一个极好办法，而商业工具却没有这样做。
5.5 测试
- 为失败而设计
DevOps 颠覆了 IT 和软件开发中许多长期保持的准则。例如，耐久性过来意味着“失常运行工夫”，但当初是更换的速度。带有具体产品规格的大型文档曾经被便当贴所取代。对于安全性来说，已经专一于让代码通过性能需要的团队当初正在寻找赶在其他人之前毁坏应用程序的办法。这种“混沌工程”的新办法无意毁坏了应用程序的部署，迫使工程师在可靠性和安全性方面进行构建。
詹姆斯 · 维克特的《哥特列特》中有一句话: 对你的代码要厚道——就像它雄辩地表白了你的思维一样。咱们的指标不仅仅是在主动交付过程中测试性能，而且是要真正测试代码的坚硬性，并大幅度的进步可承受发行版的最低安全性。
咱们通过在应用程序上线之前无意地对其进行各种功能测试、压力测试和平安测试，从而增强了应用程序的性能——缩小了平安专家亲自测试代码所需的工夫。如果你可能找到某种办法来毁坏你的应用程序，那么攻击者也有可能毁坏你的应用程序，因而，你须要在应用程序启动之前构建测试以及补救措施。你须要打算这些测试工作，以及构建它们所需的资源。
- 并行化平安测试
所有麻利开发方法都有一个独特的问题，那就是如何解决比开发周期更长的测试。例如，咱们晓得对要害代码片段进行含糊测试所需的工夫比麻利 Sprint 的均匀工夫要长。对大量代码进行 SAST 扫描通常要比构建过程长一个数量级。DevOps 也是如此—— 应用 CI 和 CD 代码可能在创立后的几个小时内交付给用户，而且可能无奈执行残缺的白盒测试扫描或动静代码扫描。
为了解决这个问题，DevOps 团队同时运行多个平安测试以防止提早。他们将大型应用程序分解成服务，以放慢扫描速度。针对已知关键问题的验证由单元测试来解决，以便进行疾速抽查，并将失败的代码返回给开发团队。代码扫描器通常与单元测试或其余功能测试并行运行。
咱们的观点是，作为一名平安专家，你应该寻找放慢平安测试的办法。组织效率与速度的测试以及完整性与实现工夫的测试，对于咱们交谈过的每个开发团队来说，都是一种继续的均衡过程。将扫描集中在代码的特定区域有助于更快地发现问题。一些公司还探讨了保护预填充和齐全配置的测试服务器的打算——就像他们保护生产服务器一样——期待下一个测试周期以防止提早。为了提高效率和疾速部署而重写和重新配置测试环境有助于 CI。
5.6 预公布
- 弹性 FTW
有了公共云和虚拟化资源后，疾速提供测试服务器变得更加容易。咱们当初能够通过一些 API 调用启动新环境，并在不应用时缩容。利用随需应变的弹性云服务来减速平安测试。
- 测试数据治理
开发人员和测试人员有一个十分坏的习惯，就是将生产数据复制到开发和测试环境中以改良他们的测试。在过来的几十年里，这始终是许多数据泄露事件的源头。锁定生产环境，这样 QA 和开发人员就不能泄露受管制的数据，这很好，但也确保他们不会绕过你的安全控制。数据屏蔽、标记化和各种工具都能够生成高质量的测试数据，从而最大限度的升高它们应用生产数据的动机。
这些工具提供来自生产数据的测试数据，但去除了敏感信息。这种办法曾经证实对于许多公司是胜利的，而且大多数厂商为 DevOps 管道提供了适合的 API 或自动化性能。
5.7 部署
- 手动与自动化部署
通过自动化将新代码推入生产环境非常容易。但对代码进行审查，或者在呈现谬误时进行回滚，要艰难得多。与咱们交谈过的大多数团队还不能齐全适应全自动化部署——这会吓坏许多平安人员。继续的软件交付实际上只有多数公司应用。
大多数公司每隔几周才向客户公布新代码，通常是在一系列冲刺之后。这些公司通过脚本执行许多部署操作，然而在操作和开发资源可用时手动启动脚本以齐全监督推送操作。有些组织的确对齐全自动化的生产推送十分称心，每天会公布几次。没有繁多的正确答案，但无论哪种形式，自动化都能实现大部分工作，从而腾出人员进行测试和监督。
- 部署和回滚
为了仔细检查在预部署前的测试中工作的代码可能在开发环境中依然能够工作，咱们交谈过的团队依然会进行“冒烟”测试，然而他们曾经将这些测试进化为自动化和更细粒度的管制。
咱们看到了三个罕用于加强部署的技巧。
第一个也是最弱小的部署称为蓝 - 绿或红 - 黑部署。新旧代码并排运行，各自在本人的一组服务器上。在负载均衡器级别，如果发现错误，负载均衡器就会指向旧代码。
第二种是金丝雀测试，其中一小部分独自的会话是针对新代码的——优先的对外部员工的测试人员凋谢，而后凋谢给内部客户的子集。如果金丝雀死亡(遇到谬误)，新代码将退出，直到收回的代码能够修复为止，此时将反复该过程。
最初，个性标记通过配置文件启用和禁用新的代码元素。如果在新的代码段中发现了事件谬误，则能够敞开该个性，直到该个性失去修复。在不同的模型和组织之间，自动化和人工干预的水平有很大的不同，但总的来说，这些部署比传统的 web 服务环境更加自动化。
- 生产环境平安测试
即便安全控制失败，应用程序通常也能持续运行。例如，一个新的部署脚本可能会错过对 web 或应用层防火墙策略的更新，或者应用程序可能在没有任何防火墙爱护的状况下启动。
验证——至多是要害平安组件的健全性查看——对于生产环境是必不可少的。咱们采访的大多数大公司都雇佣了浸透测试人员，许多公司都有专职的“红队”来查看利用程序运行时的平安缺点。
- 自动化运行时的平安防护
许多公司将 Web 应用程序防火墙 (WAF) 作为其应用程序平安程序的一部分，通常是为了满足 PCI-DSS 需要。与咱们交谈过的大多数公司对这些工具都不称心，所以当他们持续利用 WAF 黑名单时，他们采纳了运行时应用程序自我爱护 (RASP) 来填补残余的空白。RASP 是一种利用平安技术，嵌入到应用程序或利用程序运行时环境中，查看应用层的申请，以实时检测攻打和误用。
除了“应用程序上下文中的 WAF”，RASP 还能够在应用程序框架的许多中央进行监控和执行，既能够针对特定类型的攻打定制爱护，也能够容许 web 应用程序申请“实现”，直到在阻止申请之前发现某个申请的确是歹意的。在过来三年里，咱们接到的简直所有探讨应用程序平安和 DevOps 的电话都探讨了 RASP，而且咱们接触的大多数公司都部署了这项技术。
5.8 应用程序平安规范
目前曾经有一些应用程序平安规范可用。开放式 Web 应用程序平安我的项目(OWASP) TOP 10 和 SANS 常见弱点枚举 TOP 25 是最风行的安全漏洞，但也有其余威逼和常见弱点列表，这些列表通常侧重于特定的子主题，如云部署或应用程序平安度量。每个规范都偏向于被一个或多个规范组织所承受，因而你应用的规范通常取决于你所处的行业。或者你能够把它们都用上。
无论你的抉择如何，咱们的想法都是理解哪些攻打是常见的，并在构建管道中应用一个或多个安全控制和应用程序平安测试来解释这些攻打。实质上，你构建的是一个威逼矩阵，并将它们映射到安全控制。此步骤将帮忙你打算采纳哪些平安工具并将这些工具放入构建过程，以及在生产中应用哪些平安工具。
六、平安在 DevOps 中的角色
正如后面提到的，DevOps 并不齐全是工具和技术，但它的胜利很大水平上取决于人们在这个模型中的工作形式。咱们曾经对工具和流程进行了具体的介绍，并且从平安从业者与 DevOps 单干的角度探讨了大部分内容。因为本文次要是为了帮忙平安人员，所以咱们在这里概述他们在 DevOps 环境中的作用。咱们心愿这个总结能帮忙你和其余团队一起工作，缩小摩擦。
尽管咱们无意将这篇文章命名为企业 DevSecOps，但请记住，你的开发，IT 同行们认为基本没有这回事。对他们来说，安全性成为集成和交付代码的操作过程的一部分。
咱们称安全性为一个独立的货色，是因为当它被编入 DevOps 框架时，平安人员实际上更难适应。你须要理解如何改良平安代码的交付，而不会浪费时间，也不会在你可能并不相熟的开发过程中引入瓶颈。好消息是，安全性非常适合 DevOps 模型，然而你须要在组织应用的自动化和编排中进行调整以获得成功。
6.1 平安专家的责任
- 学习 DevOps 模型
在本文中，咱们甚至还没有涉及 DevOps 的实践和实际。在基本概念和实际方面有很多货色须要你学习。要在 DevOps 环境中工作，你须要理解它是什么以及它是如何工作的。你须要理解文化和哲学上的变动，以及它们如何影响过程、工具和优先级。你须要理解公司的办法，以便最好地集成平安工具和指标。一旦你理解了开发团队的机制，你就会对如何在他们的流程上下文中与他们一起工作有了更好的理解。
- 学习如何变得麻利
参加 DevOps 团队意味着你须要适应 DevOps，而不是相同。DevOps 的指标是快、更快、最快: 提供疾速反馈的小型迭代更改，最终缩小在制品(Work In Progress，WIP)。为进步安全性而进行的小型迭代变更合乎这个模型。你将优先思考那些使得安全软件的交付优于新性能交付的事件，这通常是一项微小的工作，以扭转长期存在的“性能优先”的文化。你须要调整需要和倡议，使它们适宜于流程，通常简化为小步骤，并提供足够的信息，使工作既能够自动化，又能够被监督。你能够倡议进行人工代码审计或含糊测试，只有你理解它们在流程中的实用地位，以及哪些能够公布哪些不能公布。
- 培训
咱们的教训表明，使开发团队放慢安全性的最佳办法之一是培训: 外部解释或演示、帮忙应用程序平安的第三方专家、威逼建模、在线学习或各种商业课程。历史的负面影响是老本，许多课程要花费数千美元。你须要评估如何最好地利用你的资源——这个问题的答案通常包含为所有员工提供一些在线教学，抉择加入课程的人，而后教同龄人。邀请现场专家教学的费用可能很高，然而整个团队都能够加入培训。
- 减少本人的反对
如果没有帮忙，平安团队根本无法扩大他们的常识。这并不意味着会有数百名新的平安岗位的员工，而是意味着要委托开发人员帮忙产品进步安全性。平安团队通常很小，而且开发人员比例为 100:1。
此外，平安人员在大多数开发会议上都不缺席，因而他们在日常的麻利流动中不足可见性。为了帮忙扩大平安团队的覆盖范围，看看是否能够让每个开发团队中的某个人——也就是所谓的“平安冠军”——充当平安倡导者。这不仅有助于扩大平安团队的覆盖范围，还有助于扩大安全意识。
- 帮忙 DevOps 团队了解威逼
大多数开发人员并不齐全了解攻击者是如何攻打零碎的，或者当代码或 SQL 注入攻打是可能呈现的时候，这又意味着什么。平安威逼的深度和广度超出了他们的教训，大多数公司不传授威逼建模。
OWASP Top 10 是一个很好的指南，指出了困扰开发团队的代码缺点类型，然而你应该将这些威逼映射回事实世界的示例，展现 SQL 注入攻打可能造成的侵害，并解释 Heartbleed 类型的破绽如何可能齐全裸露客户凭证。能够把这些事实世界中的用例看作是“震撼和敬畏”，这对于帮忙开发人员“了解它”大有帮忙。
- 对补救措施提出倡议
如果你的平安倡议只是“加密数据”或“装置 WAF”，那么这种倡议是不够的。通常状况下，开发人员和 IT 人员对于安全性的形成只有一个繁多的想法，他们心愿设置并遗记一个繁多的工具。帮忙构建安全性程序的元素，包含代码内加强和反对工具。教诲他们如何帮忙解决特定的威逼，并提供部署和策略设置方面的帮忙。
过来，公司经常制作代码格调指南，教给年老的开发人员正确编写的代码是什么样的。通常状况下，这些资源都不是在线的。思考一个对于平安编码实际和其余参考资料的 Wiki 页面，这些材料很容易被没有平安背景的人发现并且很容易浏览。
- 帮忙评估平安工具
对于平安之外的人来说，充沛了解平安工具的作用或工作形式是不寻常的。因而，你能够通过两种形式提供帮忙: 首先，帮忙开发人员抉择工具。谬误的概念到处都是，这不仅仅是因为供应商承诺的能力过高。此外，对于开发人员来说，评估代码扫描器、流动监视器甚至补丁管理系统的有效性是不常见的。
作为参谋，你有责任帮忙 DevOps 理解这些工具可能提供什么能力，以及在你的测试框架中适宜什么。当然，你可能无奈评估 API 的品质，然而你能够判断一个产品在什么时候不能提供有意义的后果。其次，你应该帮忙定位开销，因为把握资金的人并不总是分明具体的工具如何解决安全性和听从性要求。你应该为满足业务需要的工具指定性能和报告要求。
- 有优先级的提供帮忙
在咱们的钻研过程中，许多平安专家通知咱们，所有的破绽看起来都像是高优先级的，辨别一个对组织有影响的破绽和一个没有影响的破绽是十分艰难的。破绽披露剖析畛域超出了开发人员的技能范畴。你须要帮忙填补这个空白，因为并非每个破绽都会带来真正的危险。
而且，平安人员长期以来都喜爱应用恐怖主义威逼等级，含糊地正告“重大危险”和“高威逼等级”。如果不把威逼和可能的破绽利用分割起来，不把破绽利用对企业意味着什么说分明，或者不晓得如何解决和升高危险，这些正告都是没有价值的。
例如，你能够修复代码中一个要害的应用程序破绽，对支持系统打补丁，如果不是要害的性能禁用则该性能，或者用 IDS 或防火墙进行阻止，甚至是用 WAF 或 RASP 技术进行过滤。或者在破绽利用实际上并不会侵害业务的状况下，“什么都不做”反而是正确的答案。而不是下意识的“天哪！当初就修复它!”咱们在历史上看到过这样的反馈—— 通常有几种抉择来修复一个破绽，所以向 DevOps 团队提出折衷方案能够让他们抉择最适宜的。
- 编写测试
DevOps 曾经将一些操作和版本管理人员置于一个不难受的地位，他们必须学习编写脚本，编写代码，并将他们的工作公开给公众评审。它在短期内将人们推出他们的舒服区，但这是在中期内建设一个有凝聚力的团队的要害局部。
平安人员向团队奉献测试是齐全能够承受的: 验证证书的扫描、查看已知的 SQL 注入攻打、定位破绽的开源工具等等。如果你对此感到放心，那么请帮忙并集成单元测试和回归测试。交融和投合！要加入一个 DevOps 团队，其中自动化起着关键作用，你可能须要晓得如何编写脚本或模板。
好消息是，你们的策略当初曾经体现在环境的定义中。不要胆怯你不晓得源代码管制或脚本的正确格局; 这是开发人员通常热衷于提供帮忙的畛域。在将你的测试集成到构建和部署服务器之前，你能够在脚本编写方面学一些货色，然而你要做的不仅仅是鼓吹安全性——你也能够做出奉献！
- 宣传
你能够帮忙开发团队的一个要害畛域是理解公司和内部的策略需要。正如 CVE 条目简直不通知你如何修复某个平安问题一样，外部平安和隐衷策略执行对于开发团队来说经常是个谜。开发者不能在谷歌上搜寻这些答案，所以你能够提供本人作为参谋。你至多应该像开发团队中的任何人一样了解听从性、隐衷、软件受权和安全策略，所以他们可能会感谢你的帮忙。
小编注
这个系列文章比大多数其余文章都要长一点，DevSecOps 是一个特地的畛域，所有人都关注平安，但所有人如同又都不晓得什么是平安，如何达成。对于未知事物的恐怖，造成了人们谈虎色变，平安的动作也逐步开始变味走了型。本次特意将系列文章编著在一篇推文中，目标就是心愿从全局的视角给大家一个残缺的 DevSecOps。
（本系列文章发表于 Securosis 网站，原文题目是“企业 DevSecOps”，咱们是从嘶吼的内容转发的（做了少许文字上的优化），并不确认嘶吼就是原始的译者，无从讲究。）
作者：Adrian Lane
原文：http://securosis.com/blog/ent…
转自：https://www.4hou.com/ 嘶吼 ROARTALK
玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入
