什么是IAST（交互式应用安全测试）？

这篇文章是Contrast Security 的CTO和共同创始人，Jeff Williams于2018年末写的一篇文章，对IAST描述的非常清楚，其中谈到的技术，我们今天还在做。对于IAST的深刻理解，非常值得我们学习。

一、介绍

交互式应用安全测试（Interactive application security testing IAST）是一个在应用和API中自动化识别和诊断软件漏洞的技术。如果从名字的缩写来看，插桩（Instrumented）式应用安全测试或许是一个更好的说法。IAST不是一个扫描器，重要的事说两遍，它不是一个扫描器，IAST持续地从内部监控你应用中的漏洞，在整个开发生命周期中，IAST通过你在开发和测试中使用的工具，实时地提供报警。

IAST最显著的特性是它使用插桩来收集安全信息，直接从运行中的代码发现问题，不是源代码扫描（SAST），也不是HTTP 扫描(DAST)。但那并不意味着你要等到产品上线时才使用它，恰恰相反，你可在IDE中，当开始编写和测试第一行代码时，就使用IAST。

了解IAST在完整的应用安全技术策略中的位置非常重要，有两个主要自动化应用安全的方法，你都要考虑到：

在开发时阻止漏洞

IAST自动地发现应用和API的漏洞，这样可以在开发过程早期就进行修复，成本不会那么高。IAST在检测速度，精确度，流程上都比传统的SAST和DAST有优势，某些IAST还包括开源软件安全分析功能。

在生产阶段检测攻击和阻止漏洞利用

RASP在运行时阻止漏洞被利用，而不是像Web 应用防火墙（WAF）那样通过检查网络流量来阻止攻击。RASP并不仅在精确度和扩展性上优于传统的Web防护方法，还能提供在几分钟内将多个业务系统部署新的防护手段的所需架构。（注：RASP也使用插桩的方法，和IAST技术基本一样，有时会把这两个技术等同。）

我们强烈推荐你把IAST加入到认可的应用安全测试技术名单中，它在2010年出现，许多最大的金融、技术和医疗保健公司已经采用了IAST技术。在本文中，我们将探索如何把IAST集成到整个软件生命周期中，实现最经济的漏洞检测。

二、什么是IAST？

交互式应用安全测试使用软件插桩收集安全信息，并直接从运行中的代码发现问题，以实现自动化识别和诊断在应用和API中的软件漏洞。

IAST可以访问代码本身，能够在每行代码执行SAST，而且，IAST可以访问HTTP流量，也能够在每一次请求和响应时，执行类DAST的分析，因此，IAST的规则是SAST和DAST的一个功能合集。

接下来，我们会探索你使用IAST能够做到的事情，IAST的两个主要能力如下：

• 自有代码安全测试：IAST能够自动化地分析应用和API 中的自有代码，找出以前没有发现的（零 day）漏洞，能够识别很宽范围的漏洞，包括并不限于OWASP Top 10，还有其他更复杂的漏洞。
• 开源软件安全测试：IAST也能用来测试开源库和框架的安全性，一般有两个维度。首先，IAST能识别困扰开源软件的已知漏洞（如CVE发布），其次，IAST能识别开源软件中以前未知的（潜在）漏洞。

01 IAST 探头如何工作

通常，IAST使用类似APM工具的技术，使用安全探头对插桩的应用和API进行调试排错，探头从运行的应用中直接检查安全相关的事件，并传递给分析引擎，引擎重新组装这些事件，识别出代码执行中的漏洞特征。

当一个应用或者API被加载到内存中，应用中的插桩是动态执行的。插桩本身很安全，并被广泛应用到日志、性能测试、及其他目的。许多常见的框架已经在运行时使用隐藏的插桩技术，很可能你已经在应用和API中使用过某种形式的插桩。

现代应用常常在运行时组装，使用依赖注入、动态加载、反向控制等其他技术。因为这个原因，源代码分析只能提供一个局部观察，验证安全最好的方法是直接检查运行时应用，IAST支持这种直接的检测。

IAST安全探头能够从应用中实际地提取任何信息。在许多方面，IAST是SAST和DAST的一个合集，包括代码和HTTP流量的分析，但IAST在它的分析中考虑到很多类型的信息，包括：

代码——IAST能访问所有和应用一起部署的源代码和二进制代码。代码探头对应用中每一行代码做二进制的静态分析，包括库和框架。

HTTP流量——IAST能够看到HTTP请求和响应，使用和DAST非常类似的技术，发现和这些流量相关的漏洞。

