从 DevSecOps 流程视角看 IAST 技术应用与发展

　　原标题：从 DevSecOps 流程视角看 IAST 技术应用与发展

　　近几年,伴随云计算、容器技术以及 DevOps 的普及,DevSecOps 作为糅合了开发、安全及运营理念的全新方法,其关注热度持续上升,并在全球范围内得到广泛应用。目前 IAST 被部分业内人士看作一种“更适合 DevSecOps 流程构建”的应用程序安全检测技术,受到行业的更多关注。那么 IAST 是否真的更适合 DevSecOps 流程构建?它能够提供哪些核心能力和关键技术,以及有哪些局限性,未来前景如何?对此,安全牛特别邀请到火线安全洞态 IAST 产品负责人董志勇先生,就 IAST 和 DevSecOps 的相关话题展开探讨。

　　安全牛:

　　在您看来,目前DevSecOps的痛点和难点是什么?

　　董志勇:

　　要了解 DevSecOps 的痛点和难点,首先要弄明白 DevSecOps 到底是什么。根据 Gartner 定义,DevSecOps(即 Development、Security 和 Operations)是指在不减少敏捷度和开发者效率,或在不要求开发者离开现有工具链的情况下,将安全尽可能无缝、无感知地集成进 IT 和 DevOps 开发中。

　　DevSecOps 有三个核心点:一是便于集成,安全工具可以很方便的与现有的 IT 或 DevOps 流程对接和打通,这也是实现 DevSecOps 的前提条件;二是无感知,要求安全工具对已有的 DevOps 流程不能产生任何的影响和干扰;三是在研发阶段解决安全问题,而不是像传统开发流程一样,在软件上线后由安全人员检测问题,再反馈给研发人员来解决问题。问题越早的检测和修复,企业的整体修复成本就越低,这也是 DevSecOps 的核心目的之一。目前来看,DevSecOps 在落地时遇到的主要痛点和难点也体现在这三个点上。

　　在 IAST 技术出现之前,我们熟知的安全技术是动态应用程序安全测试技术(DAST)和静态应用程序安全测试技术(SAST),这两种技术在 DevSecOps 流程构建中有其独特优势,但也有各自的不足。

　　DAST 的优点是检测结果准确,因为它拿的是真实 Payload(有效载荷),在运行的应用程序上直接做漏洞验证。DAST 发现问题后,没有代码层的相关信息,这可能会给研发人员解决问题带来一定的成本,同时其检测时间较长、会产生脏数据等,不能满足 DevSecOps 对无感的要求;SAST 的检测结果对于开发人员来说比较友好,但由于工具无法直接理解代码,尤其是开发人员在写代码时,引用的各种设计模式和新奇的技术,这些原因都会导致 SAST 漏洞检测的误报率存在挑战,给到研发人员时,不能保证报告的准确性,影响使用。

　　安全牛:

　　IAST 可以帮助 DevSecOps 进行哪些应对呢?

　　董志勇:

　　IAST 是交互式应用程序安全测试(Interactive Application Security Testing),是一种新的应用程序安全测试方案,通过在服务端部署 Agent ,收集、监控应用程序运行时的函数执行、数据传输等信息,然后根据污点跟踪算法、值传递算法等一系列算法进行漏洞的识别。

　　IAST 是一种应用程序运行时的漏洞检测技术,所以它具备了 DAST 中检测结果准确的特征;此外,IAST 采集到数据在方法内部的流动后,通过污点跟踪算法来进行漏洞检测,用算法来进行漏洞检测,所以检测结果也具备了 SAST 中全面性的特征。

　　同时因为 IAST 安装在应用程序内部,安全人员可以拿到类似于源码级漏洞报告,这种漏洞结果对于开发人员很友好,可以方便开发人员进行漏洞修复。综合来看,IAST 具有高检出率、低误报率、检测报告详细便于排查等一系列优势,可以很好地在 DevSecOps 流程中解决痛点和难点。

　　安全牛:

