AI驱动模糊测试：用oss-fuzz-gen自动生成高质量测试目标

1. 项目概述与核心价值

如果你是一名从事软件安全、质量保障或者底层系统开发的工程师，那么“模糊测试”这个词对你来说一定不陌生。它就像给软件做高强度、无规则的“压力测试”，通过向程序输入大量随机、变异的数据，试图触发那些隐藏在角落里的崩溃、内存错误或逻辑缺陷。传统的模糊测试，无论是基于变异的还是基于生成的，其效率和深度很大程度上依赖于安全研究员对目标代码的深刻理解和手动编写的“模糊测试目标”。这个过程既耗时又需要极高的专业性，成为了大规模、自动化漏洞挖掘的一个主要瓶颈。

最近几年，我一直在关注如何将大语言模型应用到实际的工程和安全实践中。当看到 Google 开源的这个oss-fuzz-gen框架时，我意识到一个拐点可能真的来了。这个项目的核心目标非常明确：利用大语言模型，自动为真实世界的 C/C++/Java/Python 项目生成高质量的模糊测试目标，并通过成熟的 OSS-Fuzz 平台进行自动化评估和验证。简单来说，它试图用 AI 来替代或辅助安全专家完成那部分最耗时、最需要经验的工作——编写有效的 Fuzzing Harness。

这个框架的价值在于，它不是一个停留在论文里的概念，而是一个已经投入实战并取得显著成果的工具。根据其官方数据，在 2024 年 1 月的一次大规模实验中，该框架成功为 160 个 C/C++ 项目生成了有效的模糊测试目标，其中一些目标甚至将代码行覆盖率提升了 29%，远超已有的人工编写目标。更令人印象深刻的是，通过这些 AI 生成的测试目标，已经发现了至少 30 个全新的、人工编写目标无法触达的安全漏洞，包括内存越界读写、释放后使用等高风险问题，其中一些已被分配了 CVE 编号。

对于安全研究员、开源项目维护者，甚至是追求更高代码质量的开发团队而言，oss-fuzz-gen提供了一个全新的武器。它降低了模糊测试的门槛，让那些缺乏专职安全专家的项目也能享受到顶级模糊测试基础设施的红利。接下来，我将结合自己的理解和实践，深入拆解这个框架的设计思路、使用方法、核心技巧以及背后的考量。

2. 框架架构与核心设计思路拆解

要理解oss-fuzz-gen的强大之处，我们不能只把它看作一个“调用 LLM 的脚本”。它是一个精心设计的、端到端的自动化系统。其核心设计思路可以概括为：将模糊测试目标的生成问题，分解为一系列可由 LLM 驱动的、可评估的“智能体”任务，并通过严格的、生产级别的指标进行闭环验证。

2.1 核心工作流解析

整个框架的工作流可以清晰地分为几个阶段，我将其归纳为“分析-生成-编译-运行-评估”的闭环。

第一阶段：目标分析与上下文构建。这是整个流程的起点，也是决定生成质量的关键。框架不会盲目地将整个项目代码扔给 LLM。相反，它会先对目标项目进行静态分析，提取关键信息，例如：

• 项目结构：识别主要的头文件、源文件目录。
• API 接口：通过分析函数声明、文档注释，甚至现有的单元测试，来识别出可供模糊测试的函数。这些函数通常具有明确的输入输出，并且是库的核心功能。
• 编译依赖：分析项目的构建系统（如 CMakeLists.txt, Makefile），确定编译模糊测试目标所需的所有库和标志。

这个过程的目标是为 LLM 构建一个精准、简洁的“上下文窗口”。LLM 的上下文长度是有限的，我们必须把最相关的信息喂给它。框架会智能地打包这些信息，形成一个结构化的“提示词”基础。

第二阶段：提示词工程与目标生成。这是 AI 发挥核心作用的地方。框架内置了多种“提示词构建器”，它们负责将第一阶段收集的上下文，格式化成 LLM 能够理解并有效执行的指令。例如，一个典型的提示词可能包含：

