G.O.S.S.I.P 特别推荐 2026-11-15 FuzzAnything: 下一代OSS-Fuzz，为代码迷宫打开更多入口

安全研究GoSSIP · 2026-11-15 16:20 · 1 阅读

原创 yunlong 2026-11-15 16:20 上海

FuzzAnything——为每个人都提供最好的智能模糊测试技术，平台开放申请中！！！

大家好，我们是香港大学 Chen Ho 教授课题组，今天我们要给大家介绍的是我们最近的一项非常有趣的研究工作——FuzzAnything：随着近年来大模型能力阶跃式的提升，在漏洞挖掘任务上的效果越来越显著。但随着顶尖模型的安全护栏不断收紧、对敏感请求的拒绝愈发频繁，即使是出于善意的安全研究，也可能因无法获得必要的模型支持而难以继续开展。为此，我们将近一年来在 Fuzzing 领域积累的研究成果整合为平台，承担运行所需的算力与运维成本，并逐步开放测试结果与相关研究数据，让更多研究者能够以更低的门槛使用和探索前沿漏洞挖掘技术。

以下是FuzzAnything的详细介绍

如果把编写代码比作建造一座建筑，那么软件测试就是检查这座建筑，来看哪些房间的结构存在问题，哪些通道会在特定条件下失效，哪些不起眼的角落藏着安全隐患。然而，一个真实代码库远比普通建筑复杂。函数之间相互调用，数据在不同模块之间流动，同一段代码在不同状态下又会表现出不同的行为。它更像一座巨大的、会随着状态变化而呈现不同通路的迷宫。

我们要寻找的缺陷，就藏在这座迷宫之中。模糊测试就是探索这座迷宫的方式，通过向程序提供不同的输入，让它实际运行起来，沿着执行路径寻找崩溃或其他异常。但问题在于：如果测试根本没有走进某片区域，我们又该如何发现那里的问题？

FuzzAnything 的使命由此展开：

Make anything be fuzzable and make any code be fuzzed.
让任何对象都能被模糊测试，让每一段代码都得到模糊测试。

前半句关乎可测试性，让原本难以接入 Fuzzing 的对象拥有可运行的测试入口。后半句关乎探索的广度与深度，让测试持续走向尚未执行到的代码。这两句话也是我们自2022年起在腾讯就已开展的研究方向（见【G.O.S.S.I.P 阅读推荐 2023-11-08 Fuzz Anything】）。

迷宫探索，首先取决于从哪里进入

模糊测试，也就是 Fuzzing，会持续生成、变异并执行大量测试输入，观察程序是否出现崩溃、内存错误等异常。对一个软件库而言，这个过程通常需要一段连接测试输入与库接口的代码，即Fuzz Harness，也称测试驱动。Fuzz Harness 负责准备环境、创建对象、调用接口，并把测试输入送进目标代码。在迷宫的比喻里，它是一扇入口，入口的质量决定着探索者能否顺利进入、能够抵达哪些区域，以及能否深入那些隐藏着缺陷的角落。

OSS-Fuzz 接入文档：https://google.github.io/oss-fuzz/getting-started/new-project-guide/

以 OSS-Fuzz 的常规接入流程为例，项目需要集成一个或多个 fuzz target，再由基础设施持续构建和运行测试。这使得对开源软件开展持续 Fuzzing 成为可能，也让测试入口的设计成为影响探索范围的重要因素。但即使现代 Fuzzer 会利用覆盖反馈机制来保留能触达新代码的输入，继续变异、探索，测试的深度和广度仍然大幅度受到入口和路径条件的限制。

第一种限制，是有些区域没有被现有入口连接起来。

一个库可能同时提供读取、写入、转换、流式处理等能力，而已有 Harness 只调用其中一部分接口。对于没有被调用链连接起来的功能，再多的输入变异也无法凭空补出缺失的调用。人工编写入口需要理解接口、准备数据并维护构建环境，投入有限时，测试自然容易集中在少数主要功能上。

这就像一座有许多区域的建筑只开放了几扇入口。有的区域从这些入口出发根本没有通路。

第二种限制，是有路可走，却很难满足沿途的通行条件。

有的功能要求先创建对象、完成配置，再按照特定顺序调用接口；有的路径只有在输入格式、参数关系和内部状态同时满足条件时才会出现。测试可能已经调用到一个函数，却长期停留在参数检查或浅层逻辑附近。

这相当于走到一扇门前，却一直没有准备好开门需要的钥匙。在入口保持不变的情况下，持续增加测试次数，也未必能解决缺失的状态准备。

下面的动画展示了目前基于OSS-Fuzz的持续性模糊测试的局限性。它们从同一个入口出发，沿不同分支探索，随后在未满足的条件前停下。这展示了固定入口下的两类局限：(1) 有些代码虽有通路，却难以被当前测试深入执行；(2) 另一些功能没有被 Harness 的调用链连接起来，持续变异输入也无法让它们自动进入测试范围。