　　基于 IAST 来构建 DevSecOps 流程,所依靠的关键性技术有哪些?

　　董志勇:

　　对于这个问题,我的理解是如何用 IAST 来构建 DevSecOps ,或者说是构建 DevSecOps 流程时,IAST 必须具备哪些功能才能支撑这个流程的构建。我个人认为大概有三点。第一点,IAST 必须柔和地嵌入 DevOps 流程,即十分便利地与 CI/CD 流程对接,包括与 Jenkins 、Gitlab 等工具打通等;第二点,当 IAST 和 DevOps 流程对接时,需要做版本的控制,支持在 Agent 端直接指定项目名称和版本,进行后续的版本跟踪,以及版本的漏洞对比等;第三点,IAST 可通过漏洞复测与回归测试,验证此前发现的漏洞是否依旧存在。

　　安全牛:

　　相比较其他应用程序安全测试模式,您认为 IAST 的核心能力有哪些?其在具体的场景应用中又会存在哪些局限性?

　　董志勇:

　　IAST 本质是做漏洞检测,其核心能力主要包括四点:一是实时的漏洞检测,保证不影响  DevOps 的原有效率;二是第三方组件的梳理和漏洞检测,保证应用避免供应链的攻击;三是灵活的漏洞检测逻辑,让用户在使用内置检测逻辑的同时,很方便地配置出具有业务属性的特定检测逻辑,来做业务层面的漏洞检测;四是极低的运营成本,IAST 在企业内部使用时,一定是需要持续运营的,当出现了 IAST 没有覆盖到的漏洞情况时,可以用 的成本来完善检测策略和检测逻辑,保证漏洞的检出。

　　IAST 的局限性主要体现在 IAST 的内置漏洞策略有限、且无业务属性,无法保证检测所有的安全风险;推荐在上线前通过白盒、灰盒、黑盒、人工渗透测试一起来检测漏洞,然后将 IAST 没有覆盖到的漏洞策略补充进来;上线后可通过外部的众测、SRC 运营等手段,更全面地发现安全风险,同时将漏洞策略补充到 IAST 中,做后续的自动化测试。

　　安全牛:

　　目前国内 IAST 产品的代表类型有哪些?从应用的角度看其主要差异是什么?

　　董志勇:

　　根据 Gatner 定义,IAST 特指被动插桩的这种模式,但由于开发难度等一系列原因,在国内出现了一些临时性的解决方案,如:将黑盒改造成 IAST ,另外也有将 RASP 与扫描器结合形成主动插桩的方案。

　　主动插桩的原理是在应用程序上安装 Agent,Agent 采集应用程序从外部获取数据的入口,以及最终触发漏洞的关键位置信息,然后联动外部扫描器,把流量数据发到扫描器上,扫描器根据漏洞库,或者根据主动式对应的 POC 库,来做一些流量的重组、重放,实现对漏洞的检测。它在检测漏洞的时候,是看外部扫描器端重组的 POC 有没有到达上次出现危险的位置。

　　主动式有很大的局限性:一,从整个行业来看,应用的安全性越来越高,比如验证码、数据包加密、防重放等一些安全措施越来越完善。在这样的背景下,主动式 IAST 依赖流量重放进行漏洞检测,比如:滑动验证码场景下,IAST 无法重放流量,此时,便无法检测对应位置的漏洞;二,主动式 IAST 需要进行流量重放,会产生大量的脏数据,影响功能测试结果;三,应用程序的技术架构整体趋势是向微服务、分布式等方向发展,在微服务中,服务间可能不用传统的 Http 请求进行通信,比如使用基于 TCP 协议的 RPC 请求。此时,主动式 IAST 无法发起 RPC 请求,也就无法进行漏洞检测。

