SAST vs DAST vs IAST：安全测试三兄弟的互补而非替代

应用安全测试里最常见的三个缩写：SAST、DAST、IAST。很多人第一反应是“选一个最强的”，但这是个伪命题——这三兄弟不是竞争关系，而是从不同视角看同一个问题。选谁不取决于谁更先进，而取决于你处在软件生命周期的哪个阶段、想发现哪一类漏洞、能承受多少误报。

一、先看一句话定义

• SAST（静态应用安全测试）：在不运行程序的前提下，扫描源代码/字节码找漏洞，属于“白盒”。
• DAST（动态应用安全测试）：在运行中的程序外部发起请求、模拟攻击，属于“黑盒”，不需要源码。
• IAST（交互式应用安全测试）：在程序运行时从内部插桩（agent），结合运行流量与代码上下文，属于“灰盒”。

理解这三者的关键，是它们各自回答不同的问题：SAST 问“代码里哪里可能出错”，DAST 问“实际运行时能不能被打穿”，IAST 问“这次运行中，哪个数据流真的流到了危险点”。

二、SAST：把问题扼杀在写代码阶段

SAST 直接分析源码（或编译中间产物），不执行程序。优点是能在开发早期、甚至提交代码时就发现问题，定位到具体文件与行号，修复成本低。它覆盖的是“代码可达即能扫到”，不依赖运行时环境。

短板：误报率通常较高，因为它无法判断某段代码在真实业务里是否会被触发；对运行时才暴露的问题（如配置错误、鉴权绕过、依赖库的实际调用链）看不全；需要源码，第三方闭源组件无能为力。

典型场景：CI 流水线里做代码提交门禁，防止明显的注入、硬编码密钥、危险函数调用合入主干。

三、DAST：从攻击者视角验证“真能打穿吗”

DAST 把目标当成黑盒，从外部发送请求、构造攻击载荷，观察响应。它最大的价值是贴近真实攻击——发现的是“运行时确实可被利用”的问题，误报相对少。不需要源码，所以也能覆盖第三方组件、配置层的问题。

短板：通常要到部署之后才能测，发现晚、修复成本高；覆盖面受限于爬虫和测试用例能触达的路径，测不到没被发现的功能点；难以精确定位到源码位置，开发拿到报告往往只知道“哪个 URL 有问题”；对需要登录、多步骤业务流程的场景，配置成本高。

典型场景：上线前的安全验收、对已部署环境做周期性扫描。

四、IAST：运行时插桩，兼顾上下文与真实数据流

IAST 通过在应用内植入 agent（探针），在程序运行时同时观察代码执行与外部流量。它既能看到请求怎么进来，也能看到数据在代码里怎么流转到危险点，因此能给出带完整调用栈的证据，误报通常低于 SAST，定位也精确。

短板：需要能在目标环境部署探针（对生产环境有顾虑）；依赖测试覆盖率——没被执行到的代码就发现不了，所以它常与功能测试/自动化测试绑定；对语言和框架的支持有差异；性能上会有一定开销。

典型场景：配合自动化测试在测试环境跑，既验证功能又同步产出安全结论。

五、三者对比一览

维度	SAST	DAST	IAST
测试对象	源码/字节码（不运行）	运行中的目标（外部）	运行中的应用（内部插桩）
视角	白盒	黑盒	灰盒
介入时机	编码/提交阶段最早	部署后	测试/运行时
是否需要源码	需要	不需要	需要（可插桩）
误报水平	偏高	偏低	较低
定位精度	到文件/行	到 URL/接口	到调用栈/数据流
覆盖依赖	有限（看得到源码的部分）	可覆盖运行时暴露面	受执行路径限制
典型场景	CI 代码门禁	上线前验收	与自动化测试结合

六、为什么是互补而不是替代

把三者放在一起看，会发现它们的盲区恰好互补：

• SAST 看得到代码但不知道会不会被触发；DAST 知道能不能被触发但不知道问题在哪一行；IAST 两者都要，但要求代码被执行到。
• SAST 覆盖早、覆盖广但噪声大；DAST 噪声小但介入晚、覆盖窄；IAST 精度高但要能插桩、要跑得够全。
• 只上 SAST，容易陷入“一堆误报没人修”的疲态；只上 DAST，漏洞往往到上线才暴露；只上 IAST，没跑到的路径就是盲区。

现实的答案不是三选一，而是按阶段编排：早期用 SAST 卡住明显的坏味道与危险模式，测试阶段用 IAST 配合自动化用例做精确验证，上线前后用 DAST 从攻击者视角做外部验收。三者叠加，才构成一个没有明显缺口的应用安全测试闭环。

七、落地时的几个实际问题

1. 误报谁来处理

无论哪种工具，报告没人修就等于没做。要有明确的 triage 流程：谁看、多久内关闭、如何标记“接受风险”。SAST 尤其需要基线管理，否则历史遗留问题会淹没新增问题。

2. 覆盖率比工具品牌更重要

IAST 的发现能力直接取决于测试用例覆盖了多少代码；DAST 取决于爬虫与用例触达了多少接口。上线前先量一下“被测到的比例”，比换一个更贵的工具更有意义。

3. 别把安全测试当成一次性验收

安全测试应该嵌进研发流程持续跑，而不是上线前集中补一次。CI 里跑 SAST、测试环境跑 IAST、定期对生产做 DAST，形成节奏，才不至于每次都靠人肉救火。

4. 关注工具之间的协同

理想状态是三类结果能归并到同一个视图：同一个漏洞，SAST 给代码位置、IAST 给数据流证据、DAST 给可利用性验证。能打通这三者的工具链，价值远大于三个各自为战的孤岛。

八、一张决策清单

• 想在提交阶段就拦住明显漏洞 → 上 SAST，重点做门禁与基线。
• 想验证已部署系统是否真能被攻击 → 上 DAST，重点是覆盖面和登录态配置。
• 想让安全结论跟着自动化测试一起产出、且要精确定位 → 上 IAST。
• 资源有限只能先做一个 → 优先 SAST 建立底线，再逐步补 IAST/DAST。
• 追求“一次选对、永久解决” → 这条路不存在，编排与流程才是答案。

SAST 管“可能”，DAST 管“实际”，IAST 管“具体”——三者合起来才是一张完整的图。