DevSecOps一词最早由Gartner在2012年提出,并从2017年开始逐渐成为热门词汇。DevSecOps可以理解为将安全性融入到DevOps的过程中,在整个开发和运维的过程中将安全作为一项重要的考虑因素,最终实现应用整个生命周期内的安全性。利用DevSecOps实现安全自动化可以在提高研发运维效率的同时增强应用的安全性。

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

DevSecOps 安全工具金字塔

DevSecOps 安全工具金字塔描述了一组层次结构,金字塔底部的工具是基础工具,随着组织 DevSecOps 实践成熟度的提高,组织可能会希望使用金字塔中较高的一些更先进的方法。

金字塔中的安全工具分层与组织的 DevSecOps 成熟度分级没有直接关系,仅使用低层次的安全工具也可以完成高等级的 DevSecOps 实践成熟度,反之亦然。金字塔中的工具分层与该工具的普适性、侵入性、易用性等因素相关。普适性强、侵入性低、易用性高的安全工具更适合作为底层基础优先引入,普适性弱、侵入性高、易用性低的工具则适合作为进阶工具帮助 DevSecOps 实践变得更加完善且深入。

CARTA 平台

CARTA(Continuous Adaptive Risk and Trust Assessment,持续自适应风险与信任评估)由 Gartner 在 2018 年十大安全技术趋势中首次提出,在 2019 年再次被列入十大安全项目,也是 Gartner 主推的一种应对当前及未来安全趋势先进战略方法。CARTA 强调对风险和信任的评估分析,这个分析的过程就是一个权衡的过程,告别传统安全门式允许 / 阻断的处置方式,旨在通过动态智能分析来评估用户行为,放弃追求完美的安全,不能要求零风险,不要求 100% 信任,寻求一种 0 和 1 之间的风险与信任的平衡。CARTA 战略是一个庞大的体系, 其包括大数据、AI、机器学习、自动化、行为分析、威胁检测、安全防护、安全评估等方面,集主流技术与一体打造出一个自适应自判断安全防护平台。

CARTA 跟 DevSecOps 的趋势一致,将安全左移至开发阶段,并最终集成在整个生命周期中,完成敏捷化的自适应风险和信任评估。因此 CARTA 已逐渐从单纯的生产环境实践方法,融合进 DevSecOps 的体系之中。

应用安全性测试即服务(ASTaaS)

随着应用开发环境的开放化以及云服务日趋成熟,更轻量级的 ASTaaS 逐渐开始被接受。在 ASTaaS 上,使用者通常仅需按需付费来对应用程序执行安全测试,而不必再分别购买昂贵的私有化安全设备。该服务通常是静态和动态分析,渗透测试,应用程序编程接口(API)测试,风险评估等安全功能的组合。ASTaaS 通常用于移动和 Web 应用程序。

ASTaaS 的发展动力主要来自云应用程序的使用,在云应用程序中,用于测试的资源更易于配置。有数据表明, 全球在公共云计算上的支出预计将从 2015 年的 670 亿美元增加到 2020 年的 1620 亿美元。

应用安全测试编排(ASTO)

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

模糊测试

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

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

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

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

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

容器安全

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

  • 保护容器管道和应用

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

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

运行时应用自保护(RASP)

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

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

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

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

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

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

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

软件组成分析(SCA)

SCA 工具检查软件,以确定软件中所有组件和库的来源。SCA 工具在识别和发现常见和流行组件(尤其是开源组件)中的漏洞方面非常有效。但是,它们通常不会检测内部自定义开发组件的漏洞。

SCA 工具在查找通用和流行的库和组件(尤其是开放源代码部分)方面最为有效。它们的工作原理是将代码中的已知模块与已知漏洞库进行比较。SCA 工具查找具有已知漏洞并已记录漏洞的组件,并且通常会提示使用者组件是否过时或有可用的补丁修补程序。

为了进行比较,几乎所有 SCA 工具都使用 NVVD 或 CVE 作为已知漏洞的来源。许多商业 SCA 产品还使用VulnDB 等商业漏洞数据库作为来源。SCA 工具可以在源代码,字节码,二进制编码或某种组合上运行。在知识产权保护的影响下,基于不同软件授权许可证书的风险检测,正成为新的技术关注点。SCA 可以对不同软件组件的授权许可进行分析,避免潜在的法律风险。

