DevSecOps安全工具链介绍

一、概述

本文将重点介绍安全工具链子系统和周边生态子系统。通过这些内容的介绍，为大家打下DevSecOps平台技术框架的基础，为后续章节的安全专项能力与DevOps融合做前提铺垫。

安全工具链是指企业安全建设者站在整个软件开发生命周期的角度，去选择不同的安全工具在软件研发过程不同阶段解决安全风险，从而实现平台级的安全自动化。周边生态系统是指除了安全工具之外，在软件开发生命周期或DevOps流程中还涉及其他的系统，如项目管理、组件仓库和镜像仓库等，这些典型的周边生态系统都会影响到安全工具链的建设与实施方案。

二、安全工具链在平台中的定位

2.1 概述

建设DevSecOps平台的目标之一就是降低线上安全漏洞的数量和修复成本，围绕这一目标，其核心是构建和利用好各种自动化安全漏洞检测工具，并将其与CI/CD流水线进行自动化集成，在不影响研发效率的同时，确保安全漏洞能够及时、准确地发现。

作为建设者，需要根据工具的特性和所适合嵌入的研发阶段，对安全工具进行分类，以明确安全工具在整个平台中的定位，构建安全发现能力的纵深，让各种安全工具各司其职，最终形成完整的安全工具链。

2.2 分层定位

2.2.1 不同阶段的安全工具

在DevSecOps中，安全左移的表现形式是将安全工作前置到目标规划、需求分析、软件设计、编码开发、构建部署等阶段，并由CI/CD平台推动整个开发和运营流程自动化，在不同阶段采用不同的安全工具。

下图列举了各阶段的一些典型安全工具，这些安全工具主要特点是高度自动化及可集成性。

从上图中可以看到，在软件开发生命周期的不同阶段都对应了不同的安全工具及工具的自动化程度，在某个阶段的自动化程度越高就越适合在该阶段做工具集成。

例如，SAST（静态安全检测）和SCA（软件成分分析）适合在开发和构建阶段集成至CI/CD流水线，而DAST（动态安全检测）和IAST（交互式安全检测）适合在测试阶段集成至CI/CD流水线。最终在DevSecOps模式下，安全工具链覆盖软件开发生命周期的所有阶段。

2.2.2 安全工具金字塔

除上述基本安全工具外，有时还需要一些更前瞻性的安全工具，这些安全能力层次分明、相互作用、能力叠加、共同协作来保障应用安全。在《2020 DevSecOps行业洞察报告》中，首次提出了安全工具金字塔概念，如下图所示：

《2020 DevSecOps行业洞察报告》参考地址：

《2020 DevSecOps行业洞察报告》正式发布了 - FreeBuf网络安全行业门户

该金字塔涵盖了传统建设层、应用实践层和卓越层，并从技术前瞻性、落地难度和市场普及时间三个维度思考未来DevSecOps演进的工具链，目前已发展到2.0版本。

图中从安全的角度，自下而上地显示了不同阶段、不同层次的安全检测工具。报告中指出，工具的分层与该工具的普适性、侵入性和易用性相关，一般认为普适性强、侵入性低、易用性高的工具适合金字塔底层并优先集成，相反普适性弱、侵入性高、易用性低的工具更适合在不断的实践深化过程中逐渐引入。此外，报告中还指出，金字塔中的安全工具分层与DevSecOps成熟度分级没有直接关系，仅使用低层次的安全工具也可以完成高等级的DevSecOps实践成熟度。

2.3 安全流水线集成概览

2.3.1 概述

在安全自动化落地阶段，需要由安全人员去构建这些安全能力，并将安全能力原子化，放到DevSecOps流水线的编排模板中。通常是根据企业的业务形态去构建各个不同的原子化能力，然后将这些能力集成至对应的作业模板。通过安全原子化能力与作业模板编排后的融合，当业务真正去使用的时候，只需在流水线中选择一个模板即可完成安全操作。

2.3.2 标准流水线集成安全工具链概览图

下图展示了一个标准流水线集成安全工具链的概览。

从上图中可以看到，当DevSecOps流水线构建完之后，安全原子化能力可以根据流水线作业模板做不同的编排，例如，代码提交完之后自动触发代码安全检测，构建完之后触发软件成分分析，部署完之后触发安全扫描。当流水线作业模板足够丰富的时候，整个安全自动化工作就逐渐做起来了，这是一个慢慢迭代的过程，一般来说是从研测向运维推进建设，或者研测和运维同时建设，并向中间合拢，最后达成一体化的安全自动化。自动化之后，DevSecOps平台里会出现很多过程数据，如项目管理数据、任务数据、漏洞数据等，基于这些汇总数据，可以持续地去做度量分析和运营改进。

