每种方法（DAST 与 SAST）都有其优点和缺点。

例如，DAST 方法更适合评估 XSS 类型的漏洞，因为它实际上能够“在客户端”执行以验证是否确实可以执行（而不是良性反射）。在这种情况下，SAST 在大多数情况下仅限于证明输入从源到接收器（或具有可能的路径）并且可以反映在输出中，但通常无法确认可以执行反射传递 XSS 有效载荷。在这种情况下，DAST 比 SAST 有一些优势。

OTOH，检测漏洞（例如将密码输入以明文形式写入后端日志文件）对于 DAST 扫描器来说几乎是不可能的，但对于 SAST 分析来说是一项易于管理的工作。

因此，IAST（或有时称为混合）可以利用两种方法的优势并帮助管理/减少另一种方法的固有弱点。它还可以通过让一种方法确认另一种方法来帮助降低误报检测率（例如，在 SQLI 的动态测试中确认攻击确实到达了 DB）；通过缩小攻击面来帮助加速测试（例如，如果页面不执行任何 SQL，则无需为 SQLI 测试页面），实际发现可能隐藏的攻击面（即未链接到的子应用程序或页面）在盲人中不容易发现）等。

免责声明：我曾经为此类扫描仪工作并开发过其中一种。

IAST 工具在发现漏洞方面的效率如何？

HP WIRT、带有 Acusensor 的 Acunetix、Contrast Security、Quotium 和 Appscan Enterprise 可以在最适合的情况下发现更多漏洞。是的，我使用对比安全性和 WIRT 比没有 SAST 端功能更快地发现漏洞（请注意，WIRT 通过 SecurityScope 挂钩向 WebInspect 工具内提供反馈，并使 Fortify 能够与 SecurityScope 日志输出合并） ，但我会（并且已经）仅在针对 JEE 应用程序时使用它们的功能。对于 Acusensor，您获得的结果更少，而且仅针对 PHP 应用程序。Quotium 和 Appscan Enterprise 不一定能为 .NET、JEE 或我遇到的任何其他语言增加更多价值——但它们当然也有自己的优势，在正确的设置和设置下。

HP WIRT/SecScope vs. JEE: 9/10
Contrast Security vs. JEE: 9.5/10
Acusensor vs. PHP: 6/10
Quotium or Appscan benefits: 7 or 8 out of 10
HP WIRT vs. ASP.NET: 8.5 out of 10

是否有任何证据表明这些可以比黑盒应用程序笔测试 (DAST) 或源代码审查 (SAST) 找到更多或更少？

有绝对确凿的证据表明这一点，特别是考虑到任何给定的 DAST 评估都存在时间和资源限制。当谈到这个话题时，让我成为一个声音巨人：IAST，无论是严格的（Contrast、Quotium）还是松散定义的（WIRT/SecScope 等）在混合大脑工具之后配置故障注入测试用例时都是巨大的帮助代码理解（这通常涉及 - 至少 - 步行和爬取应用程序的执行流程）。

在 WIRT/SecScope 的情况下，我能够配置并找到我在几种情况下肯定会错过的漏洞——针对 JEE 和 .NET 应用程序，尤其是超过 20 MLOC 且具有大量复杂性的应用程序，尤其是当它们包括作为 SOAP 和/或 REST 接口的 Web 服务。

就个人而言，如果不将 IAST 视为主要的、首次运行的方法，我什至不会对 JEE、.NET 或 PHP 构建的应用程序进行评估。它节省了很多时间并提供了很多关注点。

将 SAST 与 IAST 进行比较：IAST 比 SAST 更快，并且专注于风险管理。即使只有一个 IAST 发现 SAST 可能会或可能不会在未来发现，但在查看控制集差距分析或类似的风险管理问题时，这可能具有巨大的价值。使用 IAST 发现安全漏洞这一事实使得软件弱点具有独特的优势，可以实现更高的优先级。此外，在进一步定制视图、理解代码、设计代码和组合资源时，IAST 发现与 SAST 发现（尤其是基于自定义规则）相结合可以节省大量时间。

将 DAST 与 IAST 进行比较：在我的手中，IAST 只会发现更多，并更深入地了解漏洞，这可能会导致漏洞利用或漏洞利用链更容易/更快。

总之：尽可能早地使用 IAST，并为未来的 SAST（和定制的 SAST）评估提供 IAST 工件。

哪个更好？锤子还是螺丝刀？这一切都取决于问题。鉴于您事先不知道弱点，IARPA 的 STONESOUP 推荐的方法是使用多种工具和多种方法。

