IAST 全称 Interactive Application Security Testing，即交互式应用程序安全测试，一般也叫灰盒，是一种在应用和 API 中自动化识别和诊断软件漏洞的应用程序安全测试技术。最早在 2012 年由 Gartner 首次提出，后来在国外得到广泛推广和应用。与传统的 SAST（静态应用程序安全测试）和 DAST（动态应用程序安全测试）方法相比，IAST 提供了更全面、准确和高效的安全测试解决方案。
传统的 SAST 工具主要关注静态代码分析，一般是通过检查源代码来发现潜在的漏洞和安全弱点。然而，由于无法准确模拟应用程序的实际运行环境和用户输入，因此 SAST 工具往往会产生大量误报。
DAST 工具通过模拟实际应用程序的交互和攻击场景来测试应用程序的安全性，但尽管 DAST 工具可以提供更真实的测试结果以及 Payload，但由于无法准确确定漏洞的具体代码位置且漏报率较高，给开发人员的修复工作带来了挑战的同时也容易留下安全隐患。
与此相比，IAST 将 SAST 和 DAST 的优点融合到一个解决方案中，通过 Agent 插桩技术（Instrument）收集、监控 Web 应用程序运行时的函数执行、数据传输，并与 IAST 服务端（Server）进行实时交互，高效、准确地识别安全缺陷及漏洞，可准确确定漏洞所在的代码文件、行数、函数及参数，能够准确地检测到漏洞的可利用性，并确定其在应用程序代码中的精确代码位置。
目前国内常见的 IAST 产品中，一般是通过代理模式、流量镜像模式，插桩模式等读取应用程序运行时的相关数据交互，其中插桩模式还可进一步分为主动插桩、被动插桩。
代理模式、流量镜像模式都是黑盒的一种变种，是在早期国内 IAST 技术不成熟的现实情况下，通过对黑盒的改造以充当 IAST 使用的产物。
主动插桩模式在关键函数（危险方法） Hook 到流量后，会添加 Payload 进行扫描，这个过程仍然是类似黑盒的功能，主动对目标应用进行扫描，应用服务器的 IAST Agent不会追踪整个污点数据流，只会收集存在危险方法调用的请求流量，然后发送验证数据包给 IAST 的 Server 端，Server 端会向应用服务器发送构造好的重放流量来验证风险是否存在。
这种采集和重放流量的方式产生的脏数据比爬虫、代理式黑盒是显著减少了的，但是其本质仍然是黑盒的技术和逻辑，因为只要存在流量重放，就一定会存在脏数据，当下的新场景也无法覆盖。
对 IAST 来说，被动插桩模式才是最重要、也是最符合 IAST 技术路线与原理定位的检测模式。最早推出 IAST 产品的美国厂商 Contrast，其 IAST 就只提供被动插桩一种方式。
被动插桩基于值匹配算法和污点跟踪算法进行漏洞检测，不会主动发送 Payload，不用采集和重放流量，对来自客户端的请求响应进行污点传播数据流监控，根据是否经过无害化处理来判断是否存在漏洞。
只需要开启了业务测试，就会自动触发安全测试， 通过测试流量就可以实时地进行漏洞检测，不会影响同时运行的其他测试活动，在这个过程中不会产生脏数据，并且可以解决比如微服务这样的新场景、新架构的检测问题。
被动插桩 IAST 的技术原理，在提出之初主要是针对于 Java 而言，因为 Java 提供了原生的接口，它允许在程序运行起来以后，对编译后的代码进行操作或监听等操作。IAST 主要是对代码的调用链过程进行监听，监听的点主要分为三类：入口方法、传播方法、危险方法。
入口方法：主要是指接受用户传入数据的方法；
传播方法：对用户传入的参数进行处理的业务逻辑；
危险方法：通常指可能会造成危害的方法。
对被动式 IAST 来说，污点跟踪算法是其最核心的漏洞检测方式。上文提到，Java 应用提供了原生的接口，在 IAST 启动的时候，会通过 Agent 技术对上述三类方法进行监听。与零信任概念类似，IAST 不信任任何用户传入的值，所有由用户传入的值都会被打上污点标签。如果用户传入的数据携带着污点标签传入到了最终的危险方法，则会被判定为存在漏洞。
如果研发人员在传播方法过程中，对传入的值进行了过滤或使用了安全方法，则会在经过这类方法的时候销毁污点标签，此时再传入到危险方法时就不再携带污点标签，也就不会判定为漏洞了。
检测原理：
详细地来说，IAST 通过 Java 的 Instrument 技术将 Agent 运行在 JVM 中，在成功插桩以后 IAST 会对该应用程序进行 Hook。IAST 主要 Hook 的点分为三类：Source、Propagator、Sink。
其中 Source 主要是接受用户传入数据的点，IAST 将不会信任该 Source 的任何数据，因此 IAST 将用户传入的数据标记上污点 tag。
Propagator 顾名思义也就是传播方法，一般而言用户传进来的参数都会经过程序内部逻辑，比如字符串拼接等，这些就被称为Propagator，不管该参数经过了多少Propagator 点，污点 tag 始终都会携带。
当然传播方法中会有一个特定的方法，也就是常说的清洁函数，当参数在传播过程中经过了安全方法或过滤方法（比如 XXE 的setFeature、自研过滤方法等），会将污点 tag 进行清洗、摘除。
在经过上述的流转过程后，一部分数据就会进入 Sink 点，也称为危险方法执行处，如果用户传入的参数此时还携带着污点 tag，证明数据流转过程中没有经过任何安全方法和过滤方法，IAST 将标记为存在漏洞，并将该参数流转的调用链还原，展示相应的传播过程以及堆栈信息。如果污点 tag 此时已经不再存在，则不再判定为漏洞。
通过上述原理，可以得出结论：IAST 对于判定漏洞是否存在的条件要求比黑盒和白盒测试更为严格，因此其准确率更高。
当发现漏洞，IAST 能够支持生成相应的报告，并提供有关漏洞的详细信息，包括漏洞的类型、代码具体位置、严重程度等。IAST 平台还能够提供漏洞修复建议，帮助开发团队更好地进行修复工作。同时，为了进一步提升修复效率，IAST 平台支持项目分组，将开发工作与安全工作协同。
开发人员可以通过登录平台来查看自己所负责的项目概况。这在以前可能需要安全人员逐个分发安全报告，漏洞闭环周期慢且难管理。当下开发人员可以更加便捷地查看项目的安全状况，并采取相应的措施进行修复。这种集中管理的方式提高了团队之间的协作效率，使整个修复过程更加快速高效。
得益于基于污点标记跟踪算法的检测原理，IAST 能在用户手动或自动执行功能测试的同时触发流量，并实时检测安全漏洞，与开发人员原有的工作流程具有良好的集成性，可以与开发环境和持续集成/持续交付（CI/CD）流水线完美集成，是 DevSecOps 中的测试环节的不二之选。
IAST 在插桩时可以获取代码中的所有 API 。在功能测试过程中，它会统计并记录测试中的 API 调用覆盖率。举个例子，一个系统总共有 100 个 API 接口，但 IAST 检测到测试的 API 覆盖率只有 95%。这可能是因为：测试人员没有覆盖到部分 API，安全人员可以进行复测；或 API 已经被废弃，但长期下来代码中没有删除，形成了常说的坏链和死链情况。
这些未覆盖或已经废弃但没有删除的 API，由于长时间没有维护，在设计或实现中可能存在已知或未知的安全漏洞。一旦系统上线后，不法分子就有可能通过模糊测试等技术，发现这些遗留接口的存在。并且利用可能存在的安全问题进行非法入侵等恶意行为，导致隐私数据泄露等严重后果。
通过梳理和报告 API 覆盖率和遗留接口的情况，IAST 可以提醒研发团队及时检查和修复，以避免因未知安全漏洞导致的风险。
微服务架构具有低耦合和强大的可扩展性等特点，随着信息化的发展，受到越来越多企业的青睐。然而，这些流行的架构也带来了安全方面的挑战。漏洞的产生不仅限于代码内部的调用。
传统的 SAST 和 DAST 受限于检测方式，很难覆盖微服务架构中的所有情况。通过 TraceID 技术，IAST 能够跟踪微服务的上下游信息，弥补了流行的微服务架构的安全测试需求，更全面地检测和保护微服务架构的安全。
综上所述，IAST 作为一种主流的应用安全测试技术，它很好地结合和融合了 SAST 和 DAST 的优点，但这并不意味着 IAST 拥有替代 SAST 和 DAST 的能力。相反，IAST 与 SAST、DAST 作用在应用安全生命周期的不同阶段，实现了不同的安全能力，并且相互之间进行能力补充，共同组成了完备的应用安全测试体系。
IAST 采用被动插桩作为核心运行模式，基于污点跟踪算法进行检测。不仅准确率高，而且不会对正常业务产生影响，天然地融入了 DevSecOps 理念，实现了开发、安全、运维工作的深度集成。在安全测试准确率、报告质量以及与软件开发流程的集成性等多个维度都展现出了明显的优势。
推荐阅读