三、安全工具链分类

3.1 概述

在谈安全工具链时，看到最多的就是各种安全检测工具，如SAST、DAST、IAST等。前文已经讨论了这些安全检测工具在DevSecOps平台各阶段的自动化程度和分层定位，同时列举了标准流水线的集成概览，本节将继续探讨这些典型工具的技术原理、优缺点及使用场景。

3.2 威胁建模类

3.2.1 威胁建模的概念

威胁建模(Threat Modeling)是分析应用程序安全性的一种结构化方法，通过识别威胁理解信息系统存在的安全风险，发现系统设计中存在的安全问题，制定风险消减措施，将消减措施落入系统设计中。

3.2.2 威胁建模起到的作用

威胁建模可以在产品设计阶段、架构评审阶段或者产品运行时开展，强迫我们站在攻击者的角度去评估产品的安全性，分析产品中每个组件是否可能被篡改、仿冒，是否可能会造成信息泄露、拒绝攻击等。

3.2.3 威胁建模的流程

3.2.3.1 威胁建模流程图

在微软的软件开发生命周期中，一直将威胁建模当作最核心的一部分，并通过威胁建模消除绝大部分的安全风险。下图展示了微软威胁建模的流程。

从上图图中可以看到，威胁建模包含绘制数据流图、威胁识别与分析、制定消减措施、验证消减措施4个流程。

3.2.3.2 威胁建模流程内容

3.2.3.2.1 绘制数据流图

数据流图一般是根据业务的系统上下文、逻辑架构图、网络边界、服务或组件调用关系，由安全人员与业务方一起绘制。绘制数据流图的过程可以帮助安全人员更好地理解业务、确保安全视角没有遗漏。可以使用一些威胁建模工具绘制数据流图，典型的有微软提供的威胁建模工具Microsoft Threat Modeling Tool和OWASP安全组织提供的OWASP Threat Dragon。

微软微软提供的威胁建模工具官网地址：

Microsoft Threat Modeling Tool 概述 - Azure | Microsoft Learn

OWASP Threat Dragon官网地址：

OWASP Threat Dragon | OWASP Foundation

下图为微软威胁建模工具绘制的某业务数据流图。

数据流图主要由外部实体、处理过程、数据存储、数据流及信任边界组成，在上图的数据流图中，矩形表示外部实体，圆形表示处理过程，中间带标签的两条平行线表示数据存储，带箭头的曲线表示数据流，蓝色虚线表示信任边界。

下图详细列举了构成数据流图的5个部分。

3.2.3.2.2 威胁识别与分析

通过数据流图和信任边界的划分，我们对容易产生威胁的地方也有了一定的理解。要识别威胁，首先需要知道攻击者的目标，明确需要保护的重点资产，如代码、服务器、敏感数据等；其次定义可能的攻击者，如内部员工、竞争对手、外部的攻击团队等，并找出这些潜在的攻击者可能的攻击路径，如利用安全漏洞、弱口令、钓鱼邮件等，可以看到攻击路径的确定会影响到最终的信任边界划分；最后需要对这些识别到的威胁进行分析，剖析可能会出现的具体威胁。

3.2.3.2.2.1 STRIDE威胁分析方法论

STRIDE方法是微软提供的用于威胁分析的方法论，它从攻击者的角度把威胁划分成六个类别，分别是Spooling（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Dos（拒绝服务）和Elevation of Privilege（权限提升），几乎能够覆盖目前绝大部分安全问题。但随着近年来隐私保护的问题越来越严重，隐私安全也成了业务一个重要威胁，因此STRIDE新增了一项Privacy（隐私），演变成现在的ASTRIDE(Advanced STRIDE)。下图列举了ASTRIDE的7类威胁与信息安全三要素、三属性的对应关系。

接下来可以结合数据流图的基本元素，使用ASTRIDE威胁分析方法来对基本元素进行威胁分析，可以得出下图的对应关系。

