IAST/RASP调研与实践：IAST落地全流程

经过⻓时间的建设，58 集团落地了包括 SAST、 DAST 和 SCA 等安全能⼒在内的应⽤安全体系。

但是，上述能⼒各有其局限性，例如 SAST 在源码层⾯进⾏安全检测，覆盖⾯相对较⼴，但由于 58 的SAST 是基于抽象语法树(AST)进⾏⾃动化代码审计，未覆盖应⽤间接引⽤包中的 Sink 点（若覆盖该情形，会出现路径爆炸等问题，对性能要求较⾼）。⽽DAST需要发送⼤量 Payload，不仅增加业务机器负载，还会引⼊⼤量脏数据。

洞态 IAST 刚好可以解决上述问题，它使⽤应⽤程序运⾏时数据流进⾏分析，⾃然覆盖了应⽤间接引⽤包中的 Sink 点；且完全依赖测试⼈员触发的请求，在服务端对该请求触发的⽅法调⽤链路进⾏分析，不会产⽣脏数据。

本节会按照时间线梳理洞态 IAST 在58集团的落地流程，以及每个流程中的关键点和注意事项。

在试点部署阶段，笔者以 Docker 的⽅式部署了 IAST 服务，并相继接⼊了简单的 Spring Web ⼯程、采⽤⾃研 Web 框架的靶场和某个业务线的数个边缘业务(均为Java应⽤)。

1. 接⼊Spring-Web ⼯程的⽬的是验证 IAST 流程是否跑通，agent端和server端⽹络通信是否正常等常⻅的环境问题。

2. 接⼊⾃研 Web 框架的靶场的⽬的是检验 IAST 的漏洞检测能⼒，它能检测出靶场的⼤部分漏洞。接⼊靶场的时候出现了⼩插曲，由于靶场⾸⻚前端是根据漏洞类型动态⽣成的，⽽靶场共有上万个漏洞，接⼊ IAST 后机器的 CPU 使⽤率飙升到 100%。经过研发排查发现在⽣成靶场⾸⻚时，短时间命中⼤量 IAST Hook的⽅法，占⽤了⼤量 CPU。把相应的 hook 规则( java.util.List.get(int),java.util.Map.get(int) )下掉后，靶场就能正常访问了，后续安全团队在设计 IAST 的降级策略时也考虑了该场景。

3. 接⼊具体业务的⽬的是模拟 IAST 正常上线后的场景。同样，在靶场出现的 CPU 暴涨的情况也出现在了业务机器上，笔者也愈发觉得设计、研发容灾降级功能迫在眉睫，只有开发了完善的降级策略，才能开启 IAST 的建设流程。

TIPS: 在业务线上试点部署时，要选择相对重视安全的业务部⻔，并尽量不要给业务的研发或测试带来额外的⼯作量。由于现阶段 IAST 还需要⼿动部署，笔者也是写了 Shell 脚本，该脚本中⽤ Attach的⽅式接⼊ Agent。业务测试在应⽤启动之后、测试开始之前，在机器上运⾏该脚本就会⾃动接⼊ IAST 。

58安全团队计划于测试环境部署洞态 IAST，由于测试服务也具有稳定性要求，安全产品的部署需优先保证业务⽅服务的可⽤性及稳定性。因⽽部署前需要先⾏设计监控降级⽅案，以防部署后对业务造成困扰。

在开发容灾降级功能阶段，研发⼈员针对可能导致业务服务不可⽤及不稳定的情况设计并开发了该功能，主要包括监控模块和降级模块。

监控模块

1. 性能监控，监控 CPU 使⽤率、内存使⽤率、垃圾回收次数、线程数量等。

2. 访问请求监控，监控业务的请求流量。

3. 数据收集监控，监控 Hook ⽅法次数和 Hook 耗时。

4. 服务端指令监控，监控服务端下发指令，指令包括卸载核⼼引擎、开关核⼼引擎、开关降级熔断功能。

降级模块

降级模块依赖于上述监控模块提供的数据，且熔断降级分为两步，降级是指在发⽣某些对业务应⽤会有影响的状况发⽣时，通过熔断 Agent 的功能来优先保障业务的正常使⽤；卸载是在降级策略持续⼀段时间后的⼆次降级(兜底)策略，即卸载核⼼引擎服务。

1. 性能降级，单性能指标超过危险阈值和多性能指标超过⻛险阈值均会触发降级。

