oss-fuzz-gen：用 LLM 生成 fuzz target，再用 OSS-Fuzz 判分

它要解决的是 fuzz target 的产能问题，不是 fuzzing 引擎的问题

模糊测试的瓶颈很少在引擎。libFuzzer、AFL 这些工具本身已经足够成熟，真正稀缺的是有人愿意为每一个解析入口手写一个能跑起来、能构造出有意义输入、还能被覆盖率反馈驱动的 fuzz target。一个中等规模的 C/C++ 项目往往有几十个对外接口，人工写全几乎不可能。oss-fuzz-gen 针对的就是这一层：让 LLM 读项目代码，产出候选 fuzz target，然后交给 OSS-Fuzz 去编译和跑。README 把定位写得很直白，它是一个用于 fuzz target 生成与评测的框架，覆盖 C、C++、Java、Python 四类真实项目。目标读者是已经在 OSS-Fuzz 体系里工作的人，或者至少熟悉 OSS-Fuzz 项目结构的人。

生成与评测是两段，中间隔着 OSS-Fuzz 的构建系统

流程可以拆成两半。前半段是生成：模型根据项目源码和提示模板产出 fuzz target 源码。README 里能看到提示模板放在 prompts/template_xml 目录下，并且列出了 Default 和 Test-to-harness 两类 Prompt Builder，后者用于从已有测试反推 harness。后半段是评测：生成的 target 被送进 OSS-Fuzz 平台编译运行，与生产环境里最新的数据对比。四个指标分别是 Compilability、Runtime crashes、Runtime coverage、Runtime line coverage diff against existing human-written fuzz targets。注意最后一项是相对量，它衡量的是模型写的 target 比人类已经写好的 target 多覆盖了多少行。这个设计比绝对覆盖率数字更诚实，因为它排除了项目本身规模带来的干扰。README 给出的样本实验日期是 2024 年 1 月 31 日，包含来自 297 个开源项目的 1300 多个 benchmark，结论是成功为 160 个 C/C++ 项目生成了有效 target（有效定义为带来非零覆盖率增长），最大行覆盖提升为 29%。这些数字来自项目自己的实验结果，不是第三方复现。

模型清单读起来像一份供应商适配表

README 列出的支持模型覆盖了 Google 和 OpenAI 两条线：Vertex AI 的 code-bison 与 code-bison-32k，Gemini Pro、Ultra、Experimental、1.5，以及 OpenAI 的 GPT-3.5-turbo、GPT-4、GPT-4o、GPT-4o-mini、GPT-4-turbo，还有 Azure 上的 GPT-3.5-turbo、GPT-4、GPT-4o。这个清单本身就说明了框架的抽象层次：它不绑定单一模型，而是把模型调用当作可替换的一层。对使用者的实际影响是成本结构。生成阶段烧的是 API 调用，评测阶段烧的是 OSS-Fuzz 的构建和运行资源，两者的预算要分开算。README 没有给出单次实验的调用量或费用估算，这部分需要自己按 benchmark 数量和重试次数估。

跑起来之前先看 USAGE.md，README 本身不给命令

这是这个仓库一个明显的信息落差。README 的 Usage 一节没有内联任何命令，只指向 USAGE.md，说明如何运行框架并基于结果生成报告。同样，独立 agent 的执行与评测走的是 agent_tests/readme.md，可以单独跑一个 agent 或一串 agent，不必启动完整实验。这种拆分对做研究的人是好事，对想快速试一下的人是摩擦。仓库里能确认的路径包括 benchmark-sets/all 存放 benchmark 集合、prompts/template_xml 存放提示模板、images 存放示意图。除此之外的具体 CLI 参数、环境变量名、配置文件键名，在给出的材料里看不到，不能凭空补。要上手就得先读 USAGE.md 和 agent_tests/readme.md 这两个文件。

评测报告不公开，这限制了它作为外部证据的价值

