IAST如何能助力甲方DevSecOps落地？

今天的议题主要分三个部分。第一个还是为大家普及一下IAST。因为考虑到关于IAST，市面上有很多的声音，有各种形式的IAST。第二部分会和大家交流下，洞态IAST产品上的特色和产品逻辑。第三部分，是我们一些比较好的落地经验分享。

IAST主要分为主动插桩和被动插桩的方式。其实除了这两类，市面上还会有一种流量型的IAST。

洞态属于被动式插桩IAST，它的检测原理是通过插桩agent拿到里面所有数据的污点数据，所有的函数，它的参数，通过hook的方式把整个代码的调用链串起来。洞态会在内部找到存在有外部污染数据的传入，并且会执行一些危险方法的点，去查找是否会存在风险的调用链路，然后基于后续的判断规则去验证是否存在风险。被动插桩最大的特色是完全没有任何流量的重放， 部署上去之后不需去关心如何处理脏数据，如何去和业务那边处理各种发包的问题。

主动插桩其实也会插桩agent， 在收到流量之后 ，主动插桩只会hook少量的敏感函数。在hook到之后，从外面的发包器发不同的payload过来，通过agent的处理去验证它能否触发一些危险函数来进行漏洞扫描。还有一种流量式的，但现在提的比较少了，基本上是黑盒的逻辑，通过发包器发payload来根据整个回显或者说通过dns log去验证是否存在漏洞。基本上就是黑盒检测扫描器只是套了IAST的壳 。

综上，IAST主要分为三类。

第一类是流量式的，它基本属于黑盒扫描器，只是获取流量的时候有一些代理或者流量镜像的方式。这种IAST产品比较大的问题是由于属于黑盒扫描器，它扫描起来的时候延时是比较大的，会产生大量的脏数据。放在DevOps里面去用的时候，在我们现有的经验来看其实是比较难去落地。当然黑盒有它自己的场景，比如说去扫一个单独的环境其实是可以的。

第二类是主动插桩型的，只是发少量的包就可以完成一个漏洞的验证。但是主动插装和流量式的IAST没有办法覆盖到一些新的漏洞场景，比如，这个包本来就有一些验证码，或者本来就有一些图形验证码，或者做了一些防重放的策略。同样，主动插桩也需要花一些精力解决脏数据的问题。但是主动插桩和流量式的插桩技术实现起来难度相对会比较低。

第三类是被动插桩型的，被动插桩最大问题是agent的实现难度会比较大。它基于污点分析算法的方式去做匹配，不需要重放任何的数据， agent插桩之后不需再去担心是否给测试环境产生脏数据，而且不需要发包 ，整个检测是实时的。

我们过去一年多在很多客户那儿部署了IAST，接触了很多客户，发现其实还是有些问题的，比如，一个客户买了IAST产品，测完之后发现有很多漏洞检测出来，最后验证了下发现是黑盒扫描器扫出来的。其实建议大家把IAST部署到自己的产品里面去，还是要搞清楚目前漏洞是通过什么样的方式检测出来的。因为有时候客户在做poc的时候发现漏洞检测得很好，放到线上之后只想用被动插桩的时候，发现能力和之前的想象得不太一样。

接下来为大家分享一下洞态IAST产品逻辑以及能力。

首先可以看下洞态IAST产品的发展历程。

2021年4月份我们把agent端做了开源，当时开源的时候还比较保守，我们在想是不是服务端可以不开源，只把agent端开源，解决企业内部部署agent时考虑的信任问题。

2021年9月份，我们把agent端、server端、检测引擎、检测规则以及对常见的中高危漏洞的支持规则全部都做了开源，到现在洞态也是全球唯一开源的IAST检测产品。

今年1月份，我们能统计到的当时真正在内部持续使用洞态IAST的甲方企业是200多家。

今年5月份，我们发布了商业版，也开始去做一些商业化的落地。商业版一部分是可以提供企业需要的更深度的一些功能，另外一部分是，我们看到了企业在实施IAST的时候，确实是需要非常多的技术支持，这也是我们发布商业版很重要的原因。

截止今年9月份，洞态IAST部署的甲方企业案例累计超过了800家，包括自如、美团、58、陌陌等中大型的互联网厂商，agent的部署量很多都过千甚至过万级的。

洞态IAST开源之后我们也遇到了一些很有意思的事情。统计了下，有35%的深度用户属于中国以外的地区，也会有国际友人把洞态相关的内容翻译成其他国家的语言在当地做一些宣传，这是我们没有想到的事情。

累计的代码提交数有3000多次，全球有800多个深度用户。

从产品上面来说，社区给我们贡献了很多有价值的点，比如agent启停、agent降级策略、消息通知等等。社区里也会有非常多的用户给我们反馈一些误报和漏报的场景，比如说XXE、SSRF等等。同样社区在去部署IAST的时候，也反馈了非常多的最佳实践。

