确定性 SAST 与 AI 安全代理如何分工：Snyk VulnBench 2.0 中的覆盖率、Harness 策略与成本

我们探讨 AI 编码代理和 AI 安全 Harness 能发现哪些确定性静态应用安全测试（SAST）无法发现的问题，以及它们会漏掉哪些而 SAST 能捕获的问题。VulnBench 2.0 是一个基准测试集，包含来自 20 个开源 Web 应用的 108 个经过人工精心筛选、攻击者可到达的漏洞，涉及 Go、JavaScript/TypeScript、Python 和 Java；其中 62 个漏洞的数据流跨越多个文件。只有在定位到漏洞的攻击者可控源点和危险汇点，且两者各自在两行以内时，才计为发现该漏洞。我们在同一盲测协议下评估了 9 种产品化配置：Snyk Code 静态分析器、采用 3 种模型与工作量设置的 Claude Code /security-review（其中一种使用 Snyk MCP server）、搭载 GPT-5.6 Luna、Terra 和 Sol 的 Codex Security，以及采用两种模型后端的 DeepSec 扫描器。Snyk Code 达到 82.4% 的宏平均召回率（108 个漏洞中发现 89 个），Claude Code 搭配 Opus 5 并采用 xhigh 工作量设置时达到 79.3%（108 个中发现 85 个）；两者在 28 个漏洞上的结果不同，其中 16 个由前者发现、12 个由后者发现，差异太小，无法据此区分二者。单独使用任何一个引擎都不足够：二者结合后发现了 108 个漏洞中的 101 个，这也是全部 7 种可比配置合并后的上限；此外，AI 配置还报告了至少 7 个真实漏洞，而这些漏洞不在参考集合中，Snyk Code 也未报告。AI 引擎漏掉什么，不仅取决于其模型，也同样取决于其 Harness：如果没有 Claude Code 内置的审查策略，同一模型在该策略排除或限制的漏洞类别中发现了 20 个漏洞中的 16 个，而不是 9 个（在 20 个应用中的 19 个上进行的补充运行）；搭载 GPT-5.6 Sol 的 Codex Security 在文件级定位了 80 个漏洞，但在行级仅定位了 34 个；DeepSec 不依赖模型的文件选择机制，仅为 108 条数据流中的 56 条保留了文件。覆盖率与成本之间的相关性很弱。Harness、测试固件、参考集合和所有运行数据均已公开。