• 任务描述：“你是一个专业的模糊测试工程师，请为以下 C 函数编写一个 libFuzzer 兼容的模糊测试目标...”
• 函数签名与文档：提供目标函数的精确声明和官方文档片段。
• 代码示例：提供该项目中其他模糊测试目标或单元测试的例子，作为风格参考。
• 约束条件：明确要求，如“必须使用LLVMFuzzerTestOneInput函数入口”、“妥善处理可能为空的输入指针”、“避免调用exit()”等。

框架支持多种主流 LLM，包括 Google 自家的 Vertex AI Codey/Gemini 系列和 OpenAI 的 GPT 系列。你可以根据成本、速度和效果进行选择。生成的结果就是一份完整的、理论上可编译运行的 C/C++/Python/Java 源代码文件。

第三阶段：编译与集成。生成代码只是第一步，能否融入现有构建体系才是难点。oss-fuzz-gen巧妙地利用了 OSS-Fuzz 的标准化基础设施。它会将生成的模糊测试目标文件，按照 OSS-Fuzz 的项目规范，放置到正确的位置（通常是projects/<project-name>/目录下），并尝试利用项目已有的 Docker 构建环境进行编译。这一步会自动检测语法错误、链接错误等编译期问题。

第四阶段：运行时模糊测试与数据收集。编译成功后，框架会驱动 OSS-Fuzz 的模糊测试引擎（如 libFuzzer, AFL++）对生成的目标进行实际运行。这个过程会持续一段时间，并收集关键运行时指标：

• 崩溃报告：任何导致程序异常退出的输入都会被记录下来，这是发现漏洞的直接证据。
• 代码覆盖率：收集行覆盖率、函数覆盖率、分支覆盖率等数据。这是衡量模糊测试目标有效性的核心指标。
• 执行速度：记录每秒可以执行多少次测试用例，效率过低的目标实用性会大打折扣。

第五阶段：评估与报告生成。这是形成闭环的一步。框架会将新生成目标的运行结果，与项目已有的人工编写目标进行对比分析。评估主要基于四个量化指标：

1. 可编译性：生成的目标能否成功编译？这是最基本的门槛。
2. 运行时崩溃：是否触发了新的、独特的崩溃？
3. 运行时覆盖率：达到了多少绝对代码覆盖率？
4. 覆盖率提升：相比已有目标，新增的代码覆盖率是多少？（这是衡量其“价值”的关键）

最终，所有这些数据会被汇总成一份详细的报告，清晰地展示每个 LLM、每种提示词策略在不同项目上的表现，从而指导后续的优化。

2.2 设计背后的“为什么”

理解了流程，我们再来看看几个关键设计选择背后的逻辑：

为什么基于 OSS-Fuzz？OSS-Fuzz 是 Google 维护的、业界最权威的持续模糊测试平台，它为数百个关键开源项目提供免费的、大规模的模糊测试服务。基于它意味着：

• 标准化：无需自己搭建复杂的模糊测试集群，直接复用其成熟的 Docker 环境、构建脚本和运行管理。
• 可比性：评估结果与生产环境完全一致，得出的结论（如覆盖率提升）具有极高的可信度。
• 生态整合：发现的漏洞可以通过 OSS-Fuzz 的标准流程直接报告给维护者，形成从发现到修复的完整通路。

为什么采用多模型、多提示词策略？不同的 LLM 在代码生成、逻辑理解上各有优劣。同一个模型，用不同的方式提问（提示词），得到的结果也可能天差地别。oss-fuzz-gen支持多种模型和提示词构建器，本质上是在进行一场大规模的“自动化评估实验”，旨在 empirically（基于实证）找出针对“模糊测试目标生成”这个特定任务的最优组合。这种数据驱动的思路，比单纯依赖某个“最强模型”的直觉要可靠得多。

为什么强调“覆盖率提升”而非绝对覆盖率？一个项目已有的模糊测试目标，往往是经过安全专家精心打磨的，已经覆盖了容易想到的路径。AI 生成目标的价值，在于它能发现人类忽略的“死角”。因此，“覆盖率提升”这个指标比“绝对覆盖率”更能体现 AI 的补充价值。提升 1% 的覆盖率，可能就意味着发现了一个全新的、复杂的攻击面。

3. 实战部署与核心配置详解

看懂了原理，接下来我们动手把它用起来。oss-fuzz-gen的部署和使用有一定的门槛，主要集中在环境依赖和配置上。我会结合自己的踩坑经验，带你走通全流程。