上表直观地表现了数据流图基本元素会面临哪些类别的威胁。外部实体可以被伪造，如发起中间人攻击、认证信息伪造等；处理过程会面临上述所有的威胁，如业务系统的Web服务面临爬虫攻击、DDOS攻击等；数据存储往往面临数据被篡改、敏感数据泄露等威胁，如数据库被脱库，敏感数据未加密等。对所有元素进行威胁分析后，就会获得该系统的威胁清单，后面就可以依据威胁清单来制定消减措施。

3.2.3.2.3 制定消减措施

3.2.3.2.3.1 消减措施表

可以根据不同的数据流图元素和威胁定义消减措施，当然不同的威胁对应的消减措施一般也不一样。例如，在绘制数据流图小节中的业务数据图中，用户登录Web应用程序这一行为会存在仿冒威胁，消减措施可以是强的身份认证、防止登陆口令暴力破解等，详细方案就是账号、密码、证书认证，增加验证码机制，密码尝试次数限制，账号黑名单机制等。下表列出了ASTRIDE威胁对应的消减措施。

通常在提出消减措施时，要综合考虑业务的实际情况，不能因制定的消减措施导致业务性能、易用性等大打折扣，有时安全和业务之间要做一个平衡，一般有4种应对措施：

• 缓解。采取一定的措施增加攻击时间和攻击成本。
• 解决。彻底消除风险，例如，可以是代码和组件方式实现，或安全认证方案等。
• 转移。将威胁转移至第三方或其他系统，例如，购买第三方安全服务，签订用户协议和免责声明等。
• 接受。接受风险是基于成本和安全的一个综合考量，例如，有的风险受到战争、自然灾害等不可抗力因素限制，出于成本考虑，选择接受此类风险。

实际上也并不是所有的威胁都必须及时修复，例如，有些威胁可能风险不大，但如果消减措施会导致整个架构调整就可以考虑暂时不修复。

3.2.3.2.3.2 DREAD 威胁评级模型

因此需要对威胁进行评级，定义严重程度和优先级，可以使用DREAD威胁评级模型。

DREAD威胁评级模型分别对应5个指标：破坏程度(Damage)、可复现性(Reproducibility)、可利用性(Exploitability)、受影响的用户(Affected users)、可发现性(Discoverability)，下表详细列出了这5个指标的等级划分。

从表中可以看到，这5个指标中每个指标的评级分为高、中、低三等，最终威胁的危险评级由这5个指标的加权平均算出。

DREAD威胁评级模型官网地址：

Advanced Threat Modelling Knowledge Session (owasp.org)

3.2.3.2.4 验证消减措施

在完成威胁建模后，需要回顾整个过程，验证威胁是否已经完成闭环，数据流图表是否符合设计，代码实现是否符合预期设计，是否列举所有威胁，以及威胁是否都采取消减措施。验证过程不是一次性工作，过程中需要和业务经常保持沟通，反复执行整个威胁建模的活动识别安全风险，同时确保每个风险都在及时跟进处理。最后整理所有的威胁建模材料并归档，作为后面业务威胁建模的参考材料。

3.3 静态安全检测类

3.3.1 静态检测原理

3.3.1.1 静态检测原理图

静态应用安全测试(Static Application Security Testing，SAST)是一种在编码阶段对源代码进行安全扫描发现安全漏洞的测试技术，又称为白盒测试。SAST是在软件安全开发生命周期(S-SDLC)较早阶段引入的安全检测工具，合理使用可以在最早阶段发现安全风险，SAST技术的基本原理如下图所示：

3.3.1.2 静态检测技术发展阶段

上图描述了SAST的基本原理，同时也是SAST类产品技术发展的几个阶段：基于正则匹配代码分析、基于AST（Abstract Syntax Tree，抽象语法树）代码分析、基于IR（Intermediate Representation，中间代码）和CFG（Control Flow Graph，控制流图）代码分析、基于CodeQL代码分析。

3.3.1.2.1 基于正则匹配代码分析

根据一些漏洞的特征，通过关键字匹配去发现漏洞，但由于无法预测开发人员的编程习惯，匹配规则难以适配多数场景，导致误报率、漏报率非常高。现在纯基于正则匹配的SAST已经不存在了，只是作为一种辅助分析技术。

3.3.1.2.2 基于AST代码分析

通过词法分析和语法分析，将高级代码语言转化为AST语法树，这样就不需要直接去分析高级语言，转而分析AST语法树，解决了正则匹配关键字的最大问题。基于语法树预置可能造成漏洞的函数，通过算法分析这些漏洞函数的入参是否可控来判断是否存在漏洞，这种算法称为污点分析技术。基于AST代码分析最大难点是无法完整处理AST语法树，因此这类SAST都会面临同样的问题。