图 1：基于 OSS-Fuzz 的持续性模糊测试的局限性。每个阶段叠加展示多条执行轨迹，轨迹停止后汇报相应的调用或输入条件。图中区分入口未连接与路径条件受阻两种情况，仅为概念示意。

一个实际例子：已经调用了压缩函数，为什么仍然走不到某段代码？

下图关于 zlib 的示例很好地说明了这个问题。图（a）中已有 Harness 调用了 deflate，但没有建立用户自定义 gzip 头所需的状态，相关路径因此始终没有得到执行，导致对压缩函数 deflate 测的很浅。仅仅继续变异待压缩的数据，无法补上缺失的 API 调用。

而要解决这个问题，我们需要做是的中通过分析覆盖阻碍，自底向上分析当前模糊测试探索被阻塞的原因，将问题关联到同一模块下的 解压头设置 功能（图(b)展示了这一过程）。需要先通过 deflateInit2 选择 gzip 编码模式，再于首次 deflate 之前使用 deflateSetHeader 设置自定义头，同时准备对应的对象、缓冲区与生命周期。这让测试得以探索原先入口没有建立起来的状态。

回到迷宫的比喻里，这次推进来自识别门为何打不开，再准备正确的钥匙，而不是在知道自己拿的钥匙不对的情况下，就想暴力的把门锁打开。

让智能体参与，让测试随着反馈演进

FuzzAnything 让Agent参与进来，先解决模糊测试构建/插桩难的问题，实现对目标的一键式测试，然后将入口构造、测试执行与反馈分析组织为持续运转的过程。智能体理解目标项目，构造测试入口，调用Fuzzer进行路径探索，再从运行结果中判断哪些地方仍然难以到达，并据此修改或增加 Harness。对于 Fuzzing 过程中产生的 crash，我们进行复现与根因分析，结合 API 使用约束和运行时状态，区分 Harness 误用与目标代码中的真实缺陷，来持续进行改进，从而实现进化式的模糊测试。

进化式模糊测试

在迷宫中，这意味着把“下一扇入口应该开在哪里、进入前需要准备什么”也交给系统探索。

入口数量只是过程中的一个维度。真正有价值的入口，需要连接新的功能、建立此前缺失的对象状态，或让测试越过一直阻碍探索的条件。多个写法不同却覆盖相同浅层逻辑的 Harness，并不能充分推进这一目标。

因此，智能体需要反复完成几个相互关联的判断：

哪里还没有被测试？
从覆盖信息中寻找尚未充分探索的模块、函数与分支。
为什么走不到？
结合代码与执行反馈，定位缺失的调用、对象状态或参数条件。
怎样建立有效入口？
构造相应的 API 调用与数据准备过程，生成或修改 Harness。
这次改动是否有效？
编译、运行、测试并检查结果，再用新的反馈指导下一轮探索。

我们所说的“自演进”，发生在这些具体的测试方案、Harness 和探索策略上：系统把每一轮执行中学到的东西用于下一轮，让测试过程能够持续调整。

下面的动画沿用前面的迷宫。智能体根据每轮探索的反馈，补齐调用条件，在外墙上分批打开新的有效入口。多组测试从不同入口出发，已有入口也随反馈得到改进，让执行轨迹逐步延伸到原先无法触达的区域，最终探索图中的大部分空间。

图 2：FuzzAnything 的进化式模糊测试概念图。每轮先准备并校验调用条件，再建立入口、展开探索；浅青色区域记录已经走过的位置，少量灰色区域仍待探索。

打开入口，需要理解 API 的使用规则

为软件库构造一个有效 Harness，包含大量领域知识。函数名和参数类型只是起点，真正决定测试能否深入的，往往是接口之间、参数之间，以及对象生命周期中的依赖关系。

API 之间的依赖，决定一组调用在语义上是否成立。 构造 Harness，需要理解每次调用建立了哪些条件、改变了哪些状态，以及后续调用是否仍然满足接口约定。这些关系涉及对象归属、状态转换、数据解释与引用有效性，往往无法仅从函数签名和参数类型中看出来。

同一个 API 内部的约束，决定参数组合是否符合接口契约。 每个参数的类型正确，并不意味着它们可以任意组合。这要求系统理解参数之间的条件关系，并在构造测试数据时共同维护这些关系。独立地生成各个参数再拼接起来，很容易形成类型正确、语义错误的调用。

这些依赖的正确性，直接关系到漏洞报告的可信度。 违反调用契约的 Harness 也可能触发越界访问、悬空引用等内存错误，甚至让崩溃栈落在目标库内部。若把测试代码误用接口造成的崩溃直接归为目标库的缺陷，就会产生虚假的漏洞报告。因此，Harness 能编译、能运行，甚至触发了崩溃，都不足以说明测试有效。