3.1 环境准备与依赖安装

首先，你需要一个 Linux 环境（Ubuntu 20.04/22.04 是官方推荐且测试最充分的）。Windows 和 macOS 可以通过 WSL 或虚拟机实现，但直接操作可能会遇到更多依赖问题。

第一步：获取源代码。

git clone https://github.com/google/oss-fuzz-gen.git cd oss-fuzz-gen

这是所有工作的基础。

第二步：安装系统级依赖。框架的运行依赖于 Python、Docker 以及 OSS-Fuzz 的基础设施。官方推荐使用它们提供的脚本，这能避免很多版本冲突问题。

# 安装基础工具，如 curl, git, python3-pip 等 sudo apt-get update && sudo apt-get install -y curl git python3-pip # 运行环境准备脚本。这个脚本会检查并安装 Docker、Go 语言等必要组件。 # 注意：这会以 root 权限运行，建议先查看脚本内容。 ./infra/helper.py check_build

注意：Docker 的安装和配置是关键。确保当前用户有权限执行docker命令（通常需要加入docker用户组）。运行docker ps测试一下，如果提示权限错误，执行sudo usermod -aG docker $USER后重新登录。

第三步：配置 Python 虚拟环境。强烈建议使用虚拟环境来管理 Python 依赖，避免污染系统环境。

python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt

requirements.txt包含了框架运行所需的核心 Python 库。

3.2 核心配置文件解析

框架的行为由一个核心的配置文件控制，通常是一个 YAML 或 JSON 文件。理解并正确配置它是成功运行实验的关键。以下是一个简化但关键的配置示例：

# experiment_config.yaml fuzzing_benchmark: 'path/to/benchmark/set' # 指向你要测试的项目集合定义 llm_models: - name: 'gpt-4' provider: 'openai' api_key: ${OPENAI_API_KEY} # 建议使用环境变量，避免密钥泄露 - name: 'gemini-pro' provider: 'google' api_key: ${GOOGLE_API_KEY} prompt_builders: - 'default' # 使用默认的 XML 模板提示词 - 'test-to-harness' # 尝试从现有单元测试转换 agent_oracle: 'all' # 使用哪些“目标预言”来筛选要测试的函数 evaluation_metrics: - 'compilability' - 'coverage' - 'crash' - 'coverage_diff' experiment_output_dir: './results/$(date +%Y%m%d)'

关键配置项解读：

1. fuzzing_benchmark：这是实验的“靶场”。它指向一个目录，里面定义了你要测试哪些开源项目。框架自带了一些预定义的集合，如benchmark-sets/all包含了 1300+ 个目标。你也可以创建自己的集合，只针对你关心的几个项目进行测试。
2. llm_models：指定要使用的模型列表。你需要提前在对应的云服务平台（OpenAI, Google AI Studio, Azure）上创建账户并获取 API 密钥。成本提示：大规模实验会消耗大量 Token，尤其是 GPT-4 这类模型，运行前最好预估一下成本。
3. prompt_builders：提示词构建策略。default是通用策略；test-to-harness是一个有趣的策略，它尝试分析项目现有的单元测试代码，将其“转化”为模糊测试目标。不同策略在不同类型的项目上效果可能不同。
4. agent_oracle：“智能体预言”。这是一个高级概念，它决定了框架如何从项目中“挑选”出值得进行模糊测试的函数。选项如far reach, low coverage会优先选择那些在现有覆盖中调用深度较深但自身覆盖率低的函数，这往往是漏洞的藏身之处。all则尝试覆盖所有可能的函数。
5. evaluation_metrics：指定要收集哪些评估数据。通常全选即可。

3.3 运行完整实验流程

配置好后，运行一个完整实验的命令相对简单：

python -m src.main --config experiment_config.yaml

这个过程会非常漫长，因为它会串行或并行地（取决于配置）为每个项目、每个模型、每个提示词策略生成目标、编译、运行并评估。一个包含几十个项目的小型实验可能就需要数小时甚至数天。

实操心得：

