Project Zero 对比 Fuzzilli 与 BigSleep 在 V8 漏洞发现上的表现

Project Zero 定期对比了 Google 用来发现 Chrome JavaScript 引擎 V8 漏洞的两款自动化工具。Fuzzilli 是一款生成式 JavaScript 引擎 fuzzer，BigSleep 则是基于 LLM 的缺陷发现系统。过去六个月里，BigSleep 发现的漏洞数量超过 Fuzzilli（45 个对 37 个），两者报告的具体 bug 重叠率为 25%。由于这种对比方法容易低估重叠程度，我们还做了专门的实验，测试 2023 年以来所报告漏洞的理论重叠率。这些实验估计重叠率约为 60%。无论哪个数值更准确，都有相当一部分漏洞只能由 LLM 或只能由 fuzzing 发现。LLM 能如此迅速地发现这么多漏洞，这非常令人期待，但 fuzzing 和 LLM 仍然是互补的方法。我们建议厂商同时对自己的代码进行 fuzzing 和 agentic 分析，以最大限度地增加在漏洞影响用户之前被报告的漏洞数量。

长期以来，fuzzing 一直被成功应用于 Chrome 或 V8（Chrome 的 JavaScript 引擎）等软件项目来检测 bug。最近，能够阅读、推理和编写代码的强大 LLM 的出现，正在给软件开发和软件安全带来变革性的变化。在已经充分 fuzzing 过的目标中发现了成百上千个新 bug 和漏洞之后，一个自然而然的问题出现了：新的 LLM 与“传统”fuzzer 相比如何？它们开始取代 fuzzer，还是这两种方法互为补充？为了帮助回答这个问题，我们关注三个关键问题：

每种方法在现实世界中能发现多少 bug？ 两种方法之间的重叠是什么？ 由一个系统而非另一个系统发现的 bug 的“形态”是怎样的？

在这篇博文中，我们将范围限定为两个具体系统：Fuzzilli，一款 JavaScript 引擎 fuzzer，以及 BigSleep，一个 agentic 缺陷发现系统。这两个系统都在生产环境中运行，自动寻找新添加代码中的 bug，因此它们具有相当直接的可比性。具体来说，Fuzzilli 在许多实例上持续运行，首批实例通常会在几小时内发现新变更，而 BigSleep 目前每天运行一次，被提示审查新提交，并为其发现的任何 bug 编写 proof-of-concept 测试用例。两个系统都通过 Clusterfuzz 报告 bug，后者会进行基本的崩溃分诊，然后在 Chrome 的问题跟踪器中提交 bug 报告。

我们还将目标限定为 V8，这是一个高性能的 JavaScript 和 WebAssembly 引擎，拥有复杂而成熟的测试和 fuzzing 设置。特别是，Fuzzilli 是一款专门设计的 fuzzing 工具，用于发现这些引擎中的 bug。这些 bug 通常具有复杂的性质，这为比较两种方法在经过充分测试的软件中发现深层复杂 bug 的能力提供了一个有趣的“试验场”。我们将对更广泛的目标、fuzzer 和 agentic 缺陷发现系统进行类似分析留待未来工作。

现在，我们将在专门的一节中逐一探讨这三个主要问题。每一节都会先概述总体方法，然后详细描述方法论（通常以项目符号列出，因此如果你不太关心细节，可以跳过这些块），之后再探讨结果。最后，我们尝试解读结果，以了解 fuzzing 与 AI 的当前状态。

这是最容易分析的部分，尽管有一些我们稍后会看到的注意事项。基本思路是从 Chromium 的 bug 跟踪器（V8 bug 的跟踪之处）查询问题，并从中提取各种统计数据。这尤其容易，因为两个系统各自都有一个专门的 hotlist。我们将分析范围限定在 2026 年 4 月至 9 月的六个月，因为自动化的 BigSleep 流水线今年 4 月才激活。因此，我们的原始数据来自以下两个 bug 跟踪器查询：

Fuzzilli: hotlistid:5433121 created:2026-04-01..2026-09-30 BigSleep: hotlistid:8067258 created:2026-04-01..2026-09-30

由此得到的 bug 报告原始数量为：

BigSleep 小胜。然而，这包括所有类型的 bug，而且 BigSleep 最初还在 V8 中发现了很多配置和集成问题，例如 crbug.com/503869331，其中不安全标志阻止机制尚未正常工作。这些是合理的问题，但与我们的比较关系不大，因为几乎没有现实世界的安全影响。消除这些问题的一个简单方法是专门查看漏洞，将结果限制为 type:vulnerability：

突然 fuzzer 明显胜出？不完全是。这些数据仍然存在一些问题，尤其是重复项和无法处理的报告（例如被关闭为 WAI 的 bug）。乍一看，这似乎很容易解决：只需加入另一个约束，例如 status:(fixed | verified)。不幸的是，事情有点复杂。以 Fuzzilli bug crbug.com/511935486 为例。这个 bug 上的事件基本上是：

该 bug 由 Clusterfuzz 于 5 月 11 日提交并分配给一名工程师 该 bug 由 Clusterfuzz 关闭，因为测试用例当天晚些时候不再复现

因此，这个 bug 没有收到任何开发者交互。这里最可能发生的情况是，这个 bug 是另一个 bug crbug.com/511210507 的重复项，但 Clusterfuzz 没有意识到这一点，因为崩溃签名（从堆栈跟踪推导而来）略有不同。当另一个 bug 得到修复时，测试用例在 Clusterfuzz 上停止复现，于是该问题被关闭。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）