随着DevOps在快速交付和创新IT支持能力方面越来越受欢迎，大家开始对安全和合规的关注性也在增加。安全风险管理负责人必须在不减慢开发进程的情况下，调整安全工具、流程和方针以适应DevOps工具链。

01

概述

关键挑战

①作为传统瀑布式和敏捷开发模式的替代方案，DevOps的使用正在增加，但是对安全和合规的考虑处于滞后状态。

②DevOps强调自动化以实现目标，但传统意义上安全是缓慢的、存在复杂流程的和边界的——与DevOps强调的自动化、透明性和快速正好相反。

③大多数DevOps开发人员不了解安全性。

④传统应用程序安全性测试通常不考虑速度和透明度的。

⑤对于特定行业的某些应用，产品每次更新后的新版本需要得到政府监管单位重新认证，这使得快速迭代成为问题。

建议

作为负责改进应用安全性的DevOps团队，其安全风险管理者应该：

① 根据业务风险和监管要求与项目负责人协商，提前决定适合DevSecOps的项目。

② 将现有开发生命周期中安全工具调整到DevOps流程中，前移为开发人员可以快速采取的、可操作小步骤，并向后移动到自动化工具和响应流程中。

③ 通常情况下，为整合持续集成/持续开发（CI / CD）工具提供明确的支持，要求所有应用程序安全测试供应商，提供全面支持API接口的自动化解决方案。

④ 改进和协调已经集成到生命周期内各个阶段工具的响应方式，以开发人员更喜欢的方式将情报定位到不同阶段。

02

战略规划设想

到2019年，只有10％的DevOps计划能够完全达到DevSecOps所需的安全自动化水平，而2017年还不到5％。

介绍

DevOps强调通过提高交付速度和持续创新IT能力这样的共同目标，来拆除开发和IT运维之间“墙壁”。与DevOps相关的Gartner咨询业务稳步增长，从2015年的每月几个电话增长到2017年每月超过25个新电话。安全和开发管理人都在努力使项目和流程适应这种方法。虽然DevOps给快速迭代和开发业务带来了许多优势，但它也给负责支持这些项目安全开发的风险管理人员提出了严峻的挑战。为启用DevSecOps，安全团队将需要调整现有应用程序的安全方案，以适应DevOps所需的快速度，同时又不牺牲安全性或合规性。

传统的应用程序安全测试依赖于重度的、一次性过关检查，通常在测试期间执行，需要几天甚至几周，并且需要安全专业人员来执行。传统安全测试不能简单地扩展为DevSecOps。DevOps强调持续响应和自动化改进。安全需要有这样思维模式，即在整个DevOps流程中，在服务创建最初阶段就开始考虑安全，并随着每次后续迭代进行连续地、自动化地改进。图1显示了Gartner将DevSecOps视为一个连续循环的视图，每个阶段平滑地进入下一个阶段。重点在于持续的交付周期，自动化流程可以实现渐进式地、安全地、可监控地改进。

图1. DevSecOps：将安全融入到DevOps

资料来源：Gartner（2017年11月）

攻不破的应用是不存在的。因此，安全风险管理领导者必须在安全需求与开发速度之间取得平衡。然而并非每个项目都应转换为DevOps方式进行开发。解决上述这些问题是构建DevSecOps项目的关键难题。下面，我们提供构建DevSecOps能力的最佳实践方案。

分析

尽早确定DevSecOps是否适合某个特定的项目。

DevOps作为一种方法论，它强调协作、敏捷性和快速迭代。然而，有些应用程序受限于隐私、法规和强制监管。这让开发流程与合规问题绑定在一起了，使得对产品的更改变得更加麻烦。在金融服务、医疗保健和制造业等一些垂直行业中，政府监管限制了对某些部分的生产环节可以采取的措施。例如：就像药品制造商生产环境变化后需要让FDA重新认证一样，某些软件更新后需要重新认证。由于这是一个昂贵、耗时的过程，会使生产系统在一段时间内处于脱机状态，因此这些认证往往会在其它停机时间窗口中提前安排。

然而，即使在受到严格监管的行业中，并非每个环节都受到这些限制。 实际上，一般来说，受限制或受监管系统的数量只占整个系统的小部分。DevSecOps通常非常适合快速创新和迭代，在面向客户时也存在很大优势。

虽然DevOps对于安全风险管理者来说可能特别具有挑战性，但是当业务风险可以接受时，应该尽一切努力这样做。安全风险管理领导者有责任预先识别这些系统，然后与开发人员一起定义界限，以便在DevOps方法可能不太适合某些法规或安全需求的情况下指导项目。