• 从小处着手：千万不要一开始就用benchmark-sets/all。先创建一个只包含 1-2 个你非常熟悉的小项目（比如cJSON）的测试集，验证整个流程是否能跑通。
• 监控与日志：框架会生成详细的日志文件。运行过程中，多关注logs/目录下的输出，特别是编译错误和运行错误的日志，这能帮你快速定位问题是出在环境、配置还是生成的代码本身。
• 管理 API 成本：在配置中可以为每个模型设置max_tokens和请求频率限制。对于实验性运行，可以先使用gpt-3.5-turbo或gemini-pro这类成本较低的模型进行流程验证。
• 结果解读：实验结束后，结果会输出到experiment_output_dir指定的目录。里面会有 CSV 格式的汇总报告、每个目标的详细日志和覆盖率报告。重点关注coverage_diff为正数的目标，它们就是有价值的产出。

4. 高级技巧：独立智能体执行与问题排查

除了运行端到端的大实验，oss-fuzz-gen框架还提供了一个更灵活的模式：独立智能体执行。这允许你像调用一个函数库一样，使用框架的各个组件。这对于调试、定制化生成或集成到其他流水线中非常有用。

4.1 独立生成与测试单个目标

假设你只想为某个特定函数生成一个模糊测试目标，并手动测试它，可以这样做：

# example_agent_usage.py import sys sys.path.append('.') # 确保能导入框架模块 from src.agents import generation_agent, compilation_agent, running_agent from src.utils import project_loader # 1. 加载特定项目 project = project_loader.load_project('cJSON') # 2. 选择目标函数（例如 cJSON_Parse） target_function = project.find_function('cJSON_Parse') # 3. 使用生成智能体 prompt_builder = 'default' llm_model = 'gpt-4' generated_code, metadata = generation_agent.generate_fuzz_target( project=project, function=target_function, prompt_builder=prompt_builder, llm_model=llm_model ) print(f"Generated code for {target_function.name}:\n{generated_code}") # 4. （可选）使用编译智能体进行本地编译检查 # 这需要配置好项目的 OSS-Fuzz 构建环境 # compile_result = compilation_agent.compile_target(project, generated_code) # 5. （可选）使用运行智能体进行本地模糊测试 # run_result = running_agent.run_fuzzer(project, compile_result['harness_path'])

这种方式让你可以精准控制输入和输出，方便进行提示词调优或结果分析。

4.2 常见问题与排查实录

在实际操作中，你几乎一定会遇到各种问题。下面是我总结的一些典型问题及其解决方法：

问题一：Docker 构建失败，提示“找不到基础镜像”或“构建脚本错误”。

• 原因分析：OSS-Fuzz 为每个项目维护了一个 Dockerfile 和构建脚本。oss-fuzz-gen会调用这些脚本。失败可能源于网络问题（拉取镜像失败）、项目构建脚本更新导致不兼容，或本地 Docker 环境问题。
• 排查步骤：
  1. 手动进入 OSS-Fuzz 目录，尝试构建该项目：cd oss-fuzz && python3 infra/helper.py build_image cjson
  2. 如果手动构建成功，可能是框架在调用路径或参数传递上有问题。检查框架生成的临时构建命令是否正确。
  3. 如果手动构建也失败，那是 OSS-Fuzz 项目本身的问题，可能需要检查该项目的构建说明或提交 issue。

问题二：LLM API 调用频繁失败，返回超时或速率限制错误。

• 原因分析：云服务 API 有调用频率和并发限制。框架在并行处理多个任务时可能触达限制。
• 解决方案：
  1. 降低并发度：在配置文件中找到并发设置（如max_workers），将其调小（例如从 10 改为 2）。
  2. 增加重试与退避：框架的 HTTP 客户端通常内置了重试逻辑，检查其配置，适当增加重试次数和退避等待时间。
  3. 切换模型或供应商：如果某个 API 特别不稳定，可以暂时在配置中注释掉它，使用其他替代模型。

问题三：生成的代码编译成功，但运行时不产生任何覆盖率或崩溃。