NIST 的 Paul Black 在其CrossTalk 2009 年 3 月/4 月的文章中强调了静态分析的优缺点。“当发现新的攻击或故障模式时，必须开发新的测试。静态分析器在这种情况下具有一定的优势……”最重要的是，静态分析器有可能发现罕见的事件或隐藏的后门。由于他们独立于任何特定执行来考虑代码，因此他们可以枚举所有可能的交互。交互的数量往往呈指数级增长，无法进行全面的静态分析和测试执行。静态分析可以专注于交互，而无需测试重新建立初始条件或人为地约束系统以产生所需的交互。更糟糕的是，实际上无法期望黑盒测试能够发现，例如，当用户 ID 为“JoshuaCaleb”时可访问的后门，因为要测试的任意字符串几乎是无限的。”

“测试和静态分析相辅相成。测试的优势在于可能会发现完全意外的故障。可以测试嵌入式系统，即使分析任何可能隐藏在组件中的软件完全不切实际。”

“静态分析不是灵丹妙药。复杂而微妙的漏洞总能打败静态分析器中的推理。完全缺乏审计或加密等重要要求，不能仅从对后期制作工件的检查中合理地推断出来。软件没有弹性或自我监控很容易在安装或操作中出错，但静态分析可能是抵御漏洞的最后一道防线之一。” ... 来自 2008 年 6 月静态分析工具博览会[3] , [4]的作品表明当前的分析仪变化很大。分析器可能对某些弱点产生很少的误报，但对其他弱点产生很多误报。同样，遗漏弱点的比率也有很大差异。分析器也只涵盖了记录的弱点的一个子集[5]。因此，最全面的静态分析将来自仔细使用分析器的组合。

Black 博士领导 NIST 的SAMATE - 软件保障指标和工具评估项目。有关Web 应用程序扫描仪的价格和功能比较，请参阅 SAMATE 的工具调查和 Shay Chen 的 SecTool 页面。全面披露：我是支持 SAMATE 项目的客座研究员。

我正在为编写案例研究 Quotium ( http://www.quotium.com ) 的公司工作，但我会尽量客观地回答！

重点不是发现漏洞，而是能够让开发人员快速修复对您的业务，特别是您的数据（黑客的主要范围）构成真正风险的漏洞。

为什么 ？

当您在发布周期短的敏捷环境中进行开发时。您无法停止执行 SAST+DAST、分析报告、进行结果分类、修复未使用函数中的问题、分析代码（有时位于第三方中）以查明源头、了解误报 ecc 的过程......没时间！

SAST 和 DAST 的主要问题是时间和专业知识。对于这两者，您都需要影响分析和代码修复分析。SAST+DAST 不是敏捷的。

SAST 和 DAST 只了解系统的一侧，它们不会在整体威胁上下文和数据上下文中查看漏洞。IAST 确实如此，因为它跟踪从前端到后端的数据。

真正的 IAST 是一种从头开始构建的工具，专门用于从黑客的角度对代码进行操作。

IAST 使您能够更好地集成到开发过程中。

例如，您将 IAST 工具插入到您拥有构建服务器的位置……一方面，您将自动化测试脚本（例如 selenium）插入错误跟踪工具。您有一个在夜间运行的自动化安全测试过程。

早上，您的开发人员会找到他们的易受攻击的代码列表以及要应用的补救措施、对测试应用程序的攻击的回放视频、不同组件上易受攻击的代码的路径，以便能够修补第三方接口（如果源代码）不可用。

• 开发人员只关注已证明的漏洞
• 测试人员清楚地了解 OWASP Top 10、SANS/CWE、PCI ecc 为 GO/NO GO 量身定制的漏洞风险

在这个过程中获得了很大的时间！

好吧，我不是客观的，但这就是它的工作原理:)

客观地说：

只有 2 个工具被创建为 IAST：Quotium 的 Seeker 和 Aspect 的对比。

所有其他供应商都试图合并单独的工具以用于营销目的，但它们是 DAST+SAST 而不是 IAST！

我们有客户将 IAST 实施为一个连续的过程，并继续拥有用于审计的 SAST 工具。

SAST 帮助您进行更好的安全编码实践。IAST 在 SAST 之后仍然会发现漏洞，但如果这段代码没有被易受攻击的进程触及，IAST 不会突出不安全的编码实践。

所以你可能会更好地做 IAST+SAST 比 DAST+SAST ！