相信企业有充分的理由采用DevOps，比如为了尽可能支持产品上市速度和提高发布质量等。在“DevOps报告状态”中，Gartner的CEB研究团队进行的一项调查显示，39%的IT领导者发现DevOps在一定程度上帮助满足了业务需求，61%的人说DevOps提供了广泛的帮助。对于安全风险管理负责人来说，重点应该是如何尽可能地使其工作。为那些不会带来不可接受风险的项目，寻找促进安全发展的方法。不做会对业务构成风险的决策，并与相关人员进行相关的沟通。

建议

① 与相关人员协商，确定DevSecOps可能不适合指导的时间。

② 在设定组建团队之前，将开发方法与项目的约束限制相匹配。

③ 严格监管或法律强制的地方并不适合DevSecOps，但是面对客户和合作伙伴的接口通常是很好的候选者。

通过将现有的安全开发工具扩展到整个生命周期，使其适应DevOps过程。

DevSecOps流程的各个阶段在较高层次上，可拆分为10个熟悉的细分步骤（参见图2）。

图2. 10类DevSecOps工具

资料来源：Gartner（2017年11月）

传统软件开发生命周期的许多安全工具仍将适用于DevSecOps，尽管它们运行的速度和频率可能非常不同。在某些情况下，当供应商没有修改其功能以适合自动化时(例如，API支持)，需要购买新工具以解决差距。

前置：DevSecOps中常常使用的一个短语，前置直接映射出战略方针，即将更多的测试转移到图2的左边，也就是在产品生命周期中越早越好。安全主管应该从计划开始，将重点放在用于早期测试和自动化检测的技术上，并将重点放在开发人员可以快速采取的可操作的小步骤上。

计划

计划很重要，解决安全和技术债务也很重要。确定在接下来的几个scrums中要解决的安全问题，并将它们添加到工作列表中。调查什么样安全需求需要开始解决，以及现在是否应该开始编写基础代码。在这个阶段，安全培训、威胁建模和工具培训这些事情也需要解决。您可以选择在接下来的几次scrum中支持一部分开发人员，让他们在团队其它成员在处理问题时进行培训。然后，在下一个计划周期中，将它们进行更改，直到所有的开发人员都能跟上进度。

即时响应是DevSecOps的一个关键要素，众所周知，Bug越早被发现，修复的成本就越低也越容易。在生命周期的接下来的几个阶段，Gartner强调前置哲学——即支持开发人员在这个过程中使用工具, 来获得清晰的、可操作的信息，并尽早获得反馈。

我们还建议已经接受过一些安全培训的开发人员，来回答基本安全问题，发现问题并作为IT安全的接口。

创建

强调向左移位的前置理念，支持直接在开发人员的集成开发环境(IDE)中集成相关安全工具和解决方案。许多安全工具供应商提供了一个“安全拼写检查器”，可以捕获常见的安全错误，并提供修复方案。但是，要小心避免无用的警告或无意的建议，这会无意慢慢让开发人员忽略该工具。为了避免这些问题，基于IDE的安全测试工具常常需要牺牲覆盖面来减少误报，而不像对整个系统进行静态分析测试那样识别许多问题。IDE插件并不能代替全面的静态分析测试。但是，根据DevSecOps的理念，它们可以在前期捕获简单的错误。

创建阶段的其它关键活动包括威胁建模、安全架构审核(针对跨多个迭代版本的新组件或更大的项目)和开源审查。所有这些活动都可以从具备安全能力的开发者那儿得到极大的便利。

验证

此处的DevSecOps扫描可以分为两大类：(1)扫描已知/重用代码中的已知漏洞和错误配置；(2)扫描自定义代码中的未知漏洞。在现代的DevOps开发中，应用程序中的大部分代码是“组装”的，而不是开发的，并且大部分代码是从开源和第三方库、框架和组件中重用的。首先扫描这些已知的漏洞和已知的错误配置将解决大多数风险。

可以在下载组件时使用具有修复功能的软件组合分析解决方案来强制执行组织的开源软件代码，从而可以主动进行验证，开发人员可以在项目开始时利用已经被验证的不存在问题的组件库。同时，在其它项目中也可以自动执行。