2. 访问请求和数据收集降级，⾼频访问请求(例如压测环境)和单请求触发⼤量已hook的规则均会触发熔断降级。

3. 熔断异常降级，⻓时间反复处于降级状态和正常状态，触发卸载策略。

4. 服务端下发指令控制agent端熔断、降级、卸载。

TIPS: 图1 是最初监控降级功能的雏形，后续洞态团队⼜进⼀步开发了该功能。

图1-IAST降级方案设计图

图2 是开启降级配置后的压测结果，开启后应⽤性能接近于agent插桩前的应⽤效果，相⽐于市⾯同类型IAST产品性能提升显著。

图2-IAST降级方案压测结果

在流程⾃动化阶段，主要解决了两个问题，分别是如何在业务发布应⽤时⾃动接⼊ IAST，以及怎样把IAST 检出漏洞纳⼊到58原有的漏洞运营流程。

嵌⼊CI-CD流程

58 集团对IAST的定位是在测试阶段检测安全⻛险的安全能⼒(如图3 所示)。

图3-58应用安全能力(部分)

安全团队和负责 CI-CD 流程的团队合作，在研发或测试⼈员部署业务应⽤到机器时，⾃动接⼊ IAST，如图 4 所示。

图4-IAST接入流程图

接⼊ CI-CD 流程时需要注意以下三点：

1. 明确 IAST 只覆盖测试环境，保证不会影响线上应⽤。

2. 设置两个开关。开关⼀由研发、测试或业务部⻔负责⼈控制，可供业务⾃主选择是否接⼊IAST；开关⼆(⿊⽩灰名单机制)由安全团队控制，可以决定哪些业务可接⼊ IAST，以及 Agent 的版本等等(主要⽤于灰度部署、问题排查和 Agent 版本迭代时)。两个开关均为开时，才会接⼊ IAST。

3. 选择合适的打 Agent 的⽅式。Attach ⽅式适⽤于应⽤运⾏后，可⾃主选择接⼊的时间，但字节码增强时会导致业务短时间不可⽤，且有可能会丢失测试流量。Premain ⽅式适⽤于应⽤还未运⾏时，需要修改应⽤的启动命令，侵⼊性较强，但可以获取测试流程的所有流量。

嵌⼊漏洞运营流程

安全团队设计了⼀套漏洞运营流程，将 IAST 检出的漏洞收敛到应⽤安全的漏洞治理体系中。该流程依赖洞态的 Webhook 转发机制，通过运营服务应⽤完成⾃动忽略历史标记为误报的漏洞、安全运营⼈员对漏洞打标和将漏洞同步到SDL平台等流程，具体流程如图 5 所示：

图5-IAST漏洞运营流程图

经过上述步骤，功能开发完毕，流程也相继跑通。接下来就是和业务线沟通，开始紧锣密⿎的全量部署进程。⼀阶段，先以⽩名单的⽅式接⼊部分应⽤，验证IAST各项功能和流程。⼆阶段，灰度接⼊全量业务。简单分享 5 点⼆阶段的注意事项。

1、明确 IAST 是安全辅助测试⼈员发现安全⻛险的产品，尽量联合测试部⻔⼀起推动灰度部署。

2、确定灰度进度。刚开始打算按照分别为2%, 5%, 10%, 20%, 50%, 100%的业务数量，每周递增进⾏灰度。在部署过程中，随着数量的提升，发现数据库容量不够、消息积压等问题，最终灰度进度为2%, 5%, 10%, 20%, 40%, 60%, 80%, 100%。

3、确定优先接⼊的业务。58 采取了两个策略：业务部⻔⾃主选择优先接⼊的应⽤；按照历史漏洞的数量，漏洞较多的应⽤优先接⼊。

4、及时响应灰度过程中遇⻅的问题。业务场景是极其复杂的，在部署过程中难免会遇到兼容性、和其他 Agent 冲突等问题，⼀定要尽快处理这类问题，优先保障测试⼈员的测试进度不受影响。

5、仅开启少量 IAST 的规则。由于业务基数⽐较⼤，少量误报率较⾼的规则导致漏洞运营成本剧增。笔者在运营过程中发现 SQL 注⼊和命令执⾏这两条规则精确度较⾼，可优先开启这两条规则。

对于灰度过程中遇到的问题，安全⼈员按照图6 所示流程进⾏处理。

图6-IAST异常case处理流程

另附两个部署过程中遇到的典型问题。