• 原因分析：这是最令人头疼的情况，意味着 LLM 生成了一个“无害”但“无效”的目标。常见原因有：
  • 输入接口不对：生成的LLVMFuzzerTestOneInput函数没有正确解析或使用传入的data和size参数。例如，它可能直接把data当作 C 字符串使用，但没有检查size和终止符。
  • 资源未清理：每次模糊测试循环中分配的内存没有释放，导致程序很快内存耗尽而退出。
  • 目标函数选择不当：选择的函数本身可能不适合模糊测试（例如，它是一个纯粹的数学计算函数，对任何输入都只有一条执行路径）。
• 排查技巧：
  1. 代码审查：仔细阅读生成的代码。检查数据输入路径是否完整、是否调用了目标函数、错误处理是否合理。
  2. 简化测试：手动编写一个最简单的测试驱动，直接调用生成的函数，并打印一些调试信息，确认函数确实被调用且参数传递正确。
  3. 查看运行日志：OSS-Fuzz 的模糊测试引擎会输出详细的运行日志，包括每秒执行次数、覆盖图谱变化等。如果“执行次数”极低或为0，通常意味着目标函数内部有断言失败或异常退出。

问题四：覆盖率报告显示“覆盖率为0”，但代码看起来没问题。

• 原因分析：代码覆盖率工具（如gcov,llvm-cov）需要代码在编译时插入插桩指令。如果编译时没有正确开启覆盖率收集选项，或者链接了未插桩的第三方库，就会导致覆盖率为0。
• 解决方案：确保在 OSS-Fuzz 的构建配置中，为该项目正确设置了SANITIZER和覆盖率收集标志（如-fsanitize=fuzzer-no-link,address本身就包含了覆盖率收集）。框架通常会处理好这些，但如果项目有特殊的构建流程，可能需要手动调整。

5. 效果评估与案例深度分析

了解了如何使用，我们再来深入看看oss-fuzz-gen的实际效果。官方数据已经很有说服力，但我们可以从几个维度进行更细致的分析，并看看如何将这些结果应用到实际工作中。

5.1 量化指标解读与横向对比

框架的评估报告提供了丰富的量化数据。我们以官方给出的“当前顶级覆盖率提升项目”表格为例，进行解读：

• 总覆盖率增益 (Total coverage gain):这是AI新增覆盖行数 / 项目总行数。对于phmap，达到了惊人的 98.42%，这意味着 AI 生成的目标几乎覆盖了整个项目（1120行）中除了已有覆盖外的所有代码。这通常发生在项目本身代码量不大，且原有模糊测试覆盖非常薄弱的情况下。
• 总相对增益 (Total relative gain):这是AI新增覆盖行数 / 已有覆盖行数。phmap的 205.75% 意味着 AI 的贡献是原有人工编写的两倍还多。这是一个极其显著的提升。
• 一个有趣的矛盾点：看usbguard，AI 覆盖总行数（24550）远大于项目总行数（3564）。这引出了表格下方的注释：“项目总行数”仅衡量了被已有目标编译链接的源代码。当 AI 生成新目标时，可能会链接进项目的其他模块或更深的依赖，从而覆盖到之前未被纳入统计的代码。这说明 AI 不仅能在已知范围内挖得更深，还能拓展模糊测试的边界，覆盖到之前未被考虑的代码区域。

横向对比的启示：

• 对成熟项目（已有高覆盖）：如usbguard，相对增益可能不高（26.04%），但绝对新增行数（5463）依然可观。AI 在这里的作用是查漏补缺，寻找那些难以触及的角落。
• 对低覆盖或新项目：如phmap、onednn，AI 能带来颠覆性的提升。这对于资源有限、尚未投入大量安全测试的项目来说，价值巨大，可以快速建立一个高覆盖的模糊测试基线。

5.2 漏洞发现案例深度剖析

框架公布的漏洞列表是其实战能力的最佳证明。我们选取其中几个典型案例，分析其发现过程：

案例一：cJSON中的越界读取漏洞

• 目标函数：很可能是cJSON_ParseWithOpts或某个具体的值获取函数。
• LLM 策略：使用了 Vertex AI 模型和默认提示词。
• 目标预言：“Far reach, low coverage”（深远可达，低覆盖率）。这提示框架去寻找那些在调用链上位置较深、但现有测试覆盖很少的函数。
• 漏洞成因推测：cJSON是一个流行的 JSON 解析库。AI 生成的模糊测试目标可能构造了极其复杂、嵌套层次极深或包含特殊字符的 JSON 字符串，这些输入触发了解析器在计算字符串长度、跳转指针时的边界条件错误，导致了越界读取。这种用例在人工编写测试时容易被忽略，因为构造起来很繁琐，但 AI 通过随机变异可以轻松生成。

