1. DevSecOps概况

DevSecOps，又称为安全DevOps，是软件开发中的一种思维，每个人都应对应用程序安全负责。通过将开发人员与IT运营集成在一起，并使每个人都专注于做出更好的安全决策，开发团队希望以更快的速度和更高的效率提供更安全的软件。

DevSecOps（Development Security Operations的缩写）最早由Gartner咨询公司研究员David Cearley在2012年首次提出，它是一种糅合了开发、安全及运营理念的全新安全管理模式。2016年9月，Gartner发布报告《DevSecOps:How to Seamlessly Integrate Security into DevOps》，提出了DevSecOps模型。DevSecOps通过在DevOps其生命周期阶段融入相关的安全实践，以帮助企业达成DevSec+SecOps的目标，使得近期DevSecOps成为业界关注的新的焦点。

1.1 关于DevSecOps的几点理解

• 是一种安全的文化的渗透

• 是制度流程和工具的集合

• 是将安全性和合规性纳入软件全生命周期的方法

• 是由学习和实践驱动的战略

1.2 DevSecOps起因

（1）组织与文化

• 开发运维人员缺少安全技能，意识

• 安全专业人员很有限

• 第一道防线安全往往在运维的基础架构职能下，地位不高很难协同工作

• 开发、运维之间的壁垒，安全职能难以嵌入进 IT 声明周期的各个阶段

• 开发交付团队，设置管理层过度地强调进度，而忽视了安全风险

（2）过程与控制

• 漏洞一般是在上线前被检测发现，而不持续在开发流程中被识别，导致修复成本高

• 控制点或审计过于滞后或缺失

• 安全需求、架构设计的持续交付得不到保障

• 缺少全链条各阶段的风险视角和管理能力

（3）技术与架构

• 老旧，不标准的架构与应用系统

• 失效的最佳实践和架构模式

• 环境标准化及维护程度低

（4）技能与工具

• 安全人员技能欠缺、安全“运营”的程度低

• 安全工具自动化不足或集成程度不高

1.3 DevSecOps生命周期

DevSecOps的主要特征是通过在软件生命周期的各个阶段进行自动化，监控和应用安全性来提高客户成果和使命价值，包括计划、创建、验证、预发布、发布、预防、检测、响应、预测和适应阶段。

（1）计划阶段：作为DevSecOps的第一个阶段，其包含了SDL模型里培训、需求、设计等几个阶段，主要关注的是开发前的安全动作。

（2）创建阶段：创建阶段主要就是指编码阶段。编码阶段主要进行安全编码及检查，旨在在编码阶段进行安全风险的消除。

（3）验证阶段：验 证 阶 段 其 实 就 是 测 试 阶 段，主 要 以 自 动 化 的 应 用 安 全 测 试（AST，Application Security Testing）和 软 件 成 分 分 析（SCA，Software Composition Analysis）为主。

（4）预发布阶段：预发布阶段一般是测试阶段及正式发布阶段的中间阶段，其与测试阶段不同的是预发布阶段所发布的预发布环境是连接的正式环境的数据库等，其等同于独立部署的非对外公开的正式环境。在DevSecOps工具链中预发布阶段主要包含有混沌工程（Chaos Engineering）、模糊测试（Fuzzing）、集成测试三个安全动作。

（5）发布阶段：针对发布阶段，在DevSecOps的流程中主要动作是软件签名，与预防阶段结合来看，主要是软件防篡改。

（6）预防阶段：该阶段主要包含有签名验证、完整性检查和纵深防御。

（7）检测阶段：从预防阶段，就已经从开发切换到运维阶段，而检测阶段则更符合传统安全中相关的安全监控动作，该阶段主要包含有RASP、UEBA、网络流量监控、渗透测试几个安全动作。

（8）响应阶段：在DevSecOps的响应阶段，安全动作主要包含有安全编排、基于RASP/WAF的防护、以及混淆。

（9）预测阶段：预测阶段主要涉及漏洞相关性分析与威胁情报。

（10）适应阶段：适应阶段主要强调了安全技术债务、修改应急响应方案、安全防御方案等几个点。其实这个阶段也可以称作优化阶段，主要是基于DevSecOps实施的整个流程的情况，进行持续的适配改进和项目调整优化，对应到过去安全动作，可以理解为持续运营反馈调整的过程，包含对相关安全问题的持续跟踪、闭环，对DevSecOps过程中相关安全动作如策略的调整等。

1.4 DevSecOps标准内容解读

安全及风险管理标准框架：《研发运营一体化（DevOps）能力成熟度模型 第6部分：安全及风险管理》标准是一种全新的安全理念与模式，强调安全是每个人的责任，将安全内嵌到应用的全生命周期，在安全风险可控的前提下，帮助企业提升IT效能，更好地实现研发运营一体化，整个框架划分为：控制总体风险、控制开发过程风险、控制交付过程风险和控制运营过程风险四大部分。