库和框架——IAST能看到部署的每一个库和框架，分析应用和API如何使用它们。不仅IAST能够根据已知漏洞（CVE）来评估库，也能识别部分或整体隐藏在库里面的未知漏洞。重要的是，因为IAST能精确知道库里面的哪一部分被应用真正调用，它能够过滤掉从未被调用的和库相关的漏洞。

应用程序状态——IAST能够检查程序执行时的应用状态。例如，IAST能看到调用安全方法时使用的参数来发现弱点，如传递“DES”参数给加密密码构造函数。

数据流——从开始进入应用的时候开始，IAST就追踪不信任的输入数据。这是识别最重要的漏洞种类—注入类漏洞的关键。这个技术，有时称之为“污点追踪”，跟踪真实数据在应用中的流动，非常精确。

控制流——IAST了解应用的控制流，能够识别出应用行为中漏洞的特征。例如如果一个应用要求在每个web服务中，采用service（）方法检查访问控制，这个特征将很容易被IAST发现。

后端连接——IAST能够检查围绕着后端连接的所有细节，如数据库、操作系统调用、目录、队列、套接字、电子邮件和其他系统。IAST使用这个信息识别出架构缺陷和安全缺陷。

配置——IAST能访问应用、框架、应用服务器、和平台的配置，保证正确的安全配置。IAST甚至能查询应用组件的运行时配置，如XML解析器。注意某些平台，如.NET，重度依赖配置来实现安全。

02 IAST分析引擎如何工作

IAST 探头生成一个安全相关事件的数据流，导入进分析引擎，这个引擎能强制实施多个规则。

事实上，IAST为一个程序建立了一个安全护栏，如果探头探测到的数据流，表明程序的行为已经违法越过了这些护栏，就会被报告为漏洞。

IAST常常使用多个不同的信息源来证实一个漏洞，例如，当一个暴露的端点，是non-XHR，或者状态正在改变，或者没有包含token检查，就可以确定是一个CSRF（跨站请求伪造）漏洞。IAST能够访问HTTP请求，分析是否一个交易修改了文件或写到存储设备里，评估是否一个控制流包含一个token检查，通过在漏洞分析中，使用所有这三种类型的数据，IAST得出准确的结果，不会漏报也不会误报。

三、我们为什么需要IAST？

问题很简单，我们在应用安全方面，有大量的问题。但应对这些问题的安全专家有限，全世界几乎有2000万的开发人员。传统的工具要求安全专家和应用一起工作，训练工具，解释结果。这些工具80%的费用是有效使用工具的“人的费用“，没有真正的自动化。

01 “工具困境”不起作用

“工具困境”是指你为工作准备的工具都不是很好用，因此，你不得不运行一系列工具，希望能得到一个好的结果。

在安全领域，十余年来，我们一直在尝试这种“混合”的方法，但确实没什么作用。

想像一下，使用SAST，DAST，还有SCA工具的结果去检测CSRF漏洞的情形：

静态分析:

静态分析工具仅仅能尝试检测没有被token检查保护的数据流，不管他们是状态变更还是通过XHR访问。结果或者是花费大量时间的误报，或者是危险的漏报。

动态分析：

DAST工具能够标记不包含CSRF令牌的表单，但无法知道是否他们在状态变更，因此，结果结果或者是花费大量时间的误报，或者是危险的漏报。

开源软件分析：

SCA工具只能标记含有已知漏洞的库，将会错失所有没有被安全专家暴露和发布的安全漏洞。

运行所有这些工具，浪费时间和宝贵的安全技能。但更重要的是，很难关联安全测试结果。静态工具能够报告源代码行数，动态工具报告HTTP请求，开源工具报告库版本号，没有好的方法来关联这些报告。最好的关联工具减少15%-35%发现结果。因此，如果你有两个工具，每份报告了200个发现结果（对于静态工具，一个保守的估计），你会得到缩减后的340个结果。总之，仅仅合并噪音和不精确的报告是不经济的。

02 传统的应用安全工具和现代软件不兼容

现代软件开发速度更快，正在加速发展。许多项目按周、天，甚至小时的频率来部署代码。不幸的是，像SAST、DAST、模糊测试、人工渗透测试、人工代码检查无法跟上现代软件的速度和规模。

传统应用安全工具的最大挑战是：