这一块的处理，可以参考我们先前的研究工作，Hopper（CCS 2023）通过解释执行与反馈学习，探索 API 内与 API 间的约束，让库能正确的捕捉API间和API内的隐式依赖。PromptFuzz（CCS 2024）使用大模型结合动静态程序分析技术，来保证生成harness的合法性。

从执行输入，到持续扩展可测试的空间

这也是我们理解 AI 时代 Fuzzing 的方式，让系统既能探索测试输入，也能持续改进承载这些输入的测试入口。

让专业 Fuzzing 引擎负责高频执行与输入变异，也让智能体理解代码和 API 的语义，诊断探索阻碍，并调整测试方案。两者通过反馈连接，使“可以测试什么”本身成为持续探索的对象。

这一方向已经有多种实践，包括 OSS-Fuzz 团队开展的自动化测试入口生成工作 OSS-Fuzz-Gen【https://github.com/google/oss-fuzz-gen】。FuzzAnything 希望进一步推进的是从项目理解、入口构造、执行反馈到结果验证的完整过程，让这些环节能够相互提供信息并持续改进。

我们今年4月份在DeepSeek V3.2上对FuzzAnything和其他baseline进行了评估，进行了非常扎实的实验，对于每个使用LLM的baseline都独立执行24h预算下的5轮实验，对于每轮生成的fuzz harnesses都额外进行5轮24h的fuzzing，来充分抵消LLM和fuzzer随机性的影响。

总体结果如下图所示：在 20 个开源库的评估中，FuzzAnything 的底层引擎 FuzzAgent 覆盖的分支总数比 OSS-Fuzz 提高 49.3%（在OpenSSL等大库上，24h过于有限，距离覆盖率瓶颈其实还很远~），约为 OSS-Fuzz-Gen 的 3 倍；平均每个库的 LLM 调用成本为 3.17 美元，共发现 102 个此前未知的缺陷，其中 90 个已获上游确认或修复。

在近期我们更换了更强的模型GLM-5.2之后，仅替换模型就可以在这些目标库上实现18.13%的覆盖率提升，同时大幅度提升Crash Triage的准确率（约90%+）。如下图所示，我们已经在一些库上实现了将近饱和的代码分支覆盖率。

开放平台，邀请你一起探索代码迷宫

FuzzAnything 已向社区开放。依托我们的 GPU 集群与专用服务器，截至下图所示的 2026 年 11 月 12 日，平台已对包括 Linux kernel、Chromium 在内的 541 个代码仓库开展持续模糊测试，累计获得 超过 2,400 条去重后的代码库崩溃记录。随着每一轮测试的推进，这一数量还在不断增长。

FuzzAnything 平台的持续测试与崩溃记录概览

虽然我们在平台上也实现了根因分析，可以直接copy漏洞报告到上游社区，并提交验证过的patch。但因为还仍有小部分的误报情况，为了避免提交错误结果到开源社区，仍需要一定的人类工作量进行最终的确认，来减少开源社区被AI slop冲击下的负担。目前积累的结果，已经超出了研究组能够及时逐一深入分析的能力。我们希望邀请更多研究者和开发者参与，一起核实问题、完善报告并推动上游修复。

为此，我们按照 Responsible Vulnerability Disclosure（负责任漏洞披露）策略（https://fuzzany.org/disclosure），分级开放结果与协作：

Tier 1：涉及潜在高危安全影响的发现。
相关材料仅在授权范围内供安全审核者和项目维护者使用，完成人工复核与影响评估后，通过上游的私有安全渠道协调处理，并遵循披露时限公开结果。欢迎有安全分析经验的研究者联系我们，参与审核。
Tier 2：经评估不符合 Tier 1 标准的功能性与工程质量问题。
注册账号并接受责任条款后，社区用户可查看相关报告、下载崩溃触发输入，参与复现、补充根因分析和修复进展。问题核实后，请通过上游公开的问题跟踪系统提交报告。

我们承担平台持续运行所需的算力与运维成本，也希望把测试结果和相关研究数据向更多人开放。欢迎使用平台探索测试数据、参与问题复核，或基于已开放的数据开展自己的研究；有意参与 Tier 1 安全审核的研究者，可通过平台邮箱（fuzzanything@gmail.com）与我们联系。

我们后续持续将近期的研究工作进行集成和开源，包括Linux内核模糊测试智能体、浏览器模糊测试智能体、高效模糊测试驱动最小化和形式化漏洞能力分析等工作，供安全研究免费使用，希望能够和大家一起来探索在AI时代下可靠软件安全的道路。

回到最初的代码迷宫，我们希望用智能体打开更多有效入口，也让更多人参与验证与修复，让尚未触达的代码得到测试，让已经发现的问题得到处理。

最后，欢迎大家使用我们的平台和研究内容，Make anything be fuzzable and make any code be fuzzed.