精选用户故事|洞态IAST在聚水潭的误报率几乎为0，如何做到？

亮点锦集（下边三条需要单独弄框强调）：

我个人在实际使用过程中体验到，对于像命令执行和sql注入这类漏洞，洞态能够做到百分百的检测。

——Spenser

对于一个开源项目而言，更多人参与就意味着可以完成更多的内容或者是发现更多的问题。我正是因为看中了洞态的开源生态，所以说我们才选择使用洞态。

——Spenser

滴水穿石，聚水成潭。聚水潭成立于2014年，创建之初，以电商SaaS ERP切入市场，凭借出色的产品和服务，快速获得市场的肯定。随着客户需求的不断变化，如今聚水潭已经发展成为以SaaS ERP为核心，集多种商家服务为一体的知名SaaS协同平台。

聚水潭不仅是洞态的早期用户，其相关负责人Spenser也是洞态开源社区的Contributor，为洞态项目提交不少issue和策略。本篇文章记录了对聚水潭Spenser师傅所做的采访。

Q1：

洞态小助手: 请师傅先做一下自我介绍，包括公司职位，还有负责的具体事务。

Spenser:我是Saas ERP公司——聚水潭的高级安全工程师Spenser，负责公司内部安全项目的研发以及安全架构的设计。

Q2：

洞态小助手: 好的~我们知道IAST产品一般是在产品上线前使用的，那您为什么选择在上线前做安全检测呢？

Spenser: 因为我们需要确保项目在上线的时候不会出现任何的安全隐患。洞态 IAST通过内存的方式，可以帮我们非常准确地找出系统中可能存在的一些问题或者安全隐患。我个人在实际使用过程中体验到，对于像命令执行和sql注入这类漏洞，洞态能够做到百分百的检测。

Q3：

洞态小助手: 上线前的安全检测工具有很多，那您为什么会选择了洞态IAST呢？Spenser: 因为首先洞态是完全开源的IAST产品，这在中国甚至说是在全球都是没有先例的。洞态将整个生态和技术推到了大众面前，大家都可以参与进来。对于一个开源项目而言，更多人参与就意味着可以完成更多的内容或者是发现更多的问题。我正是因为看中了洞态的这样一个生态，所以说我们才选择使用洞态。

Q4：

洞态小助手：那您最一开始是从哪个渠道了解到洞态的呀？

Spenser: 我的同事野烟，在某一天加班的时候告诉我说，他发现了一个IAST产品，他自己测试下来效果是比较好，我是从那个时候开始了解的。

Q5：

洞态小助手: 我知道洞态在聚水潭已经上了一部分业务线了。那目前为止有多少条业务线部署了洞态IAST呢？

Spenser:大致上说，我们现在有三到四条业务线部署了洞态IAST。

Q6：

洞态小助手: 那在使用的这段时间里，洞态帮助咱们检测出了多少的开发漏洞，有具体的数字吗？

Spenser: 漏洞数量大概是在50个左右，中危的漏洞偏多。我们之前在测试的情况下，故意创造了一些高危漏洞，也是可以非常准确地识别。

Q7：

洞态小助手: 嗯呢，那既然说到这儿，洞态误报的情况怎么样啊？

Spenser:除了之前关于敏感信息检测这一块有误报，其它基本没有。不过这块儿经过优化之后误报也几乎消失了。

洞态小助手: 您是通过什么样的方式来优化的呢？

Spenser:这个是我向洞态提了一条正则表达式，这个正则表达式是根据我的个人经验进行设计的。属于双方一起完成的，我贡献表达式，洞态团队把这条表达式设置成了敏感信息检测的默认表达式。

对于敏感数据检测的误报，我们会自己优化正则。漏洞检测，我们会根据自身的安全标准选择性开启规则，同时我们会编写一些demo来验证规则的漏检率和误报率，规则本身存在问题的会提issue。同时我们也通过自研的DongTai-SDK，对扫描结果进行验证，过滤掉一些无意义漏洞。

洞态小助手: 您也给我们提了策略，然后我们做了优化。Spenser: 对。

Q8：

洞态小助手: 公司对于洞态IAST的下⼀步推动计划是什么？预计什么时候在公司内部实现大面积推⼴呢？

Spenser:关于这一块的话，我们的主营业务线是由C#进行开发的，我们后期有计划参与到洞态C# Agent的开发中，这是为社区做贡献，也是为我们主要业务线能够使用上洞态做出一个铺垫嘛。

Q9：

洞态小助手: 接下来这个问题其实和我刚才问的有点相似了，您这边基于公司的业务实现需要，在内部开发的过程中对开源版本的洞态做了哪些升级和改造？有没有和洞态开源社区进行共创共建？啊，这个这肯定是有的。

Spenser: 关于我在开源社区的共创共建方面做的事情，一方面是我做了洞态IAST SDK的开发，Python的SDK开发，通过SDK就不需要考虑底层的一些接口的调度，或者是一些错误的处理，可以更关注于用IAST进行业务的开发。关于接口这一块，我提出了很多的issue，然后洞态这边对于issue的处理速度也是非常得快。