README 明确写着这些报告不是公开的，原因是可能包含尚未披露的漏洞。这个决定合理，但后果是外部读者只能看到汇总结论，看不到逐项目的原始数据。README 里那张 2024 年 1 月 31 日的样本结果图，以及 160 个项目、29% 最大行覆盖提升这两个数字，都只能当作项目方的自述。同样，Bugs Discovered 表格里列出的 30 个 bug 和漏洞带有具体链接（cJSON、libplist、hunspell、zstd、gdbm、hoextdown、pjsip、gpac、sqlite3、htslib、libical、croaring、openssl、liblouis、libucl、openbabel 等），其中 openssl 那条对应 CVE-2024-9143。这些链接可以逐个核对，属于可验证的部分；至于生成这些结果的模型组合，表格里几乎全部标注为 Vertex AI，Prompt Builder 以 Default 为主，Target oracle 一栏则出现了 Far reach, low coverage、Low coverage with fuzz keyword + easy params far reach、All、Test identifier 等不同取值。这一栏的信息量其实很大，它说明不同 target 的筛选策略对最终能否发现 bug 有直接影响。

它依赖 OSS-Fuzz，这既是护城河也是天花板

四个评测指标里，编译、崩溃、覆盖率三项都要在 OSS-Fuzz 的生产环境里跑，行覆盖差更是直接以 OSS-Fuzz 里已有的人工 target 为基准。这意味着如果你的项目不在 OSS-Fuzz 上，或者你没有对应的构建配置，这个框架的核心价值会大打折扣，你只能拿到生成的那一半，拿不到判分的那一半。另一个限制是语言和场景。README 说支持 C、C++、Java、Python，但列出的 bug 表格清一色是 C/C++ 项目，说明这条流水线在内存安全问题上的产出证据最充分，其他语言的实证要薄得多。如果你的目标是 Rust 或 Go 项目，这份材料里没有任何支持。作为对比，直接手写 fuzz target 再本地跑 libFuzzer 是另一条路：没有 API 成本，不依赖 OSS-Fuzz，但完全靠人，扩展速度受限于写 target 的人手。oss-fuzz-gen 换来的正是这个扩展速度，代价是把评测权交给了一个外部平台。

维护成本主要落在模型适配和 benchmark 同步上

从仓库结构看，需要持续跟进的至少有两块：一是模型接口，README 的模型清单里同时存在 bison、Gemini 多个版本和 OpenAI 多个版本，供应商改一次 API 就要动一次适配层；二是 benchmark 集合，benchmark-sets/all 引用的是 297 个开源项目的当前状态，上游项目改构建脚本或换依赖，这里就可能失效。许可证是 Apache-2.0，允许商用和修改，但要注意生成阶段调用的模型服务有各自的服务条款，仓库的许可证管不到那一层；另外 README 提到发现的漏洞报告不公开，如果你打算把生成结果对外发布，需要先确认其中是否含未披露漏洞。这些是工程和流程上的判断，具体到你的场景要自己确认，这里不构成法律意见。

谁该用它，谁该绕开

适合的场景是：你的项目已经在 OSS-Fuzz 里，你想知道换一个更强的模型、换一套提示模板能不能让覆盖率再往上走一截，并且你愿意为此付 API 费用和等待构建的时间。这种情况下，agent_tests/readme.md 提供的单 agent 执行路径比跑完整实验更划算。不适合的场景是：你只想要几个能跑的 fuzz target，项目规模不大，或者你的代码库根本不在 OSS-Fuzz 覆盖范围内。这种情况下，手写 target 加本地 libFuzzer 的路径更短，也没有外部依赖。判断标准很具体：打开 USAGE.md，看它要求的运行环境和你的机器是否对得上；再打开 benchmark-sets/all，看你的项目在不在里面。两个都过了，再谈生成。

编辑结论

已经在跑 OSS-Fuzz、并且手上有 Vertex AI 或 OpenAI 配额的安全团队，可以把它当作扩展 fuzz target 数量的实验台；只是想给一个内部 C 库补几个 fuzz 入口的小团队不适合，因为整套评测依赖 OSS-Fuzz 的生产数据，脱离这个平台后四个指标里至少三个拿不到。动手之前先确认两件事：一是 USAGE.md 里当前要求的 Python 版本和依赖能否在你机器上装通，二是你的目标项目是否已经在 OSS-Fuzz 的 benchmark 集合里，否则要先自己补 project.yaml 那一层配置。

官方来源

1. google/oss-fuzz-gen on GitHub
2. Issues
3. License: Apache-2.0
4. README