对于自定义代码的扫描，可以将传统的静态和动态应用程序安全测试工具(SAST和DAST)与SCA一起应用，以帮助理解项目对底层开源代码(如Struts)的依赖。随着DevOps广泛的应用，SAST供应商开始提供可以在几分钟内而不是几个小时内完成“快速扫描”，静态分析扫描仅查找最常见的错误。WhiteHat Scout就是一个典型的例子。这并不能满足对全面扫描的需求，全面扫描仍应定期运行。但更轻，更快的扫描才可作为DevOps组织的一部分，而不会对产品产生较重的影响。

交互式应用安全测试(IAST)是验证阶段的关键技术。IAST是DAST的一种改进形式，应用程序从内部进行检测，同时从外部执行扫描。IAST是在运行的代码上执行的，可以集成到整个DevOps过程中。在IAST中，代码经过检测，以便在测试或攻击时生成可用于提高安全性或响应攻击的数据。运行时应用程序自保护(RASP)是IAST产生的一种后置“右移”技术。虽然由于性能和兼容性问题，组织一直不愿意在运行时部署RASP，但这些问题在开发过程中不太突出（图3的左侧）。

图3 IAST是一种向前置左移的安全技术 ；

RASP后置右移的安全技术

资料来源:Gartner(2017年11月)

注意，大多数IAST实现都需要应用程序在运行时进行检测(Java、.NET、PHP、Ruby、Python、Node)，并不是所有的供应商都支持所有的平台，所以IAST不可能在所有的应用程序上都能使用，更传统的DAST可能需要使用(假设它可以完全自动化，并且对开发人员透明地执行)。

验证阶段也是培训开发人员安全意识的好阶段，这些开发人员已接受过一些安全培训。 在安全培训中，可以训练开发人员阅读安全工具测试结果的能力，使之成为开发人员技能包的一部分。这有助于培训开发人员，让他们具备判断关键或高危安全问题以及低优先级问题（或误报）。让他们对发布产品的整体安全态势有更好的感觉，并能够提出在以后的scrum中需要解决的安全问题。

验证阶段的其他活动还包括应用协议和输入的模糊测试、应用程序漏洞相关(AVC)和移动应用程序安全测试(MAST)。

试运行

支持像IAST这样的解决方案，能够测试代码，并查看它对已知攻击以及模糊测试和chaos - monkey测试的反应。攻击是不确定性的，所以投入多少时间取决于你自己，但这恰恰是一种克服测试偏见和僵化思维的测试。当认为代码已经准备好时，应将其签入发布分支签名并加盖时间戳。这将有助于发布的完整性检查。Peach是开源性测试工具中很好的模糊测试工具。

模糊测试工具在应用于DevOps时具有独特的机会。与传统的测试不同的是，由于它是基于随机性的，所以没有具体的建议来决定要做多少。一个不确定的测试可能会运行数周而且永远不会发现漏洞，或者它可能会在第一次尝试中遇到漏洞，这些都没有办法提前知道。但是，因为DevOps强调迭代开发，所以代码通过这种测试运行的频率远远超过像瀑布这样的方法开发的代码。因为随机测试迭代地累积结果，所以随着时间的推移，这实际上通过更多次数的测试。

发布

检查时间戳签名并部署到CI / CD中。我们设想将在DevSecOps环境中使用多个签名，以反映不同类型测试的成功完成。例如，SCA完成的签名，用于IAST的另一个签名以及完整漏洞扫描的签名。如果未确认其已满足所需的安全性和合规性检查，则不允许将代码发布到生产环境中。

后置右移：强调不需要人工干预的持续监控和自动化工具。正如在开发过程中一样，我们强调了前置左移哲学，因为在这个周期中，更容易快速地纠正错误。现在我们转向后置右移姿势，将焦点转移到攻击面。我们依靠技术来检测和保护应用程序免受威胁，以及应用程序“出错自动关闭”以尽可能保护其数据完整性。我们还需要有关现有网络环境的威胁情报信息，并希望将有关攻击，尝试将其反馈到流程中，以帮助我们了解下一个周期。从应用程序中获取有关其环境的信息，以通知开发人员并将其转化为可操作的安全性改进，例如重新确定培训优先级，添加安全要求或根据此智能扩充威胁模型。

防护

在实例化配置时保证代码是我们所想要的，并且符合要发布到生产中的所有要求。常见的安全控制包括应用程序控制（白名单），强制服务器工作负载运行在指定机器上。此方法是工作负载安全的基础，应被视为工作负载保护的主要控制机制。纵深防御（DND）（DDoS防护等）也适用于此处。对于网络流量，通过部署身份检测和防御系统（IDPS），用户和实体行为分析（UEBA）或越来越多的下一代防火墙（NGFW）等其它技术能够观察连接或用户的行为并确定意图实现主动保护。