3.3.1.2.3 基于IR和CFG代码分析

使用编译器或者解释器将高级语言转换成IR中间代码，IR保存了源代码之间的调用关系、上下文分析等，根据IR可以绘制出CFG，它代表了整个代码的控制流程图，后续漏洞挖掘仍是采用污点分析技术对CFG进行分析，并通过符号执行忽略程序中不可达的代码路径。目前主流的SAST产品大多采用这类技术。

3.3.1.2.4 基于CodeQL代码分析

通过统一多种语言的AST解析器，在执行完并解释后将代码的AST解析结果按照预设好的数据模型存储到CodeDB中，使用QL语言定义污点追踪漏洞模型执行QL查询，进而通过高效的搜索算法对CodeDB的AST元数据进行查询，在代码中搜索出漏洞结果。CodeQL技术可能是未来SAST的方向。

开发人员在编码过程中，采用IDE安全插件的方式进行本地源代码安全扫描，可以快速发现安全漏洞并修复。IDE插件扫描的原理就是污点跟踪技术，下图展示了集成IDE插件后发现安全漏洞的示例。

从上图中可以看到，编写存在漏洞的代码时，IDE就会产生告警，在可以查看告警内容的同时，插件也提供了修复方案，单击就可以完成漏洞修复，速度非常快。

IDE集成安全插件虽然很重要，但强迫开发人员使用特定的插件非常困难（实际上几乎是不可能的），更不用说强迫他们使用特定的IDE。因此在IDE中使用安全插件并不是唯一的方案，在DevSecOps平台中还可以将SAST作为CI/CD流水线的一部分。这样，可以确保即使开发人员未在IDE中使用安全插件，在构建运行过程中，仍然会进行安全扫描。

3.3.2 SAST产品列举与横向对比

下表列举了Fortify、Chechmarx、奇安信代码卫士、SonarQube（开源版）、腾讯云代码分析（开源版）等5款典型SAST产品的横向对比分析，在不考虑检测规则优化的情况下，结果如下。

3.3.3 总结

SAST通过分析应用程序的源代码来发现安全漏洞，它的优点是支持多种语言和架构，对漏洞类型的覆盖率较高。但从上表中可以看出，SAST的使用还是有一定门槛的，尤其是在静态检测规则的优化方面，默认规则无法完全匹配业务代码解决误报率和漏报率问题。

一般商业级的SAST工具默认情况下误报率普遍在30%以上，这将导致在DevSecOps落地时需要花费更多精力在规则优化和消除误报上。

另外，传统的SAST扫描耗时较长，尤其是对于大型的代码仓库，往往需花费数小时甚至数天才能完成，这不符合DevOps的研发效能理念，需要结合DevSecOps平台架构和安全流程去考虑并发设计和异步设计。

3.4 动态安全检测类

3.4.1 DAST基本原理

3.4.1.1 动态检测原理图

动态应用安全测试(Dynamic Application Security Testing，DAST)是一种在应用运行时模拟恶意攻击者发起自动攻击，并根据应用的具体反应确定该应用是否存在漏洞的技术，又称为黑盒测试。DAST技术的基本原理如图所示：

在上图中，DAST首先通过爬虫探测整个被测系统的结构，遍历Web的目录层级，页面信息、参数等，用户配置完目标URL后，开始模拟Web用户单机链接操作爬取应用程序；接着对爬取的信息进行分析，并发起攻击尝试，即数据重放，如在请求的表单中添加攻击特征数据；最后DAST会分析这些来自业务系统的返回，根据返回结果判定是否存在漏洞。

可以看出使用DAST这种测试方法，操作人员不需要了解应用的内部逻辑、业务的实现方式，甚至无需具备编程能力，其完全站在攻击者的视角，采用攻击特征库验证并发现漏洞，误报率低。同时DAST的这种高度自动化的测试方法也非常容易集成至CI/CD流水线。

3.4.2 DAST的缺点

DAST的优点很多，但缺点同样明显，主要缺点集中在以下几个方面：

3.4.2.1 覆盖范围有限