案例二：openssl中的 CVE-2024-9143

• 这是一个高危漏洞。能通过 AI 生成的模糊测试目标在 OpenSSL 这样的“泰山北斗”级项目中发现 OOB 读写漏洞，极具里程碑意义。
• 启示：即使是被全球安全专家用各种手段审计了无数遍的核心库，依然存在未被发现的漏洞路径。AI 模糊测试的“无差别随机探索”特性，使其在发现这类“边缘情况中的边缘情况”时具有独特优势。它不依赖于对协议或代码逻辑的深刻理解，而是通过海量尝试“撞”出问题。

从案例中学到的经验：

1. “低垂的果实”依然存在：许多开源项目，尤其是非安全核心类库，其模糊测试覆盖并不完善。AI 可以快速、低成本地收割这些“低垂的果实”。
2. 提示词与目标预言是关键：“Far reach, low coverage” 这个策略被证明非常有效。它引导 AI 去关注那些复杂、难以手动构造测试用例的代码路径。在实际应用中，我们可以根据项目特点，设计更精细化的“预言”策略。
3. 漏洞的“连带发现”效应：一个有效的模糊测试目标一旦生成，它会在 OSS-Fuzz 平台上持续运行。这意味着它不仅能在当前版本发现漏洞，在未来代码变更后，它还能继续发挥作用，捕捉到因修改而引入的新问题，实现可持续的安全保障。

5.3 集成到现有开发与安全流程的建议

对于企业和开源团队，如何将oss-fuzz-gen这类工具用起来？我建议可以分三步走：

第一步：探索与评估。

• 选型试点：从你的项目列表中挑选 3-5 个核心的、用 C/C++ 编写的库或服务。
• 运行一次基线实验：使用oss-fuzz-gen的默认配置，对这些项目进行一次完整的实验。目的是回答两个问题：1) 工具在我们的项目上能跑通吗？2) 它能产生有价值的（可编译、有覆盖率）目标吗？
• 成本评估：记录本次实验消耗的 API Token 数量和计算时间，评估长期运行的成本。

第二步：集成与自动化。

• CI/CD 流水线集成：将oss-fuzz-gen作为 CI 流水线中的一个可选或定期任务。例如，每周或每次重大版本发布前，自动运行一次针对核心模块的 AI 模糊测试目标生成与评估。
• 结果处理自动化：编写脚本，自动解析实验报告，筛选出“可编译”且“有覆盖率提升”的目标，自动提交 Pull Request 到项目的 OSS-Fuzz 目录中。这样，有价值的 AI 目标就能被持续运行。
• 漏洞跟踪自动化：配置 OSS-Fuzz 的漏洞报告，确保新发现的崩溃能自动创建 Issue 或通知到安全团队。

第三步：优化与定制。

• 提示词工程：分析在你们项目上表现最好的提示词和模型组合。可以尝试基于项目代码风格、已有的单元测试，定制专属的提示词模板。
• 目标函数筛选：如果项目很大，为所有函数生成目标成本太高。可以结合静态分析工具，先筛选出高风险函数（如处理网络数据、解析复杂格式、进行内存操作的函数），优先对这些函数使用 AI 生成。
• 构建反馈循环：将 AI 目标运行中发现的崩溃、覆盖信息收集起来，甚至可以反馈给 LLM，让它学习为什么某些目标失败了，从而在下一轮生成中改进。这需要更深的定制开发。

oss-fuzz-gen展现了大语言模型在软件安全工程领域的巨大应用潜力。它不是一个能完全取代安全专家的“银弹”，而是一个强大的“力量倍增器”。它将安全专家从重复、繁琐的测试代码编写中解放出来，让他们能更专注于漏洞的分析、利用和修复策略制定。同时，它也为广大开发者提供了一种提升代码健壮性的自动化手段。随着模型能力的持续进化，以及此类框架的不断成熟，AI 驱动的自动化安全测试必将成为未来软件开发中不可或缺的一环。