· 精确性：传统工具的最大问题是精确度。SAST和DAST产生大量的误报（不是真实的漏洞）和漏报（错失真正的漏洞）。工具不精确的时候，安全专家必须执行手动步骤来解决问题，这个流程耗费大量时间，导致软件开发的很大瓶颈。相比传统工具，IAST有一个巨大的信息优势，精确度的提高意味着开发人员能够直接使用结果，不需要专家介入。

· 兼容性：现代应用，特别是API，基于复杂的框架打造，自动把客户端流量和和功能对应到一起，从复杂的数据结构中解析出结果，如XML，JSON，序列化对象。没有大量定制的情况下，SAST无法跟踪这些路径，DAST无法模拟测试要求的复杂流量，IAST对这些问题具有很好的免疫力，因为它只观察运行时的复杂应用和API。

· 速度：现代软件方法，像敏捷和DevOps，进展得非常快。目标是在开发者和上线之间完全自动化。然而传统的工具花费许多小时去执行一个完全的分析（甚至不考虑使用专家分诊，去除误报）。当一个开发人员在他们的IDE环境中编译和测试代码时，IAST提供及时的反馈。IAST还能和QA一起运行测试，如果发现安全问题，能够马上停止编译。

· 扩展：安全工具必须能够使用多个规则，持续分析应用的整个组成。传统的扫描按顺序运行，无法扩展到整个企业。IAST是一个针对应用安全，完全分布式和持续的方法，意味你所有的应用和API能够被持续并行访问，因此你的安全也就能一直保持在最新的状态。

· 流程适合：IAST位于已经存在的开发工具和流程的顶端，不需要额外的步骤。做正常开发和测试时，IAST在后台运行，因为IAST非常精确，能在不了解漏洞的情况下发现它们，不需要专家，任何人都可以使用IAST做安全测试，生成干净的代码。

四、IAST 架构

既然许多人仍然不熟悉IAST，这里有助于说明IAST和其他类型的安全防护如何配合。

上图显示IAST在NIST的Cybersecurity Framework中的位置。IAST完全集中在应用安全这一行。除了检测和识别漏洞，某些IAST实施能帮助识别和分析应用。

网络到应用全栈中的IAST

使用基于插桩的方法来实现安全，并不限于应用层。安全专家已经认识到，我们可以不再只从外部来检测漏洞，外部的视角，并不能提供足够的上下文信息精准地识别漏洞，从内部做漏洞检测更容易，更精确。这种基于插桩的安全测试（和基于扫描的安全测试对比）趋势正在网络到应用的全栈中实现。

IAST是基于插桩的方法保护应用层。许多其他插桩方式的安全产品也都承认插桩的好处。不管在哪一层，直接访问都比从外部视角来测试，有很大的优势。

既然IAST直接把安全搭建在软件栈中，应用在任何环境下都会非常安全，包括在云、PAAS、VM和数据中心中。

五、部署一个IAST方案

对企业组织，IAST是一个能够横跨整个应用和API组件集，建立持续安全测试的有效方法。使用IAST，组织能在所有的应用组件中，持续并行地执行应用安全测试。

01 保护企业的应用组件集 

许多组织仅仅测试应用组件集中的一小部分，一些组织只测试重要的应用，其他组织的策略是测试所有面向外部的应用。更可能的是，你主要的网站没有受到攻击，而是合作伙伴的网站、一个复杂的移动API、或内网的业务应用受到攻击。这就是为什么保护所有应用和API，甚至非webAPI的重要性。

对许多外部和面向公共的应用，许多组织保留安全测试。事实上内部应用和外部应用的概念，取决于工作安全边界。不幸的是，由防火墙和其他网络安全设备建立起来的边界，已经变得千疮百孔，意义不大。例如，一台员工工作站，被攻击者变成内部的跳板，边界变得无关紧要。考虑测试你的整个应用组件集，包括内部应用。

02 在管道中的IAST 

记住，IAST不像一个扫描器，IAST有效地变成了应用的一部分。它能在应用运行的任何地方运行，包括开发人员的IDE，本地测试服务器，QA机器等。作为CI/CD构建的一部分，在容器中，在云中，你代码运行的任何地方。在整个软件生命周期中，你软件运行的任何地方，你都可以使用IAST。在集成和测试环境，在上线环境，尽早的使用IAST有很多好的理由。

下图描述了一个简单开发管道，使用IAST持续的发现漏洞。

你能够选择在软件生命周期中的哪个阶段使用IAST。因为IAST不需要额外的步骤。IAST和所有软件开发的不同方法兼容。特别适合DevOps，DevOps对工具敏感，需要专家贴身服务很长时间。