　　被动式 IAST 的检测原理,是在应用程序上安装 Agent ,安全人员进行正常的功能测试时,外部会有一定的流量进入。在这种模式下,所有进来的流量数据都会被标记为不可信,并分析不可信数据在内部应用程序中如何变化,如何流转,类似于生物学上的基因传递流程。它只需要分析不可信数据在应用程序内部的变化情况,重点分析数据的流向和传播,然后用“算法 + 数据流”进行漏洞检测,根据不可信数据未经任何有效处理直接到达危险函数的方法,来判定漏洞是否存在,无需做流量重放。前文所提到的验证码、数据包加密或者防重放场景,以及分布式、微服务的技术架构下都可以使用被动式 IAST 进行漏洞检测。

　　从整个行业趋势上来说,应用本身的安全性越来越高,只有被动式 IAST 才能兼容所有的场景,在实现漏洞检测的同时,满足 DevOps 流程下高效、准确等要求,所以 选择一定是被动式 IAST 。

　　安全牛:

　　用户在选择 IAST 产品时,应从哪些维度进行评估?

　　董志勇:

　　第一点是使用成本,它体现在几部分,其一是产品在 Server 端的部署成本,其二是在 Server 端的升级成本,其三是当把 Server 端部署和升级之后,Agent 在业务线上的推广成本,或者 Agent 在使用过程中的升级成本等。所以整体来看,需要综合考虑:Server 端的部署成本, Server 端的升级成本,Agent 端的部署升级成本以及 Agent 端的推广成本。

　　第二点是漏洞检测能力,建议直接把 IAST 部署到企业内部真实业务线上试运行两到三个月。根据“是否检测到漏洞,及漏洞检测的准确率”,对比哪款产品检测效果更佳,这是最实际的评估方法。第三点是 IAST 的整体扩展性,在企业落地 IAST 时,需评估其是否能够便利地与已有业务系统较好结合。可通过查看其 API 接口是否完善、需要的数据是否都能获取。火线安全洞态 IAST 直接开放源代码,方便用户做二次开发,因此可扩展性更强。

　　第四点是前文提到的运营成本,当出现未检测到的漏洞时,如何将缺失的策略或检测规则加入到产品中,也会产生比较高的后期使用成本,不能忽视。

　　安全牛:

　　火线安全选择了开源 IAST 产品模式,其原因是什么?开源 IAST 产品的能力表现如何?我们未来的产品规划又是怎样的?

　　董志勇:

　　IAST 是个非常不错的工具,可以高效地帮助企业在 DevOps 阶段解决相当多的漏洞。火线安全的理念是帮助整个行业提升安全能力,我们想让更多的企业使用 IAST 来防范安全风险。此外,IAST 本身是一个安全产品,其开发门槛比较高,倘若因为市场上没有开源的 IAST 产品,导致很多企业重复造轮子,就会影响行业进步,因此我们选择了开源。其实开源和非开源只是产品的外在形式不同,同样的领域也都存在伟大的闭源产品和开源产品。洞态 IAST 是这一领域的后起之秀,产品进展很快,也得到了很多用户的支持和认可。我们也会继续努力打磨产品,为用户带来更大的价值。

　　对 IAST 的未来规划:洞态 IAST 整体架构是利用 Agent 采集数据,在 Server 端进行漏洞检测。在这种架构下,在一定程度上将安全与开发进行分割,安全人员可专注于安全,开发人员可专注于开发。火线安全希望洞态 IAST 真正成为一款链接 Dev、Ops 和 Sec 团队的工具,让安全赋能开发和运维,并结合场景来满足更多 DevSecOps 流程下的安全需求。

　　安全牛评:

　　在代码安全与敏捷交付同样重要的时代,只有开发者主动接受安全测试,才能从“根”上解决代码安全问题。在提高开发人员安全意识的同时,将安全测试无感知地融入开发流程等等都是在想尽办法让开发者爱上测试。“以 IAST 为起点构建 DevSecOps 流程”的初衷是用开发思维拉近代码安全测试与代码开发者的距离。

　　而开源的代码安全工具,进一步推动开发者乐于进行安全测试,有利于应用开发行业代码安全整体水平的提高,也将成为推动代码安全市场良性循环的“加速剂”。火线安全开创了开源代码安全工具的元年——代码安全从代码开源做起。