1.4.1 控制总体风险

在DevOps模式下，安全内建于开发、交付、运营过程中，总体风险包括三个过程中的共性安全要求，包括：组织建设与人员管理、安全工具链、基础设施管理、第三方管理、数据管理、度量与反馈改进。

（1）组织建设与人员管理：在DevSecOps全过程中，建立对应的组织负责不同的安全职责，注重安全文化建设。

（2）安全工具链：要求安全左移，将漏洞扫描、应用安全测试、开源合规、威胁建模、自动化漏洞扫描平台等安全工具嵌入DevOps全生命周期。

（3）基础设施管理：要求基础设施在DevOps全生命周期中，提供安全、可靠、稳定、可持续的基础环境以及支撑服务的平台。

（4）第三方管理：包括第三方机构、第三方人员、第三方软件以及第三方服务，并通过合作进行安全风险控制。

（5）数据管理：在DevOps过程中对涉及的各类数据进行安全管理，利用制度、流程及工具化等手段保障数据的安全性。

（6）度量与反馈改进：通过对研发、交付、运营过程的安全风险进行度量，展示并反馈给团队处理和改进。

1.4.2 控制开发过程风险

为降低后续交付、运营中的安全风险，保障研发运营一体化的整体安全，必须提前实施安全风险管理工作。在应用的需求阶段就进行安全风险控制，同时关注架构与设计的安全风险，并在开发过程中实施安全风险管理。

（1）需求管理：将安全工作左移，在应用的需求阶段进行安全风险控制，定义安全需求并采取有效的措施和手段，从而控制开发过程的安全风险。

（2）设计管理：通过攻击面分析、威胁建模等手段，识别应用潜在的安全风险和威胁，制定措施消减威胁、规避风险，确保产品安全性。

（3）开发过程管理：关注编码过程的安全管理，以安全编码方式实现功能。

1.4.3 控制交付过程风险：

安全交付是将安全内建到交付过程中，是实现安全运营的前提条件。通过将配置管理、构建管理、测试管理及部署与发布管理等交付过程纳入安全风险管理，使得系统、产品、服务可以在安全完整的最佳状态下支付。

（1）配置管理：是保障交付过程正确性的前提，包括对源代码及相关脚本、依赖组件、发布制品、应用配置、环境配置等的安全管理。

（2）构建管理：安全的构建管理可提升应用的发布制品安全性，可靠可重复的构建过程有利于安全问题的避免和版本变更追溯。

（3）测试管理：在应用发布前，通过安全测试发现并排除应用的安全缺陷，提高安全质量。

（4）部署与发布管理：安全的部署与发布关注安全的流程与规范、过程中的安全控制与低风险的发布机制。

1.4.4 控制运营过程风险：

关注将安全内建于运营过程中，通过监控、运营、响应、反馈等实现技术运营过程中安全风险的闭环管理，包括：安全监控、运营安全、应急响应和运营反馈。

（1）安全监控：对运营过程中的安全进行监控，覆盖业务场景与基础运营环境，如：病毒攻击、DDos攻击、暴力破解、注入攻击、接口滥用、Web欺诈等。

（2）运营安全：应用在运营过程中实施安全控制、识别、评估漏洞与缺陷，并降低或消除风险。同时，也包括对运营过程中配置管理、变更管理等的安全管理。

（3）应急响应：针对运营过程中的安全事件、风险进行响应、跟踪和处置，及时降低风险和影响，保障业务连续性。

（4）运营反馈：关注运营过程中安全的动态性、持续性和整体性，通过对安全漏洞、缺陷、事件等的分析与反馈，实现从运营到开发过程的DevSecOps闭环管理。

1.5 DevSecOps能力蓝图

图片来源：《CU-DevSecOps实践白皮书》

1.6 DevSecOps安全工具金字塔

DevSecOps中的应用安全管理和保障能力依赖不同的安全工具能力互相作用、叠加、协作而实现，DevSecOps安全工具金字塔描述了安全工具所属的不同层次。安全工具之间的边界有时会模糊不清，因为单一的安全工具可以实现多种类别的安全能力。

DevSecOps安全工具金字塔描述了一组层次结构，金字塔底部的工具是基础工具，随着组织DevSecOps实践成熟度的提高，组织可能会希望使用金字塔中较高的一些更先进的方法。金字塔中的安全工具分层与组织的DevSecOps成熟度分级没有直接关系，仅使用低层次的安全工具也可以完成高等级的DevSecOps实践成熟度，反之亦然。金字塔中的工具分层与该工具的普适性、侵入性、易用性等因素相关。普适性强、侵入性低、易用性高的安全工具更适合作为底层基础优先引入，普适性弱、侵入性高、易用性低的工具则适合作为进阶工具帮助DevSecOps实践变得更加完善且深入。