03 安装和配置 

安装的过程非常简单，一个典型的IAST方案通常包括两部分，IAST代理，和IAST控制台。你在控制台生成一个账户，下载一个IAST代理，执行分析，发送结果给控制台。

第一步是在你的环境中增加IAST代理，和增加一个库一样，设置环境变量，当你使用应用，IAST代理自动在后台做安全测试，重要的是，你不需要攻击应用，得到安全结果。IAST能被任何人使用，甚至刚开始做开发工作的新人。

IAST控制台让你管理整个应用组件集的安全，并行地处理。管理安全策略，配置安全控制，和其他常见开发工具集成，实现漏洞通知。

04 在开发中部署IAST—流程和集成

在开发中，我们的目标是赋能开发人员发现和修复他们自己的漏洞，提交清洁的代码。但我们必须避免拖累他们，或给出误报结果，浪费他们时间。

IAST是实现这些目标的好伙伴，因为他提供即时反馈，定位准确的代码行，在本地环境中测试。IAST可以通过IDE、或者聊天程序、缺陷追踪、其他软件的集成来报警。因为IAST提供精确的代码行，完整的HTTP请求，完整的数据和控制流，开发者的工作变得容易。他们能够修复代码，使用HTTP请求来再测试，验证问题是否解决，提交清洁代码。

05 在CI/CD和QA环境中部署IAST-流程和集成

在QA环境中，我们保证开发人员已经做了正确的事情，消除了任何漏洞。我们有自信在上线之前，消除了漏洞。万一遇到严重的安全漏洞，我们需要有停止构建的能力。但我们不能放慢构建的速度，也不需要安全专家的介入。

IAST非常适合在QA环境中做安全测试，因为它和你正常的自动化和人工测试一起，在后台自动化执行安全测试。在这个环境中，IAST通过其他CI/CD工具提供通知，也能根据审计和合规的要求，出具报告。

06 生产环境部署IAST

在生产环境做安全测试并不是一个很好的主意。理想情况下，你应该在上线之前很久就修复任何安全问题。然而，常常有许多不再主动开发的传统应用，还有第三方产品，只能在生产环境。我们仍然需要持续保证这些应用没有漏洞，我们也希望知道，是否有新的漏洞会影响这些应用。

虽然没有开发和测试环境中使用的这么普遍，IAST也能有效的使用在生产环境。因为IAST不要求源代码。能够在任何可以安装IAST代理的应用中使用，但也要考虑到IAST的性能问题。虽然速度很快，在开发和测试环境中没有被注意到，在生产中，即使几微秒也无法接受。注意，IAST可以配置，如“取样模式”，能明显地改善生产中的性能，并能随着时间提供很大的安全保护。

六、选择一个IAST方案

在这部分，我们会探索一些当你评估IAST解决方案的时候，你要考虑的关键标准。所有IAST产品工作起来都有区别，你要仔细地评估他们，保证他们能在你的环境中工作。

相关部门

在这个选择的过程中，你要考虑多个不同的部门：

安全部门——安全部门，很显然在漏洞管理中，扮演着一个重要的角色。在整个组织的应用和API组件中，IAST是一个主要的漏洞提供者，应用得好，IAST能够帮助开发在早期消除大多数漏洞，不需要安全部门的介入。

开发团队——开发团队有很大的责任，保证应用和API没有漏洞。开发团队经常有使用安全工具的噩梦经历，也许会怀疑IAST能力，因此关键是确保他们理解IAST的优点，得到他们的支持。

DevOps—— DevOps团队一个重要的工作是推动软件快速上线。这和静态及动态扫描都不兼容，因为他们要花费很长时间来扫描，要求大量工作去消除误报。IAST能帮助DevOps团队把自己的安全做好，提供完全自动化的方法，在安全上很自信地推动代码上线。

管理团队——对应用安全的自信能够帮助管理层做出数字化转型的决定，向DevOps转移，或向云上转移。保证IAST作为认可的应用安全测试技术，能帮助业务转型。

技术考虑

语言支持——不同的厂商支持不同的语言，因此你要保证IAST支持你重要的应用和API正在使用的语言。

框架支持——应用框架和语言同样重要，除非IAST支持你正在使用的框架，否则在检测漏洞方面不会有效。

精确度——你会想使用一个包含一系列真实漏洞的应用，来评估精确度。仔细测试IAST的识别能力，没有误报。使用OWASP Benchmark看到操作详情，来衡量应用安全测试工具的好坏。

