GitHub Security Lab 开源 Fuzzing Taskflow：让 Agent 接管 C/C++ 模糊测试全流程，从写 Harness 到出漏洞报告

核心背景与行业痛点

持续模糊测试能挖出真实漏洞，但即便接入 OSS-Fuzz 多年的项目仍会漏掉关键 Bug，原因几乎总是同一个：需要有人盯覆盖率、为没人触达的代码写新 Harness、再逐个分诊崩溃。GitHub Security Lab 研究员 Antonio Morales 在官方博客（9 月 24 日发布，GitHub 官方账号 10 月 11 日再次推广）中给出的答案是：把这条人工回路交给 LLM Agent。

架构亮点与底层机制

Fuzzing Taskflow 构建在 Taskflow Agent 框架之上，分三层：Shell 驱动串联各阶段；每个阶段一份 Taskflow YAML（即给 Agent 的提示）；一组 MCP 工具负责执行（运行 AFL、编译 Harness、存储崩溃、读覆盖率）。核心原则是「Agent 负责决策，工具负责执行」，Agent 从不直接调用 AFL 或 clang，所有状态存于 SQLite（fuzz_context.db）。覆盖率回路中，Agent 读取未覆盖分支后可选择：构造新种子、修改 Harness 调用更多 API、自动扩充 AFL 字典中的魔数常量，或跳过冷门错误路径。结构感知方面内置 JSON/XML/正则/PNG/TLV 自定义变异器，未知格式则扫描目标源码提取字符串和 32 位常量动态生成字典。

权威 Benchmark 与实测跑分对比

官方博客未公布发现漏洞数量或与人工 Harness 的覆盖率对比数据，本文不做推测。已公开的硬参数：迭代预算 30s 起逐轮翻倍至 960s（单目标约 32 分钟），平台期阈值默认 1% 行覆盖；崩溃按七类判定输出。官方强调补丁建议标注「review required」，判定可能出错，应视为供人审阅的起点。

开发者实战落地与开箱指南

在仓库中开 Codespace，执行 ./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON 先做冒烟测试；仪表盘自动在 8765 端口启动，可实时看覆盖率趋势和崩溃热力图。默认模型为 Claude Sonnet 5（官方称其通过全部内部测试），可在 model_config.yaml 中更换。注意：LLM 选定的构建命令直接在宿主机运行，务必使用一次性环境。