交互式应用安全测试(IAST)

IAST 曾被 Gartner 多次列为十大安全技术。IAST 工具结合了 SAST 和 DAST 技术的优点。IAST 可以模拟验证代码中的已知漏洞是否可以真的在运行的环境中被利用。

IAST 工具利用对应用程序流和数据流的了解来创建高级攻击方案,并递归地使用动态分析结果:在执行动态扫描时,该工具将基于应用程序对测试用例的响应方式来了解有关应用程序的知识。一些工具将使用这些知识来创建其他测试用例,然后可以为更多的测试用例产生更多的知识,依此类推。IAST 工具擅于减少误报数, 并且可以很完美地使用在敏捷和 DevOps 环境。在这些环境中,传统的独立 DAST 和 SAST 工具在开发周期中可能会占用大量时间,而 IAST 几乎不会对原有应用生产效率产生任何影响。

PTE 自动化渗透测试

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

EDR

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

静态应用安全测试(SAST)

SAST 又称白盒测试,测试人员可以在其中了解有关被测代码的信息,包括体系结构图、常规漏洞、不安全编码等内容。SAST 工具可以发现源代码中可能导致安全漏洞的脆弱点,还可以通过 IDE 插件形式与集成开发环境结合,实时检测代码漏洞问题,漏洞发现更及时,使得修复成本更低。

源代码分析器可以在未编译的代码上运行,以检查缺陷,覆盖赋值越界、输入验证、竞争条件、路径遍历、指针和引用等。部分 SAST 工具也可以用二进制和字节码分析器对已构建和已编译的代码执行相同的操作,但这实际上已进入 SCA 和 DAST 的范畴。

移动应用安全测试(MAST)

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

动态应用安全测试(DAST)

DAST 工具又称黑盒测试,与SAST 工具相对应。测试人员无需具备编程能力,无需了解应用程序的内部逻辑结构, 也无须了解代码细节。DAST 不区分测试对象的实现语言,采用攻击特征库来做漏洞发现与验证。

DAST 工具针对编译后的可执行程序运行,以检测界面、请求、响应、脚本(即 JavaScript)、数据注入、会话、身份验证等问题。除了可以扫描应用程序本身之外,还可以扫描发现第三方开源组件、第三方框架的漏洞。

WAF

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

在这几年 WAF 领域出现了很多新的技术,譬如通过数据建模学习企业自身业务,从而阻拦与其业务特征不匹配的请求;或者使用智能语音分析引擎,从语音本质去了解。除可阻断针对利用已知漏洞的攻击外,还可防止部分通过未知漏洞的攻击。

IDS/IPS

入侵检测系统(instruction detection system,IDS)、 入侵防御系统( instruction prevention system, IPS)是两类传统的安全保障产品,主要用于应对网络安全系统中的黑客攻击事件。

IDS 是依照一定的安全策略,对网络、系统的运行状况进行监视,尽可能发现各种攻击企图、攻击行为或者攻击结果,以保证网络系统资源的机密性、完整性和可用性。

IPS 能够监视网络或网络设备的网络资料传输行为,能够即时的中断、调整或隔离一些不正常或是具有伤害性的网络行为。

由于这两种产品的技术和形态有高度的一致性,因此这里放到同一个分类中阐述。IPS 和IDS 工具已经非常成熟, 甚至可以称为古老。但由于其拥有实时检测和响应的特点,在生产系统中有着高度的实用性,因此现如今依旧是在线应用的网络保护中十分必要的一环。

受篇幅所限,金字塔中无法罗列所有的工具。威胁建模、漏洞关联分析、测试覆盖率分析、自动化漏洞修复等工具都有较强的技术创新性且未来的应用前景十分广阔,但目前的产品成熟度和市场需求度上还处于相对早期阶段,因此暂未编排进金字塔中。