严重依赖爬虫获取到的信息，如果爬虫遍历不全或不准确，会影响最终的扫描结果，导致漏报。例如，AJAX页面、动态JS拼接的链接、输入手机号或短信认证页面等，这些传统的爬虫都无法或难以应对。

3.4.2.2 限定HTTP/S测试对象

DAST的测试对象为HTTP/S的Web应用，对于其他应用无法进行安全测试，例如，iOS/Android上的客户端应用无法进行安全测试。

3.4.2.3 无法定位漏洞代码

DAST发现漏洞后会定位漏洞的URL，无法定位产生漏洞的代码位置及产生漏洞的原因，因此需要业务去进一步分析，通常需要花费较长的时间来进行漏洞定位和修复。

3.4.2.4 产生脏数据

DAST必须发送攻击特征数据来进行探测，会产生大量的安全测试脏数据，污染业务测试的数据，因此会对功能测试造成一定的影响，在安全测试过程中需要和功能测试人员保持沟通和协调。

3.4.2.5 特定场景不支持

不支持的场景主要表现在业务逻辑漏洞、某些无回显漏洞，接口经过加密和认证，大量验证码等场景。

3.4.3 总结

针对上述缺点，一些安全厂商经过不断地验证迭代，目前有的DAST工具可以避免以上若干缺点。即便如此，优秀的DAST产品检出率也只有30%，但DAST误报率极低，使用简单，因此仍然是业界安全测试非常普遍的一种方案。

3.5 交互式安全检测类

3.5.1 IAST基本原理

3.5.1.1 主动式IAST

交互式应用安全测试(Interactive Application Security Testing，IAST)是最近几年比较流行的应用安全测试技术，曾多次被Gartner列为安全领域的Top 10技术之一，又称为灰盒测试。IAST理念是让开发人员和测试人员在执行功能测试的同时，无感知地完成安全测试，极大提高安全测试效率。

IAST实现的方式主要有主动式和被动式两种模式。

3.5.1.1.1 主动式IAST基本原理

下图为主动式IAST的原理：

从上图中可以看到，功能测试人员在浏览器或者移动端设置代理，接着发起功能测试，测试流量经过代理，代理将流量复制一份，添加攻击特征数据，IAST扫描器利用改造后的流量对被测业务系统发起安全测试，根据返回的数据包判断是否存在漏洞，后续的操作和DAST的原理一样，这里不再赘述。这种代理模式的IAST不依赖爬虫，解决了DAST覆盖范围有限的问题，此外测试对象无论是基于HTTP/HTTPS的应用，还是基于iOS/Android上的客户端应用，主动式IAST都支持检测。

3.5.1.1.2 被动式IAST基本原理

下面重点介绍被动式IAST，它是一种基于插桩(Instrumented)模式的IAST，插桩模式的核心是在被测业务系统中部署Agent，使用动态Hook和污点跟踪算法挖掘漏洞。

可以看到被动式IAST检测漏洞的底层逻辑和SAST一样，都是基于控制流和污点跟踪技术判断漏洞，最大的区别是被动式IAST省去了构建AST/IR这一过程，因为通过插桩，在应用运行时已经可以绘制出控制流图。下图展示了这一过程。

从上图中可以看到，功能测试人员发起的请求到达被测业务系统的时候，IAST Agent可以追踪请求中的参数流动情况。例如，某个请求体其中一个过程是执行SQL查询语句，请求体如下：

IAST首选会将外部输入的参数zhangsan标为污染数据，接下来会一直跟踪这个污染数据，如果污染数据在传递过程中被处理了，如加密、哈希等操作，那么该标记就被解除（图中灰色圆形块），如果一直到执行SQL查询语句的时候该参数都未经过处理（图中蓝色圆形块），那么IAST就认为执行SQL语句的时候，来自外部输入的参数不可控，会产生SQL注入漏洞。所以污点分析简单理解就是追踪连接绿色块的过程（图中蓝色块的连接线）。

目前主流的IAST技术基本都采用插桩技术来实现污点跟踪，进而发现漏洞，而DAST需要进行数据重放，根据返回信息确认是否存在漏洞。因此DAST的缺点在IAST中基本都不存在。

3.5.1.1.2.1 IAST探针作用

应用启动前Agent在应用的特定位置插入探针，探针不会影响应用的原有逻辑，探针最主要作用如下：