图片来源：开源网安

（1）CARTA平台

CARTA（Continuous Adaptive Risk and Trust Assessment，持续自适应风险与信任评估）由Gartner在2018年十大安全技术趋势中首次提出，在 2019 年再次被列入十大安全项目，也是Gartner主推的一种应对当前及未来安全趋势先进战略方法。CARTA 强调对风险和信任的评估分析，这个分析的过程就是一个权衡的过程，告别传统安全门式允许/阻断的处置方式，旨在通过动态智能分析来评估用户行为，放弃追求完美的安全，不能要求零风险，不要求100% 信任，寻求一种0和1之间的风险与信任的平衡。CARTA战略是一个庞大的体系，其包括大数据、AI、机器学习、自动化、行为分析、威胁检测、安全防护、安全评估等方面，集主流技术于一体打造出一个自适应自判断安全防护平台。CARTA跟DevSecOps的趋势一致，将安全左移至开发阶段，并最终集成在整个生命周期中，完成敏捷化的自适应风险和信任评估。因此CARTA已逐渐从单纯的生产环境实践方法，融合进DevSecOps的体系之中。

（2）应用安全性测试即服务（ASTaaS）

随着应用开发环境的开放化以及云服务日趋成熟，更轻量级的ASTaaS逐渐开始被接受。在ASTaaS上，使用者通常仅需按需付费来对应用程序执行安全测试，而不必再分别购买昂贵的私有化安全设备。该服务通常是静态和动态分析，渗透测试，应用程序编程接口（API）测试，风险评估等安全功能的组合。ASTaaS 通常用于移动和 Web 应用程序。ASTaaS的发展动力主要来自云应用程序的使用，在云应用程序中，用于测试的资源更易于配置。有数据表明，全球在公共云计算上的支出预计将从2015年的670亿美元增加到2020年的1620亿美元。

（3）应用安全测试编排（ASTO）

应用安全测试编排（Application Security Testing Orchestration，ASTO）由Gartner首次提出，目前该技术和工具还处于较为初始的阶段。其目标是对生态系统中运行的所有不同的应用安全测试工具进行集中、协调的管理和报告。ASTO综合管理SAST/SCA/IAST/DAST等各种安全工具的检测能力，完善与开发工具链条的集成与自动化能力，提供安全能力编排方案。用户自定义编排安全检测的手段、工具与其它安全产品的自动化集成响应。

（4）模糊测试

模糊测试（fuzz testing）是一种介于完全的手工渗透测试与完全的自动化测试之间的安全性测试类型。能够在一项产品投入市场使用之前对潜在的应当被阻断的攻击路径进行提示。从执行过程来说，模糊测试的执行过程很简单，大致如下：

• 准备好随机或者半随机方式生成的数据；

• 将准备好的数据导入被测试的系统；

• 用程序打开文件检测被测试系统的状态；

• 根据被测系统的状态判断是否存在潜在的漏洞。

（5）容器安全

容器安全是保护云原生环境免受漏洞和主动攻击威胁所需的安全工具。容器安全工具可完全集成到构建和部署管道中，提供针对容器镜像的漏洞管理功能，实现并强制实施合规性。容器安全工具能保护容器的完整性，这包括从其承载的应用到其所依赖的基础架构等全部内容。通常而言，组织拥有持续的容器安全包含以下方面：

• 保护容器管道和应用；

• 保护容器部署环境和基础架构；

• 整合企业安全工具，遵循或增强现有的安全策略。

（6）运行时应用自保护（RASP）

运行时应用自保护 (RASP) 是一种嵌入到应用程序或应用程序运行时环境的安全技术，在应用层检查请求，实时检测并阻断攻击。RASP产品通常包含以下功能:

• 通常在应用程序上下文中进行解包和检查应用程序请求；

• 产品可以在多个执行点分析完整的请求，执行监控和阻止，有时甚至更改请求以去除恶意内容；

• 完整的功能可通过RESTful API访问；

• 防止所有类型的应用程序攻击，并确定攻击是否会成功；

• 查明漏洞所在的模块，还有特定的代码行；

• 仪表盘功能和使用情况报告。

（7）软件组成分析（SCA）

SCA工具检查软件，以确定软件中所有组件和库的来源。SCA工具在识别和发现常见和流行组件（尤其是开源组件）中的漏洞方面非常有效。但是，它们通常不会检测内部自定义开发组件的漏洞。SCA工具在查找通用和流行的库和组件（尤其是开放源代码部分）方面最为有效。它们的工作原理是将代码中的已知模块与已知漏洞库进行比较。SCA工具查找具有已知漏洞并已记录漏洞的组件，并且通常会提示使用者组件是否过时或有可用的补丁修补程序。

