信息安全-应用安全-SAST、DAST、IAST

AST（Application Security Test，应用安全测试）工具是应用程序软件安全实践的支柱之一。随着近年来安全越来越得到重视，AST们也发生着快速的迭代和变化，成为信息安全领域的当红炸子鸡。我们认为所有的软件技术和项目管理相关人员都应该对AST工具有基本的认知，并在一定程度上应用它们。但实际上，我们经常发现SAST，DAST，IAST等十分近似的名词让许多企业的安全负责人都缺乏清晰的理解。

那么SAST，DAST和IAST到底是什么？他们之间的优劣势如何？这篇小文就简而述之。

一、SAST

SAST（Static Application Security Testing，静态应用程序安全测试）对应用程序源代码执行直接的白盒分析。分析是在代码的静态视图上运行的，这意味着代码在审查时没有运行。如今，SAST已经完全成为主流，并且在整个软件行业中被广泛采用。

SAST的优点：

广泛的编程语言支持；

检出率较高；

可以定位到代码行。

SAST的缺点：

准确性差：优秀SAST产品的误报率也在53%以上*；

无法看到执行流；

通常需要一些定制或调参；

不适用于生产阶段的系统；

通常运行很慢。

二、DAST

与SAST相反，DAST（Dynamic Application Security Testing，动态应用程序安全测试）对应用程序进行黑盒分析，这意味着它们不能访问代码或实现细节。DAST只检查系统对潜在漏洞测试的请求和响应。换言之，DAST是外部的漏洞扫描程序。

DAST的优点：

独立于应用程序的技术和平台，无需代码细节；

执行相对较快；

误报率较低。

DAST的缺点：

检出率低：优秀的DAST产品检出率也只有18%*；

无法定位到代码行；

使用门槛高，报告通常需要安全专家解读。

三、IAST

IAST（Interactive Application Security Testing，交互式应用程序安全测试）结合了SAST和DAST的优点。IAST可以像SAST一样看到源代码，也可以像DAST一样看到应用程序运行时的执行流。

IAST的优点：

检出率较高；

误报率较低；

可以在研发测试和生产环境中使用；

实时产生结果；

可以持续检测，对DevOps支持度更高；

即插即用，无需配置或调参；

可以与CI平台集成，创建相互连接的工作流。

IAST的缺点：

需要特定的语言支持

我们可以看到，与SAST和DAST类产品相比，IAST类产品拥有明显的优势。但IAST作为近年来才诞生的热点，其发展还远没有SAST和DAST类产品成熟。因此我们认为如果预算允许，以上这三类应用安全测试产品应该在机构中同时应用。如果机构只拥有一款产品的预算，IAST是最合适的选择。因为IAST不仅拥有安全测试上的能力优势，也更容易与DevOps紧密结合，帮助机构在不降低发布效率的前提下完成安全测试。

---

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

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

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

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

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

A : 对于这个问题,我的理解是如何用 IAST 来构建 DevSecOps ,或者说是构建 DevSecOps 流程时,IAST 必须具备哪些功能才能支撑这个流程的构建。我个人认为大概有三点。

第一点,IAST 必须柔和地嵌入 DevOps 流程,即十分便利地与 CI/CD 流程对接,包括与 Jenkins 、Gitlab 等工具打通等;

第二点,当 IAST 和 DevOps 流程对接时,需要做版本的控制,支持在 Agent 端直接指定项目名称和版本,进行后续的版本跟踪,以及版本的漏洞对比等;

第三点,IAST 可通过漏洞复测与回归测试,验证此前发现的漏洞是否依旧存在;

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

A : IAST 本质是做漏洞检测,其核心能力主要包括四点:

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

IAST 的局限性主要体现在 IAST 的内置漏洞策略有限、且无业务属性,无法保证检测所有的安全风险;

推荐在上线前通过白盒、灰盒、黑盒、人工渗透测试一起来检测漏洞,然后将 IAST 没有覆盖到的漏洞策略补充进来;

上线后可通过外部的众测、SRC 运营等手段,更全面地发现安全风险,同时将漏洞策略补充到 IAST 中,做后续的自动化测试。

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

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

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

主动式有很大的局限性:

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

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

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

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

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

第二点是漏洞检测能力,建议直接把 IAST 部署到企业内部真实业务线上试运行两到三个月。根据“是否检测到漏洞,及漏洞检测的准确率”,对比哪款产品检测效果更佳,这是最实际的评估方法。

第三点是 IAST 的整体扩展性,在企业落地 IAST 时,需评估其是否能够便利地与已有业务系统较好结合。可通过查看其 API 接口是否完善、需要的数据是否都能获取。火线安全洞态 IAST 直接开放源代码,方便用户做二次开发,因此可扩展性更强。

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

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

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

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

安全牛评

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

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