SAST与DAST如何互补

SAST 与 DAST 的互补关系，核心在于两者观察对象不同：SAST 分析源码、数据流和安全控制，回答“代码中是否存在可疑的输入传播与敏感操作”；DAST 检查运行中的应用，回答“在特定配置、入口和请求条件下，漏洞行为是否能够被实际观察”。因此，二者的结果不能简单互相替代，尤其不能把“DAST 未发现”直接解释为“代码不存在缺陷”。

SAST负责解释代码路径

SAST适合从源头追踪用户可控输入，分析其是否经过解析、验证或规范化，并判断最终是否到达敏感操作。它能够帮助定位输入源、传播路径和安全控制缺口，也能发现某些运行时尚未覆盖的调用点。

但静态告警不等于已确认漏洞。告警可能落在不可达代码、未启用模块或实际条件不成立的路径上。复核时应结合项目模块、配置和调用关系，判断数据流是否真实存在；修复实现仍然告警时，也应先确认规则匹配逻辑与有效调用路径，再决定是否属于误报。

DAST负责验证运行行为

DAST从外部访问正在运行的应用，能够验证入口是否可达、请求是否进入预期处理逻辑，以及漏洞相关行为是否真实发生。它对修复验证尤其重要：在相同环境、请求、数据状态和扫描配置下，对比易受攻击实现与修复实现的响应差异。

DAST的局限在于覆盖范围依赖入口、认证状态、路由和请求条件。易受攻击版本没有告警，可能只是扫描器没有到达对应路径；修复后特定载荷不再触发，也不能单独证明所有入口都已安全。

建立同一条证据链

有效评估应固定项目版本、模块、环境、工具配置、扫描范围和数据状态，每轮只改变一个关键条件。先用SAST定位可疑数据流，再用DAST验证最小化运行场景；对修复版本复测同一入口，并保留源码位置、请求响应摘要、工具原始输出和人工复核理由。

最终结论应区分“已确认缺陷”“未确认告警”“误报”和“覆盖不足”。SAST提供代码层面的解释，DAST提供运行层面的证据，二者只有在同一基线下相互印证，才能形成可复核的漏洞判断与修复结论。