洞态IAST有一个特点，它其实不是简简单单说火线自己招了几个研发人员，大家一起去把它研发出来的，而是非常具有社区属性。我们和甲方的各个安全工作者一起把产品打磨得足够好，在这个过程中他们提供了遇到的各种各样的安全场景。这是我们想看到的，现在也是一步步往那个方向走了。

洞态IAST开源版的开放程度还是比较高的。开源版所有的规则都是开放的，可以去调整，目前开源版和商业版的检测规则是一样的，检测核心能力都是开放出来的。

那同样，我们在内部的一些数据链调用方面也做了很多开放，比如agent负责收集代码的调用链，这些调用链全部会传到云端上来，这部分的数据也已经完全公开。这样的好处是方便用户内部针对白盒、黑盒和IAST做联动。以前黑盒扫出来的漏洞，只能看到payload，那现在可以用IAST通过API把这次扫描的payload对应的代码调用链拉过来。通过这种方式给研发的时候，内部的运营效率会提升非常多。

洞态IAST-agent的策略只做了被动插桩的方式，原因是我们想做很难但是很正确的事情。作为标准产品来部署，如果需要让用户考虑如何处理脏数据的问题，其实是不太适合部署到DevOps流程里面来。

第一，洞态IAST可以保证没有任何脏数据，agent端只负责收集数据，不做检测，agent整体的CPU资源消耗比其它类型的IAST要低很多。

第二，洞态也可以支持更多新的场景，比如流量式的和主动式的加密、验签、跨服务场景等等。

第三，作为DevSecOps里面的最佳实践，我认为被动式IAST可以做到更无感地嵌入DevSecOps流程里。

另外一点是我们在业务优先上面的考虑。其实从最开始大家对IAST预期是非常高的，但随着越来越多的公司开始去部署IAST和agent，就发现从安全部门出发去部署agent的时候，首先考虑的不是检测问题，而是能不能持续地把agent在内部部署下去，并且让它存活下去，在这个过程中会有研发或者测试同事去不断地挑战。比如资源占用是怎样的，是否有合理的熔断降级策略，怎么样保证不会影响到业务，API接口响应慢的时候有没有一些策略可以保证不影响测试环境稳定性。

在洞态IAST发布之后，我们把业务优先放在一个很重要的位置。我们做了以下设计来保证业务优先能够实现。

第一，dongtai-agent在架构层面上分了两块，最外层的agent以及内部的core包。两级加载的机制可以保证在agent异常情况下，可以把内部的core包卸载下来。通过种多级加载的机制，保证做熔断降级和卸载的时候可以更方便一些。

第二，洞态支持非常多的熔断降级策略。作为一个标准产品，我们在主机、JVM、以及应用层面做了非常多的降级策略，比如除了cpu内存以外，洞态也支持一些接口的响应时间，单个请求的hook数超过一定值之后就可以把它bypass掉等等。

所做这些都是为了方便在内部部署agent的时候，可以获得比较好的体验，尽可能让agent在内部部署得更顺畅一些。

之前商业版发布会的时候，我们发布了高性能版本，目前洞态IAST在内部压测的时候可以支持数万应用同时在线进行安全检测。

IAST在产品能力上也有一些比较有特色的点，比如洞态可以支持API自动发现梳理，这是黑盒和白盒都没有办法做到的。也就是插桩了agent之后可以一次性梳理出来当前应用的所有API，有数据之后就可以知道这次测试有哪些API是没有覆盖到的，哪些API可以通过第三方联动的自动化测试平台做重点的跟进，可以知道API的安全测试覆盖度是多少，这在和黑盒、白盒进行辅助验证的时候非常有价值。

有用户问到洞态IAST是否拥有SCA的能力。其实洞态的开源版和商业版都有SCA检测能力，可以做运行时的组件成分分析。相比白盒来说，用户拿到的反馈一定是内部引入并且调用的非常准确的组件。

同时洞态也可以做License识别。对于用户来说，可以非常精准地定位到有风险的，需要推进修复的组件，展示它们是不是在线上正运行以及当前组件跑在了哪些业务上。

去年Log4j2爆出来的时候，我们公司应该是最快把Log4j2组件所影响的范围完整梳理出来的，现在我们把当时的能力完整到迁移到dongtai-SCA里面来了。

洞态IAST也具有全链路跟踪的能力。洞态做的会更多一些，不仅仅支持java内部的链路跟踪，还支持跨语言链路跟踪能力；另外基于异步的kafka等消息中间件，消息传递的时候所触发的整个链路也可以完整地跟踪起来。上边的图片里边是一个demo，在java这边可以看到有消息写入的过程，有一个写入者和消费者，go这边也是有消息生产者。

洞态IAST可以把调用的链路完整梳理出来，并且在漏洞展示的时候，也同样展示整个漏洞触发的链路，在哪个服务上面通过哪些中间件传递，最终触发了危险函数。上边的图片中有一个靶场地址，大家有兴趣可以去体验一下。

在最近的一段时间，我们在帮客户做IAST落地的时候其实遇到很多的问题，主要分为以下几类。