Q10：

洞态小助手: 谢谢师父！在公司部署和推广IAST这件事情上，您那边开发人员是否较难接受，导致推动存在困难，然后您是怎么克服的？

Spenser:我们会先在安全部门自己的项目中上线部署，消除掉一些坑后，有些存在阻力的业务线，我们会找他们拉一份代码，然后自己部署一套完全隔离的测试环境，测试没有问题后，让他们部署到正在使用的测试环境。

之前我们在某一条业务线上进行推动的时候，由于IAST对于健康检测这块的识别有一定的不足，导致我们的测试环境使用了洞态一段时间之后变得非常的卡顿，是因为我们的redis库被写满了，健康检测的频率是非常高的，会产生大量的扫描任务，这些扫描任务都会被写进redis，量比较大。消费端worker只有一个，无法及时地消费，就导致redis爆满之后测试环境业务比较卡顿。解决的方案是洞态开源社区的一位同学，提供了对于健康检测加白的功能，于是我们就解决这个问题。

洞态小助手: 那这个开源社区真的还是挺有帮助的。

Q11：

洞态小助手:对于聚水潭来说，洞态还需要进一步的推广使用，您预计还存在哪些难点，是否有需要洞态团队协助的地方？

Spenser: 我们的主营业务线用的是C#，C#-Agent开发完成之后，可能会存在一些漏洞，就需要洞态团队帮忙一起联动测试一下。另外，在开发的过程中可能会有涉及到协议的问题，就是上报的一些协议的问题，那也需要跟洞态团队进行交流。

Q12:

洞态小助手: 好的。那您在使用的过程中有没有一些有趣的事情和我们分享一下？

Spenser:有趣的事情的话，我这个人有个习惯，就是说任何东西拿过来之后我会先对它进行验证，我要看它靠可不可靠嘛，毕竟东西大家都没有用过。 公司的安全系统是用Python开发的，是我一个人写的。我会在系统中故意制造一些漏洞，然后看看洞态能不能识别。第一次没有识别出来，后来我同事去跟洞态团队的人进行了反馈。洞态团队经过大概一两天的时间，很快修复完了，修好之后还过来催着我的同事说：“你赶紧测一下，我现在在开车，我到家之后，就帮你一起看，看看效果怎么样，如果还是有问题的话，我当场改”。我觉得这个精神是非常好的。

洞态小助手: 哈哈，洞态技术人员对技术的热情程度是跟你一样的。

Q13:

洞态小助手: 最后一部分的问题是关于洞态未来展望的，您希望洞态未来会开发的功能是什么？

Spenser:我希望洞态未来可以有一些攻击阻断的功能吧。我希望它可以有两个模块，一个是检测的，检测的话会消耗大量的性能，是在线上测试环境。拦截的话，像那些常见的漏洞，比如命令注入、sql注入，使用带有拦截功能agent的时候，它可以在线上非常稳定的运行，但是同时它也可以有效地告警或者阻断。 因为从技术层面上来说，sql注入本质上是对数据库驱动的拦截。那如果可以在数据库驱动层面进行hook识别的话，那么我觉得所有的sql注入都可以防掉，那同时命令执行也是。对命令执行的检测，洞态其实已经实现。对于操作系统的环境不管是Windows还是Linux，任何环境下去执行命令的时候，一定会调到系统的某一个函数。那么只要对这个函数进行拦截，就可以识别出是否是攻击，就可以把命令攻击拦截掉。

还有一方面，我觉得对于一些新型的攻击手法，或者是一些情报，也可以进行一个识别，能够更加智能化。像杀毒软件的话有智能查杀引擎，其实我也希望洞态可以有这种智能化发现漏洞的功能，通过人工智能或者深度学习这种技术能够识别出漏洞，甚至可以通过这种方式识别出业务逻辑层面的漏洞。

比如某平台是需要消耗积分进行查询业务，之前我挖到过这么一个漏洞，通过对查询语句的一些处理，可以使得用户不用消耗积分去查询。像这种其实就属于业务型漏洞。可能一开始没法识别，但是通过训练，可能是我们自己发现漏洞，然后把它录制进去。在有了这样的数据源的情况下，进行训练之后，能够识别出业务型的漏洞。

洞态小助手: 嗯。您提的这点可能需要和用户一起来开发，这种类型漏洞的检测，如果单靠我们来做的话，可能做得不会很到位。

Spenser:其实是你们提供了引擎，然后让用户提供数据源，数据源是在用户本地，那么你们的神经网络或者深度学习的模型可以通过对于这些数据源的训练，去识别出这套系统里面的业务型漏洞。每个系统逻辑都会不一样，但是肯定会有某种通用的写法，有大量的原始数据之后其实就可以训练出一种能够用于识别业务漏洞的神经网络或者是智能化引擎。

对于师傅的建议和期望，我们会认真考虑。关于以上对话，屏幕前的你是否有想进一步了解的内容（说不定我们会出个续集哈）？或者你在使用洞态的过程中，有哪些问题或者期望？都可以在下方留言讨论喔🤣