GitHub Security Lab 研究员 Antonio Morales 9 月 24 日发文，公开了一套由大模型驱动的模糊测试（fuzzing）流水线，面向 C/C++ 项目，代码放在 GitHub 仓库 seclab-taskflows-fuzzing 下，默认模型是 Claude Sonnet 5。
这套东西建在 GitHub 自家的 Taskflow Agent 框架上，官方对这个框架的定义是”编写 LLM 驱动安全自动化的框架”。用户在仓库里开一个 Codespace，执行一行脚本、后面跟上目标项目名，比如 tukaani-project/xz，剩下的步骤交给智能体。
从找入口到出报告
按文章描述，流水线要做的事依次是：识别代码入口点，自动写测试桩（harness），调用 AFL++ 跑模糊测试，读覆盖率报告，根据覆盖情况改写测试桩，再对每一次崩溃做分类，最后生成漏洞报告，附带统一 diff 格式的补丁建议。
覆盖率反馈用的是时间预算翻倍的办法：每一轮给的时间是上一轮的两倍，从 30 秒起，依次 60、120、240、480、960 秒，单个目标累计约 32 分钟。智能体每轮看完覆盖率再决定改哪里。
为了让随机变异更懂输入格式，流水线叠了四层”结构感知”手段：针对文件格式的字典和自定义变异器、从源码里抽出来的字典、运行中动态生成的 AFL 字典，以及语料拼接。
崩溃分类的标签分得比较细：真实漏洞（vulnerability）、库加固建议（library_hardening）、测试桩自身的 bug（harness_bug）、内存耗尽、超时、断言失败、重复。崩溃会先经过 afl-tmin 最小化，再按调用栈去重。运行期间还有一个跑在 8765 端口的 HTML 仪表盘，实时看进度。
Morales 在文中给这套设计定了一条分工原则：
“the LLM agent owns the decisions, and the MCP tools own the execution” （决策归大模型智能体，执行归 MCP 工具。）
跟 OSS-Fuzz 那条线对照
把大模型塞进模糊测试，Google 走得更早。OSS-Fuzz 从 2023 年起就在试用大模型自动生成 fuzz target，Google 2024 年底对外说过，这条路线帮它找到了包括 OpenSSL 一处漏洞在内的一批问题。那套方案主要解决”写测试桩”这一步，项目本身得先接入 OSS-Fuzz 的基础设施。
GitHub 这次的做法更像一个可以带走的工具箱：不要求项目接入任何平台，开一个云端开发环境就能跑，分诊和写报告也一并包了。文章开头专门提醒，持续模糊测试不是万能药，常年挂在 OSS-Fuzz 上的项目照样可能藏着严重 bug，这也是他们选 xz 当演示对象的背景。xz 在 2024 年出过震动整个开源圈的后门事件，但那次是投毒，跟模糊测试能发现的内存错误不是一类问题。
文章没说的部分
几项外界最关心的数据，文章没有披露：在 xz、cJSON 上各找到多少崩溃、其中多少被判为真实漏洞、有没有分配到 CVE；跑完一个项目的 token 消耗和费用；误报率。作者自己的措辞相当克制，他写道，分诊结论应当看作”交给人的一份准备充分的起点”，不能当最终结果，补丁建议也都标着需要人工复核。
安全方面还有一条前提。流水线运行时不做容器隔离，官方建议只在 Codespace 或临时虚拟机这类可丢弃环境里跑，也不要给它提权。对想在公司内网直接部署的团队，这一条会比模型选型更早碰到。
对国内做开源基础库的维护者，门槛主要在模型：默认配置调用的是 Anthropic 的模型，国内直连不便。仓库是开源的，理论上可以换成其他兼容的模型，效果能不能保持，目前没有公开测试。
参考来源：GitHub 官方博客、seclab-taskflows-fuzzing 开源仓库说明、CocoLoop、Google OSS-Fuzz 公开资料；流水线步骤、时间预算与崩溃分类以 GitHub 博客描述为准。