检测

安全负责人必须承认，并非所有漏洞都会在开发中被识别出来，而且有些漏洞将不可避免地进入生产阶段。任何应用程序开发方法（包括DevOps）都是如此，因此，无论开发方法如何，都需要对运行中系统架构问题进行快速检测。这里的应用程序依赖于RASP等技术，这些技术允许应用程序在受到攻击时通过自我保护或采用安全失败机制进行响应。

响应

现有的应用安全响应技术很多，但通常分为三类：

（1）依靠现有纵深防御保护应用程序。例如，许多网络硬件提供商将提供DDoS保护作为其路由器和交互机的一部分。这可以是响应威胁的好方法，前提是您已完成基本威胁建模，以使现有防御与您的应用程序相匹配。

（2）依靠更积极的技术，如RASP或WAF，可以检测应用程序正在经历的攻击类型，并设置适当的防御、警告或者记录攻击行为。RASP与IAST密切相关，IAST测试应该让应用程序知道用于成功保护自身的各种响应机制。

（3）依靠更加被动的响应，如应用程序加固，代码混淆和API网关。

任何情况下，来自攻击面的威胁情报对于采取正确防御措施，以及让开发团队了解有关应用程序在真实环境中响应情况都至关重要。确保能够通过安全信息和事件管理（SIEM），安全编排或监视，确保存在一个链路可以将信息返回“计划阶段”，使得开发人员根据信息调整系统，这一点至关重要。对该信息的响应可能是事件响应，运营调整或简单的安全技术债务。无论如何，它需要纳入整个开发流程。

预测

利用从检测和响应阶段收到的可视化和远程通信信息，我们希望能够借此预测系统需要构建的新对策。例如，不寻常的Web路径遍历模式表明攻击者可能正在利用尚未修补的潜在漏洞。

这需要从攻击面收集信息和分析数据，并反馈到产品计划阶段。这种可视化和大数据能力还可以用于支持后续类似项目的威胁建模和安全需求收集活动。此外，STIX和TAXII等标准越来越被认为是组织之间、执法部门和政府机构之间共享情报的有效方式。

第三方威胁情报库也成为此阶段的关键部分。例如，在Struts等广泛使用的框架中发现新漏洞时，此类信息可帮助开发在工作流程中优先处理修复漏洞。如果漏洞至关重要且受影响的应用程序/服务也至关重要，那么开发可以使用更新库或框架解决该问题，并确定新的自动发布的优先级。

自适应

将安全实践应用到DevOps中通常要分阶段进行，并且不可避免地会发现需要改进地方或漏洞。通过获取系统及其设备已收到的所有信息，并将其用于下一轮要求，包括关键事件的Scrum级别和不太紧急问题的规划级别等。这还可能涉及某种程度的数据分析或数据缩减技术，以使信息成为可操作的活动。随着时间的推移，应用安全测试解决方案需要进行重新配置和改进，以更好地支持程序。这些解决方案会产生的大量研究结果往往会压倒安全和开发团队，因此需要对解决方案进行调整。例如，需要调整SAST以关注更高价值的情报，并尽量抑制误报漏报等情况发生。持续的反馈和开发应成为安全团队的口头禅，它将使用收集的报警信息和统计数据以及相关人员的反馈信息来改进安全实践流程和工具，以便更好地支持未来的项目。

建议：

•计划：威胁建模，安全需求收集和安全培训

•创建：IDE安全插件

•验证：SAST / DAST / SCA / IAST

•预生产：Chaos Monkey，模糊测试，代码签名，IAST

•发布：签名验证，完整性检查

•预防：纵深防御措施

•检测：RASP，渗透测试，UEBA

•响应：RASP / WAF应用程序加固和代码混淆

•预测：CVA，IoC / TI STIX TAXII

•适应：技术债务/事件响应（IR）

本文翻译自国外报告《Integrating Security Into the DevSecOps Toolchain》，如引用或转载请联系原作者。

青藤云安全以服务器安全为核心，采用自适应安全架构，将预测、防御、监控和响应能力融为一体，构建基于主机端的安全态势感知平台，为用户提供持续的安全监控、分析和快速响应能力，帮助用户在公有云、私有云、混合云、物理机、虚拟机等多样化的业务环境下，实现安全的统一策略管理，有效预测风险，精准感知威胁，提升响应效率，全方位保护企业数字资产的安全与业务的高效开展。