（8）交互式应用安全测试（IAST）

IAST曾被Gartner多次列为十大安全技术。IAST工具结合了SAST和DAST技术的优点。IAST可以模拟验证代码中的已知漏洞是否可以真的在运行的环境中被利用。IAST工具利用对应用程序流和数据流的了解来创建高级攻击方案，并递归地使用动态分析结果：在执行动态扫描时，该工具将基于应用程序对测试用例的响应方式来了解有关应用程序的知识。一些工具将使用这些知识来创建其他测试用例，然后可以为更多的测试用例产生更多的知识，依此类推。IAST工具擅于减少误报数，并且可以很完美地使用在敏捷和DevOps环境。在这些环境中，传统的独立DAST和SAST工具在开发周期中可能会占用大量时间，而IAST几乎不会对原有应用生产效率产生任何影响。

（9）PTE自动化渗透测试

自动化渗透测试是近年来逐渐被关注的一项新技术，其目的是用自动化测试的方式实现以往只有依靠白帽子人工完成的渗透测试工作，以提高漏洞检测效率，降低检测成本。这一类工具是随着机器学习等AI技术的发展而产生并成熟的。自动化渗透测试工具可以将白帽子在大量渗透过程中积累的实战经验转化为机器可存储、识别、处理的结构化经验，并且在测试过程中借助 AI 算法自我迭代，自动化地完成逻辑推理决策，以贴近实际人工渗透的方式，对给定目标进行从信息收集到漏洞利用的完整测试过程。

（10）EDR

端点检测与响应 (Endpoint Detection & Response，EDR) 是一种主动的安全方法，可以实时监控端点，并搜索 渗透到公司防御系统中的威胁。 这是一种新兴的技术，可以更好地了解端点上发生的事情，提供关于攻击的上下文和详细信息。EDR服务可以让你知道攻击者是否及何时进入你的网络，并在攻击发生时检测攻击路径ーー帮助你在记录的时间内对事件作出反应。

（11）静态应用安全测试（SAST）

SAST又称白盒测试，测试人员可以在其中了解有关被测代码的信息，包括体系结构图、常规漏洞、不安全编码等内容。SAST工具可以发现源代码中可能导致安全漏洞的脆弱点，还可以通过IDE插件形式与集成开发环境结合，实时检测代码漏洞问题，漏洞发现更及时，使得修复成本更低。源代码分析器可以在未编译的代码上运行，以检查缺陷，覆盖赋值越界、输入验证、竞争条件、路径遍历、指针和引用等。部分SAST工具也可以用二进制和字节码分析器对已构建和已编译的代码执行相同的操作，但这实际上已进入SCA和DAST的范畴。

（12）移动应用安全测试（MAST）

MAST工具融合了静态，动态和取证分析。它们执行的功能与传统的静态和动态分析器类似。MAST工具具有专门针对移动应用程序问题的独特功能，例如越狱检测、伪造WI-FI链接测试、证书的处理和验证、防止数据泄漏等。

（13）动态应用安全测试（DAST）

DAST工具又称黑盒测试，与SAST工具相对应。测试人员无需具备编程能力，无需了解应用程序的内部逻辑结构，也无须了解代码细节。DAST不区分测试对象的实现语言，采用攻击特征库来做漏洞发现与验证。DAST工具针对编译后的可执行程序运行，以检测界面、请求、响应、脚本（即JavaScript）、数据注入、会话、身份验证等问题。除了可以扫描应用程序本身之外，还可以扫描发现第三方开源组件、第三方框架的漏洞。

（14）WAF

WAF即Web应用防火墙（Web Application Firewall），是通过执行一系列针对HTTP和HTTPS的安全策略，来专门对 Web应用，提供保护的一类产品。WAF初期是基于规则防护的防护设备；基于规则的防护，可以提供各种Web应用的安全规则，WAF生产商去维护这个规则库，并实时为其更新，用户按照这些规则，可以对应用进行全方面的保护。

（15）IDS/IPS

入 侵 检 测 系 统（instruction detection system，IDS）、 入 侵 防 御 系 统（ instruction prevention system，IPS）是两类传统的安全保障产品，主要用于应对网络安全系统中的黑客攻击事件。IDS是依照一定的安全策略，对网络、系统的运行状况进行监视，尽可能发现各种攻击企图、攻击行为或者攻击结果，以保证网络系统资源的机密性、完整性和可用性。IPS能够监视网络或网络设备的网络资料传输行为，能够即时的中断、调整或隔离一些不正常或是具有伤害性的网络行为。

本文作者：小白成长中

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/168897.html