第一类是框架适配的问题。因为IAST会hook一些请求的函数，hook一些危险方法等等，如果说gRPC或者RPC的协议是魔改的，那这时候在agent端是要做agent内部的框架适配，这对于大部分想要去实施IAST但是没有研发能力的安全团队来说，其实是很难做到的。

第二类是有些安全团队在部署完之后会面临很多稳定性的问题。比如是否会产生一些脏数据甚至是日志输出，是否覆盖了之前一些正常业务的日志，以及agent装上去之后，测试工程师怎么去做压测，压测的结果是不是可以以这个为指标放到线上去，等等在整个DevOps实施的过程中会遇到非常多边缘的问题。就拿压测来说，我们一般不建议客户把agent挂上去做压测，拿这个性能指标去估算线上的使用值，这样会造成线上的资源浪费。

第三类问题是，对于很多安全的部门来说，去推进研发或测试部署agent，整个跨部门的协调成本是非常高的。

第四类是，使用IAST的产出其实比较依赖于IAST使用方（甲方）的安全能力。我们见过最好的案例是整个公司50%以上中高危的漏洞是IAST自动产出的，每两周都会有中高危的漏洞检出，我们简单验证了一下非常准确，那他们的安全团队基本上投人去运营IAST的规则就可以了。也有很多甲方想去实施IAST，但发现其实没有办法去制定合理的实施策略 。IAST报出来的漏洞也不知道如何去验证，推进缓慢，和自己最早预期其实差距是比较大的。

所以IAST对于漏洞检测来说是个非常美好的愿景，但目前看在落地的过程中其实有非常大量的知识、积累以及最佳实践是没有被公布出来的。我们这一年多接触了非常多的部署案例，也积累了很多比较好的实践。

经过我们在甲方不断地实践，最终总结出来如何有效地在DevOps流程里边推进IAST（如上图片中所示）。

第一，可以先做一小部分agent的部署，在一些和安全部门比较友好的测试项目里边验证agent，去验证在公司内部的兼容性和性能，以及容忍度是多少。因为有些公司特别是在k8s里面去部署的时候，给每个pod的资源其实非常少，可能这个pod需要的资源至少就要1G ，比如说1核2G的机器，最多给了不到2核，稍微多了20%buff的值，在这种情况下如果部署agent那么pod就会直接down掉，我们经常会遇到种情况 。前期验证以及对资源的预估是非常重要的 。

第二，经过前期初步地验证之后，就可以小批量的部署，把agent在内部更多的应用做部署。如果有些业务比较敏感，或者出现了边缘的情况没有考虑到，就可以把很少量的agent再下下来。

第三，agent在内部运营稳定之后，可以对规则做一些匹配。有些客户内部部署的业务量是非常少的，那就可以开很多的规则。即便有误报，也可以对漏洞做一些研究和验证，不断去迭代规则。但是有些客户的agent部署量是上万甚至超过10万的，那这时候对规则的敏感度是极其高的，那我们会根据客户公司的情况建议他们开放非常少量的规则，来达到最终比较好的检测效果 。

第四，有了漏洞之后，再针对漏洞做一些风险发现，持续去运营IAST。

第五，后面再逐渐地去推广，在DevOps里做一些自动化的集成等等。

以上是我们目前比较建议的在DevOps流程里去推进IAST的方法论。这可以避免大家步子跨得太大，导致agent部上去一大批，公司觉得影响性能了，又全部下下来 ，下次再推就会非常困难了。

在今年五月份的时候我们推出了洞态IAST商业版本，在商业服务方面做了一些比较深度的支持。

首先是在agent部署方面，我们会提供框架适配的服务，以及测试、运维等跨部门沟通的协助。

第二，在应用漏洞检测方面，洞态商业版也提供定制化规则以及循序渐进地去做规则调优的服务支持。

第三，在后续的漏洞验证及持续运营阶段，可以为商业客户做一些辅助漏洞验证，以及多工具交叉的验证等等。

我们希望洞态IAST可以更持久地被推进下去，也希望使用洞态IAST的甲方企业可以更好地把IAST应用到自己的业务系统里面。

另外，洞态IAST开源版支持所有漏洞类型的检测以及开源组件的成分分析，商业版做了更多的功能（如上图所示），比如，Dubbo、gRPC等微服务全链路跟踪的能力，运行时多层的开源组件的依赖分析，把递归调用的所有组件都load出来去做安全检测，商业版也支持jenkins、jira等插件一键集成，以及提供自研框架的适配服务等等。

下图是IAST融入DevSecOps的落地实践笔记的申请二维码，笔记里面有同程旅行、去哪儿、好大夫、陌陌、58、自如、知乎、聚水潭等用户，记录了他们在内部落地洞态IAST所遇到的一些问题以及最终如何把IAST成功部署上线并推广。

有兴趣阅读笔记的朋友或是想要试用洞态IAST商业版，都可以扫描下边图片中的二维码，进行免费申请。