IAST/RASP调研与实践：日活5000Agent的IAST落地全流程

背景

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

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

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

落地流程

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

试点部署 (2021年12月-2022年1月)

在试点部署阶段，笔者以 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 。

完善功能(2022年2月-2022年4月)

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降级方案压测结果

流程自动化(2022年5月-2022年6月)

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

嵌入CI-CD流程

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

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

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

图4-IAST接入流程图

接入 CI-CD 流程时需要注意以下3点：

嵌入漏洞运营流程

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

图5-IAST漏洞运营流程图

灰度部署(2022年7月-2022年9月)

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

笔者在运营过程中发现 SQL 注入和命令执行这两条规则精确度较高，可优先开启这两条规则。

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

图6-IAST异常case处理流程

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

总结和规划

经过近一年的工作，IAS T在58集团的落地流程也取得了一些结果，目前日活 Agent 数量在5000 左右，也检测出来近百个高危漏洞。这些高危漏洞都是之前的安全能力无法发现的，给SAST 等其他产品提供了召回手段。接下来，简单总结落地流程中的注意事项和近期规划。

总结

规划

洞态IAST产品优化

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

Agent模块

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

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

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

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

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

  
  

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

迭代版本

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

CI/CD系统集成

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

结束

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

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