金字塔中的内容并非一成不变,随着 DevSecOps 实践的发展,我们可能会增加新的安全工具到金字塔中,或删除一些被边缘化的安全工具,亦或调整对某个安全工具的评价和运行阶段。在某个工具的实际使用工况发生改变时,它所处的层次也可能会变更。我们会持续关注 DevSecOps 中安全工具的应用情况。

非安全工具的 DevSecOps 融合现状

DevSecOps 流程的工具非常繁杂,且许多工具都与安全风险管控过程相关,本节将叙述与 DevSecOps 流程结合较为紧密的非安全类工具的实践现状,鉴于篇幅有限,仅选取比较有代表性的三类工具进行阐述。

1、DevOps 管理平台

在 2020 年,我们看到了 DevOps 管理平台向 DevSecOps 管理平台转化上的长足进步。在过去几年间,国内不同的 DevOps 管理平台已在开发和运维流程的管理能力上逐渐地完善,并趋于同质化。2020 年,安全管理成为领先的 DevOps 平台厂商着手解决的问题,如腾讯蓝鲸、Coding、阿里云效、博云、平安神兵等 DevOps 管理平台都完成了向DevSecOps 的初步探索。常规的做法是,第三方DevSecOps 安全工具以插件或独立模块的方式集成在 DevOps 管理平台中,DevOps 管理平台在自身的流水线中调用这些安全工具,并将安全结果与质量红线进行关联,作为版本质量的参考依据。

DevOps 平台的安全流水线

目前 DevSecOps 探索尚处于起步阶段,无论是安全能力的丰富程度,还是安全与整体流程的融合程度都有待进一步地完善,但今年 DevOps 管理平台对DevSecOps 探索的显著进步,使我们非常期待其在 2021 年的表现。

2、持续集成工具

当前,持续集成(CI)工具对 DevSecOps 而言,是自动化和敏捷化的核心支撑工具。因此持续集成工具对安全自动化的支持成熟度在很大程度上决定了 DevSecOps 实践成熟度。今年,Jenkins 依旧是用户最认可的 CI 工具,达到了 53% 的市占率,因此对 Jenkins 的支持已经成为了 DevSecOps 安全产品的基础能力。假如一款安全产品没有与 Jenkins 流水线进行集成编排的能力,我们很难说这是一款真正的 DevSecOps 安全产品。

Jenkin 中自动化安全任务的执行结果

Gitlab CI、Bamboo、Travis CI 等工具由于用户的基数有限,DevSecOps 安全产品还较少对其流水线进行支持, 相信随着 DevSecOps 的发展,以上工具也会更多地被纳入安全产品支持的范围中来。

3、需求和项目管理平台

需求和项目管理平台作为软件项目开发不可或缺的支撑工具,从单纯对需求与缺陷的管理,发展到与安全流程的结合,这似乎是个必然的趋势。这种对安全的管理方式更多地偏向流程保障,而欠缺敏捷性,因此严格来说, 这更像是S-SDLC,而不是 DevSecOps。出于以下两点原因,这里还是把需求和项目管理平台纳入进来叙述。

  1. 越来越多用户希望将 DevSecOps 安全支撑工具的输出结果同步到需求和项目管理平台上,以方便在项目的维度上进行整体管控。

  2. 需求和项目管理平台的自动化能力正在不断成长,以求更加适应敏捷模式。

根据云计算开源产业联盟今年发布的《中国 DevOps 现状调查报告》,在需求和项目管理平台方面,Jira 以44% 的使用率依旧占据统治地位,因此 Jira 平台是本年度观察的重点。我们看到头部的安全工具已经能够与Jira 平台融合,帮助用户使用 Jira 的项目管理流程,完成安全的流程化管理。

在 JIRA 中引入安全漏洞管理

除Jira 之外,禅道、Ones Project、Redmine、Trello 等工具在需求与项目管理平台领域中也有一定的市场占有率。但出于用户需求、平台开放性以及安全厂商支撑意愿等因素,这些平台在安全能力的结合方面尚在起步阶段, 成熟的案例比较有限。

本文摘自《2020 DevSecOps行业洞察报告》。

声明:本文来自互联网安全内参,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。