扩展性——考虑到应用组件集的数量，包括API，内部应用和产品。是否IAST能够扩展到持续分析所有的应用？达到这个水平需要多少人来支持。

规则集覆盖——寻找一个宽泛的规则集，覆盖你关心的攻击。包括CVE。

可见性——IAST有它自己的仪表盘吗？或仅仅是依赖缺陷跟踪系统。输出什么样的报警，通知、报告？有IDE和CI/CD插件支持吗？

安装——大多数IAST产品安装简单，不要求流程变更。安全可以自动化吗，是否可以被增加到容器和镜像里面，可以自动地支持新的应用？

配置——是否IAST要求复杂的配置，来实现精确的分析？常见的安全控制和规则是否容易地添加到IAST里面？

管理和更新——是否有统一管理的方法更新IAST规则和功能？软件更新是自动化的吗？IAST包含企业级特性，如LDAP集成、强认证、企业级访问控制、数据传输和保存加密、完整的安全日志等？

集成—— IAST提供插件，能够和常见的安全及DevOps工具及管道集成吗？对收集到的数据有完整的API吗？这个API也包含管理员操作的功能吗？

IAST能够快速评估，因为在一个非常短的时间内，你就会知道它是否能在你的应用上工作。你可以只在几个应用上部署IAST，运行测试，得出评估结果。

七、在常见的使用场景中应用IAST

在这部分，我们探索如何使用IAST解决常见的安全问题。一般来讲，IAST能够识别和诊断软件本身的漏洞，不是容器，也不是操作系统或者网络攻击。

每个产品都不一样，但因为IAST可以访问代码、HTTP流量、许多其他的安全信息资源，它能解决一个宽范围的漏洞。

注意下列的IAST发现的漏洞名单包括深入到代码的漏洞（传统上只有SAST能够发现），和HTTP流量的漏洞（传统上只有DAST能发现）

注入—SQL 注入，NoSQL注入，反射式跨站脚本，存储式跨站脚本，路径遍历，命令注入，LDAP注入，XPath注入，表达式语言注入，OGNL注入，, Expression Language Injection, OGNL Injection, Hibernate Injection, 头注入, Java 反射注入，日志注入，不安全代码执行，XML 外部实体注入(XXE)

HTTP 头 – Caching, Anti-Clickjacking Controls, HSTS, 不安全Cookie, Response with Insecurely Configured Content-Security-Policy Header, Response with Insecurely Configured Strict-Transport-Security Header, Response With X-XSS-Protection Disabled, Response Without Content-Security-Policy Header, Response Without X-Content-Type Header, Version Header Enabled

解析 - XML External Entities, Untrusted Deserialization, Parameter Pollution, Regular Expression DoS, Unvalidated Redirect, Use of readLine on Untrusted Streams, Trust Boundary Violation, Unchecked Autobinding

认证 – Insecure Authentication Protocol, Unprotected Connection Strings, Session Cookie Has No 'secure' Flag, Session Rewriting, Expired Session IDs Not Regenerated, Forms Auth Protection Mode, Forms Authentication Cross-App Redirect, Forms Authentication SSL, Forms Without Autocomplete Prevention, Hardcoded Password, Session Cookie Has No 'HttpOnly' Flag, HttpOnly Cookie Flag Disabled

授权 – Cross-Site Request Forgery, Server-Side Request Forgery, Verb Tampering Weakness, Role Manager Protection Mode, Role Manager SSL

加密 – Insecure Encryption Algorithms, Insecure Hash Algorithms, Padding Oracle, Hardcoded Cryptographic Key, Weak Random Number Generation, MAC Validation Disabled

弱配置 – Detailed Error Messages, Event Validation Disabled, Header Checking Disabled, Insecure JSP Placement, Large Max Request Length, Overly Long Session Timeout, Request Validation Disabled, Request Validation Mode Disabled, Tracing Enabled, Tracing Enabled for ASPX, Unsafe XML Decoding, Viewstate Encryption Disabled, Viewstate WCF Exception Details, WCF Replay Detection Not Enabled, WCF Service Metadata Enabled, Weak Membership Configuration

有些IAST产品也包含一个强大的规则语言，允许识别白名单（一直要求的代码执行行为特征）和黑名单（不允许的代码行为特征）安全规则。

使用IAST，确保开发人员提交”清洁”的代码

