GitHub Security Lab 发布 LLM 驱动的 Fuzzing Taskflow，自动完成 C/C++ 项目模糊测试全流程

一句话看懂：GitHub Security Lab 发布 Fuzzing Taskflow，让 LLM 智能体自动完成 C/C++ 项目从写测试框架到漏洞报告的全流程模糊测试，开发者只需提供一个 GitHub 仓库地址。

事件核心：发生了什么

2026 年 9 月 24 日，GitHub Security Lab 的 Antonio Morales 发布了一篇技术文章，介绍了名为 Fuzzing Taskflow 的自动化模糊测试流水线。该项目构建在 GitHub Security Lab Taskflow Agent 框架之上，面向 C/C++ 开源项目：用户只需传入一个 GitHub owner/repo 参数，例如 tukaani-project/xz 或轻量的 DaveGamble/cJSON，系统就会自动完成克隆仓库、分析构建系统、识别关键函数、编写 harness（测试目标）、运行 AFL++、读取覆盖率报告、改进 harness、崩溃分类，并为每个独立漏洞生成漏洞报告。默认使用 Claude Sonnet 5 模型，可通过配置文件切换。代码已在 GitHub 上开源，并支持在 Codespace 中一键启动。

为什么重要

持续模糊测试长期依赖人工介入——即使项目进入 OSS-Fuzz 多年，覆盖率盲区、harness 编写和崩溃分类仍需工程师手动完成。Fuzzing Taskflow 把这层“人在回路”的重复劳动交给 LLM 智能体，且明确划分职责：智能体负责决策，MCP 工具负责执行，状态统一存入 SQLite 数据库。每个 harness 会编译两份二进制——一份用于 AFL 模糊测试，一份用于生成可读的源码级覆盖率报告——从而把覆盖率反馈闭环自动化。这为 AI 在安全测试领域的落地提供了一个可复用的架构样本，也可能推动更多安全工具向“智能体调度 + 工具原语”的模式演进。

对用户/开发者/创作者的影响

对开源维护者和安全研究者来说，这意味着可以用较低人力成本启动一轮针对特定仓库的模糊测试，尤其适合发现长期未被覆盖的代码路径。但需要注意：该工具直接在宿主机上运行 afl-fuzz、clang 及 LLM 自行选择的构建命令，没有容器隔离。官方明确警告，被提示注入的智能体原则上可以执行当前用户权限内的任意操作，因此建议只在一次性 Codespace 或无特权虚拟机中运行。对使用闭源模型或受限模型的团队，还需确认模型安全护栏是否影响任务执行——官方默认选用 Claude Sonnet 5 正是因为它通过了内部测试。