• 业务应⽤启动时，IAST 和其他 Agent 冲突(例如Skywalking), 产⽣死锁。由于 IAST 的 Agent采⽤异步增强的⽅式，增强⾃节码的逻辑在 Core 包中运⾏，如果配置延迟启动核⼼引擎，可能会偶发两个 Agent 同时增强某个类导致死锁。可采⽤attach的⽅式，或者调整 IAST 的agent启动顺序在后。

  
  

• 业务应⽤启动到⼀半，应⽤Java进程中⽌。低版本Jdk的Bug，导致Jvm动态编译优化的C2CompilerThread 线程崩溃。升级版本到jdk8u144-b31及以上版本解决。

经过近⼀年的⼯作，洞态IAST在58集团的落地流程也取得了⼀些结果，⽬前⽇活 Agent 数量在5000 左右，也检测出来近百个⾼危漏洞。这些⾼危漏洞都是之前的安全能⼒⽆法发现的，给SAST 等其他产品提供了召回⼿段。接下来，简单总结落地流程中的注意事项和近期规划。

• IAST采⽤字节码增强技术，对业务的侵⼊性较强，在部署时务必充分测试，制定完善的回退策略，优先保障业务正常研发、测试流程的进⾏。

• IAST需要包括安全团队、负责CI-CD的团队和业务团队等多个部⻔合作推动进⾏部署，在部署过程中需要多沟通，保证部署进度按计划完成，也确保业务团队了解IAST运作的基本流程和 Agent 对业务应⽤的侵⼊性，出现问题能及时定位。

• 58内部使⽤了⾃研的 RPC 框架，安全团队也基本完成了 Agent 在⾃研 RPC 框架上的适配，接下来会继续深耕跨应⽤的漏洞检测功能。

• 业务团队反馈，由于 DAST 会带来⼤量脏数据，所以测试环境对 DAST 容忍度较低。因此，58安全团队会进⼀步推动 IAST 和 DAST 的联动，由 IAST 在测试环境跟踪 DAST 的请求，拦截可能触发写数据的⽅法，并将请求触发的⽅法调⽤链路，反馈给DAST。DAST 进⼀步利⽤⽅法调⽤链路进⾏漏洞检测。

在58集团推进IAST落地过程中，洞态IAST团队与其保持积极沟通，结合58集团遇到的上述问题，洞态团队在产品上做了相应的以下设计和优化：

在Agent方面，洞态IAST拥有”重”server “轻”agent的架构模式，并且采用分级延时加载的模式，主要是为了避免一些业务可能没有启动完毕但agent已经加载而导致的影响业务的问题。自定义延时加载可以应对很多复杂的场景，提升IAST的高可用性。

洞态IAST开源这一年多的时间里，团队接触了社区提供的各种各样的使用场景，用户始终很关心IAST的使用是否会影响业务。为消除用户的这个顾虑，确保业务百分百优先，洞态IAST团队分别从三个维度设计了熔断降级模块，分别为：

• 性能指标：系统内存使用率、系统内存使用值、CPU使用率

• JVM指标：JVM内存使用率、JVM内存使用值、总线程数、守护线程数、洞态IAST线程数

• 应用指标：单请求HOOK限流、每秒限制处理请求数量(QPS)、请求响应时间

  
  

从这三个维度保障业务优先，防止Agent影响业务的运行。同时在达到这个指标以后IAST也可以配置完全卸载，针对一些敏感的业务可以选择此项，针对一些不敏感的业务可以选择恢复后启动，这样更加快捷。经过大量的上千上万Agent的部署案例，证明了洞态Agent的稳定性是经得起考验的。

洞态IAST具有版本管理的模块，在内部迭代版本的时候各个版本相互隔离，用于版本迭代或者灰度测试等场景，验收研发漏洞修复的成果。

在对接CI/CD平台方面，洞态IAST商业版采用了开箱即用的模式，摒弃“配置地狱”模式，直接填写账号密码就可以使用，针对常见的Jenkins、Jira、Gitlab等集成平台都是很好地适配对接。

下图是58集团IAST落地全过程的PDF版本资料的申请二维码，记录了他们在内部落地洞态IAST所遇到的一些问题以及最终如何把IAST成功部署上线并推广。

如果你有兴趣阅读资料，进一步学习IAST落地方案或是想试用洞态IAST商业版产品，都可以扫描下边图片中的二维码，进行免费申请。