开发人员使用IAST，在开发环境中，当生成和测试代码时，实时地做安全分析。开发人员必须要做的是把IAST代理增加到本地的服务器环境中，一旦IAST安装好了，开发人员可以做日常的工作和测试，自动或者手动，不用再做一次安全测试。开发人员通过他们使用的安全工具，如Eclipse，IDEA，VisualStudio，Slack，Hipchat，Chrome，JIRA，VSTS等，实时地收到安全漏洞通知。

在部署前，使用IAST提供强大保证

IAST也可以用在QA、测试、CI/CD阶段，保证开发阶段没有漏洞。不管是用来做自动化测试的测试服务器，还是CI/CD构建流程的一部分，只要把IAST代理添加到用来做QA的服务器中。对于完全组装的应用，在QA中使用IAST，是一个有效的最后检查手段，因为它会被配置和部署，这里发现的漏洞需要仔细处理。IAST可以配置成自动化生成缺陷跟踪ticker，或停止软件构建。

使用IAST保证API安全

传统的静态和动态工具不擅长测试API安全，这些工具无法处理复杂协议（JSON，XML，二进制，或其他payload），或者架构中用来构建API的复杂数据流和控制流。大多数API使用软件框架，包含自动化payload解析，对象映射（object mapping）。许多使用注释把数据发送到合适的方法。因为IAST从API内部收集安全信息，和常见web应用工作方式一样，能够很容易识别API漏洞。

使用IAST测试开源软件中已知漏洞

虽然开源软件漏洞常常看起来像洪水猛兽，但事实也许比看到的更严重。有几百万个开源库，但只有有限的安全专家在测试他们。IAST根据CVE库，能自动地分析开源软件漏洞。因为IAST能持续运行，并行地遍历整个应用的组件，在几分钟内检测新引入库中的问题，传统的开源软件扫描器需要重新扫描整个企业。除此之外，IAST能精确地告诉你，在开源软件库中到底调用了哪些代码。平均72%的库只包含在应用程序的编译依赖中，从来没有被应用程序真正调用。IAST能节省您升级不真正带来风险的库的工作。

使用IAST来持续审计和合规

IAST工具支持很宽范围的安全标准，包括PCI DSS，HIPPA，NIST 800-53，OWASP Top 10，OWASP ASVS，DISA AppSec STIG。IAST工具能生成报告，证明应用被完全安全测试过，没有漏洞被发现。因为这些报告任何时候都能生成，能显著的加快审计和合规流程。

使用IAST对传统应用的持续保证

传统应用提出了一个特别的应用安全挑战，常常运行很长时间，但没有大量的开发工作。传统安全过程倾向于在部署之前保证安全，也许不会发现新出现的漏洞。而不是像IAST是一个持续的安全方法，因为IAST能持续运行，并行处理，随着扩展覆盖到整个应用的组件集，其独特的定位可以帮助传统应用。

使用IAST测试开源软件中潜在的漏洞

大多数的开源漏洞还没有被检测到，因为IAST测试你整个软件栈，它能在你所使用的库和框架中，发现这些攻击者已经掌握，但研究者还没有发现的“零day”漏洞。你可以选择挑选其他的库，或贡献一个补丁，或使用RASP阻止漏洞被攻击。

使用IAST加强安全编码指南

虽然IAST使用了大量的漏洞规则，它也能加强你组织自身的安全编码指南。你可以生成“正向”的规则，如“每个API必须调用AccessController.isAuthorized（）方法来授权“。IAST能加强这些规则，给与开发人员即时反馈，告诉开发人员组织是如何实现安全的。随着时间推移，组织能使用这个能力，从负面的“阻止漏洞模型”向正向的“使用企业安全控制”模型转变。

八、IAST和DevOps

软件开发项目向DevOps转变过程中，构建和测试软件的流程加速了，使得SAST和DAST越来越难以使用。IAST格外适合DevOps，因为它赋能开发者得到及时和精准的反馈，不要求任何额外的流程步骤，发现和修复他们自己的安全漏洞。这就最小化了安全工作对开发的影响，明显减少了下游的安全工作。

使用IAST,你和以往一样构建、测试、部署代码，唯一的区别是IAST在后台运行，确保你不会引入任何危险的代码或库漏洞。

如上图所示，IAST扩展性好，非常容易的在几百上千个应用上，并行地持续执行应用安全测试。

九、IAST下一步方向？

IAST在市场上表现良好，有多家厂商和许多大规模部署案例，但仍有明显的创新空间，希望厂商们能扩展语言和框架的支持，提高保护能力，甚至增加对于应用安全行业来说全新的技术。