• 获取流量。探针可以获取所有被测业务系统的请求和响应，等于是替代了DAST的爬虫功能，只要被测业务系统功能测试全面，就可以获取到完整的流量。
• 代码分析，探针会对应用中每一行代码进行静态分析，即SAST技术，因此可以定位产生漏洞的代码位置。
• 控制流跟踪。探针可以在应用运行时，通过Hook的方式记录当前应用的上下文信息，实时分析数据流动过程并回溯调用栈，可以得到特定请求的控制流信息。
• 污点跟踪。基于控制流信息，采用污点跟踪算法，追踪不信任输入数据的流动过程，判定是否存在漏洞。

3.5.2 SAST、DAST和IAST优劣势对比

下表横向对比了SAST、DAST和IAST的优劣势。

从表中可以看出，IAST的优势较明显，它结合了DAST和SAST的优势，但最大的缺点是部署探针的成本和对业务性能的影响，尤其是在复杂场景下可能会引起业务部门的反感。因此IAST只有集成进DevOps或DevSecOps平台，在流水线中完成自动部署，最大限度发挥其安全测试效率才会有意义，最合适的场景是应用上线前的测试阶段。DAST是完全站在攻击者的视角进行资产探测，发现资产暴露面及应用的漏洞，从而保障线上运营环境的安全，最合适的场景是应用运营阶段。而SAST针对的是源码漏洞检测，能够在最早期发现安全问题，最合适的场景是应用的编码和构建阶段。

3.6 运行时应用自我保护类

3.6.1 运行时保护定义

运行时应用自我保护(Runtime Application Self-Protection，RASP)是Gartner在2012年首次提出并将其定义：运行时应用自我保护是一种植入到应用程序内部或其运行时环境的安全技术。它能够控制应用程序的执行流程，并且可以实时检测和阻止攻击行为。

3.6.2 运行时保护基本原理

3.6.2.1 原理描述

通过定义我们发现，RASP其实也是一种插桩和Hook技术，这和上文提到的IAST Agent采用的是同样的技术手段，实际上IAST Agent就是基于RASP的理念去实现的，区别是IAST Agent负责挖掘漏洞，RASP负责拦截攻击行为。

3.6.2.2 原理图

下图展示了Java语言插桩技术的基本原理。

以Java语言为例，JVM提供Instrument机制，运行了Instrumentation代理的Java程序，字节码的加载会经过我们自定义的Agent Transformer，在这里可以过滤出我们关注的类和方法，并对其字节码进行相关的修改，实现Hook埋点，最后重新加载Hook后的字节码文件完成整个插桩过程。Java应用的插桩主要分静态和动态两类，而每一类又可以使用不同的技术实现。

3.6.2.3 Java插桩技术分类及优缺点

从表的对比可以看出，无论是基于JDK动态代理机制，还是基于Cglib+ASM实现的动态字节码生成机制，或者基于Javassist实现的自定义类加载器修改运行期字节码，都没有基于ByteBuddy的字节码转换技术的效果好。

3.6.2.3.1 基于ByteBuddy字节码转换的原理

从上图可以看到，在对感兴趣的方法进行字节码转换后，就可以在before ( )和after ( )方法之间进行Hook埋点，处理插桩相关的业务逻辑。要想进入到Hook点，必须处理Hook相关的逻辑，这样就可以根据上下文和参数来实现对攻击行为的检测和拦截。

例如，SSRF漏洞（服务端请求伪造漏洞）RASP的检测逻辑为遍历每个request请求的用户输入参数，与Hook到的URL比较，如果相同，则用户输入的URL到达了底层网络请求的API，此时再检测URL对应的IP是否是内网地址，如果是，则判定为SSRF攻击，触发拦截机制。

3.6.3 RASP的缺点

RASP的缺点也很明显，一是插桩和Hook机制对应用的耦合较深，会对服务器性能有影响，实际推广难度大；二是方案不通用，需要为不同的语言适配不同的RASP，目前只在Java、PHP和.Net语言中具备成熟的产品；三是部署难度，需要研发配合，在每台服务器的应用上都需要执行RASP插桩命令，增加部署成本。

3.6.4 总结

综上所述，RASP在定位上是应用层自适应的安全解决方案，目标是在不改变应用架构或应用代码的前提下，达到快速检测并阻止攻击的目的。只需要在重点关注的节点进行插桩和Hook，就可以检测到OGNL表达式、会话、请求、SQL语句等信息，如果Hook节点足够充分，可以有效地防御XSS、SSRF、RCE和SQL注入等Web攻击。

好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！