GitHub Security Lab 在 9 月 24 日的官方博客中开源了一套 LLM 驱动的模糊测试流水线 Fuzzing Taskflow：你只需要给它一个 GitHub 仓库地址，它就能自动识别入口点、编写测试 harness、跑起 AFL++、读覆盖率报告、改进测试用例，最后把每个崩溃分诊成一份漏洞报告——全程不需要人盯着。
一条命令，流水线自己跑完
这套流水线的使用方式简单到不像安全工具。代码已经开源在 GitHub 上（组织名 GitHubSecurityLab，项目名 seclab-taskflows-fuzzing）：开一个 Codespace，执行 ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz，剩下的智能体自己办：装 AFL 等依赖、克隆仓库、在代码里找最值得测的函数、为这些函数生成 fuzz target。
作者 Antonio Morales 在博客里特别提醒了一句：这条流水线会在宿主机上直接运行 afl-fuzz、clang，以及由 LLM 自己决定的任意构建命令，中间没有任何容器隔离。被提示词注入的智能体理论上能做你的用户账号能做的任何事，所以只能跑在一次性环境里，比如 Codespace 或用完即扔的虚拟机，而且不能给提权。
智能体只做决策，工具负责执行
Fuzzing Taskflow 构建在 GitHub Security Lab 的 Taskflow Agent 框架之上，整条流水线被表达成一系列 taskflow，由智能体端到端执行。架构分三层：shell 脚本串起各个阶段，一组 YAML taskflow 描述每个阶段的提示词，一组 MCP 工具真正干活——跑 AFL、编译 harness、存崩溃、读覆盖率报告。
设计上有一条清晰的分工线：LLM 智能体拥有决策权，决定测什么、写什么样的 harness、下一个覆盖率缺口追哪里；MCP 工具只暴露执行原语。智能体从不直接调用 AFL 或 clang，而是用这些积木拼出流水线。所有阶段的状态都存在一个 SQLite 数据库里，阶段之间不直接传内存数据。
默认用的模型是 Claude Sonnet 5，原因是它通过了团队全部内部测试且没有触发安全护栏；想换模型，改 src/seclab_taskflows_fuzzing/configs/model_config.yaml 就行。
核心是覆盖率反馈循环
手动做模糊测试最磨人的两步，是读覆盖率报告找没覆盖到的分支，和为这些分支写新的 harness。Fuzzing Taskflow 把这两步都交给了智能体：每轮给每个 harness 一定的 AFL 运行时间预算，跑完后回放队列生成真实的行覆盖与分支覆盖报告，读出未覆盖分支，然后从几个动作里选一个——加一颗直奔该分支的新种子、改 harness 多调一个 API、往 AFL 字典里自动补充守卫条件比较的魔数，或者判断这是冷门错误路径直接跳过。
时间预算每轮翻倍：30 秒、60 秒、120 秒，一直到约 32 分钟。什么时候停？用"平台期检测"：连续两轮的行覆盖率增益都低于 1%，就判定进入收益递减，直接换下一个目标，不烧算力去挤最后零点几个百分点。
针对结构化输入（JSON、XML、正则、PNG 等），流水线还带了四套互补机制：预置的格式字典和自定义变异器、从目标源码里扫描字符串常量自动生成的源码级字典、按覆盖率动态增长的字典，以及语料拼接算子。
崩溃分诊：最烦人的部分也自动化了
找到崩溃只是完成了一半，分诊往往更耗时。流水线跑完 fuzzing 后自动走三步：每个崩溃先用 afl-tmin 最小化，在 ASan 下重放抓堆栈，按"栈顶哈希"去重；再把历史已知崩溃在新二进制上重放一遍，看上游修复是否已经解决；最后智能体读 harness 源码和崩溃函数，沿调用链回溯，逐个崩溃写一份 Markdown 报告。
每份报告会给一个 verdict：真正的 vulnerability、library_hardening、harness 自身的 bug、OOM、超时、断言失败或重复。区分"真漏洞"和"harness 写错了"，正是以前必须人工坐下来逐行跟代码才能做的判断。每份报告还包含根因分析（带文件行号）、可达性论证、可利用性评估、一份标着"需人工复核"的 unified diff 修复建议和回归测试草图。
跑起来之后，还能在 8765 端口打开一个实时 dashboard，看每个 harness 的运行心跳、覆盖率趋势、崩溃热力图和迭代时间线。
开源仓库维护者可以先试试
这套东西最直接的受益者，是那些"知道该 fuzz 但没人力"的 C/C++ 开源项目维护者：以前接入 OSS-Fuzz 之后，写 harness、盯覆盖率、分诊崩溃依然要人肉，现在这部分被智能体接过去了。当然，Morales 自己也承认，智能体的 verdict 只是"准备充分的起点"，不能当最终结论——漏洞报告的修复建议标着"需复核"是有原因的。
有意思的是，AI 往代码安全里钻的不只 GitHub 一家。本站之前报道过 Cursor 上线的 Security Reviewer，走的是"逐 PR 扫描"的路子；GitHub 这套走的是"纵深 fuzz"的路子。一个管增量代码，一个管存量代码，刚好互补。
