生活分享

GitHub Security Lab 推出 AI 模糊测试流程 Fuzzing Taskflow:让 AI 代理自动查找 C/C++ 漏洞

据 GitHub 博客 2026 年 9 月 24 日文章,GitHub Security Lab 以 Taskflow Agent 框架打造自主模糊测试流程,由 AI 代理编写测试框架、追查覆盖率缺口并分类崩溃。本文整理其运作方式、安全警告及对普通读者的意义。

阅读时间约 6 分钟

GitHub Security Lab 推出 AI 模糊测试流程 Fuzzing Taskflow:让 AI 代理自动查找 C/C++ 漏洞
图片:Mokaair (Original editorial artwork)

GitHub 宣布了什么

GitHub 博客于 2026 年 9 月 24 日刊出由 Antonio Morales 撰写的文章,介绍一套名为 Fuzzing Taskflow 的新流程。据文章所述,它基于 GitHub Security Lab Taskflow Agent,这是 GitHub 用来编写由大语言模型驱动的安全自动化的框架。作者将 Fuzzing Taskflow 描述为针对 C/C++ 项目的自主模糊测试流程。

模糊测试(fuzzing)是一种用大量自动生成的输入来测试程序、借此发现崩溃与潜在漏洞的方法。作者在文中指出,持续模糊测试并非万灵药:即使参与 OSS-Fuzz 多年的项目仍可能隐藏严重错误,原因是仍需要有人监控覆盖率(即测试实际执行到了多少代码)、为未被触及的代码编写新的测试框架(把待测函数接到模糊测试工具上的一小段代码),并对跑出来的崩溃结果进行分类,也就是逐一判断每次崩溃的原因和严重程度。Fuzzing Taskflow 正是尝试把这部分人工工作交给 AI 代理。

GitHub Security Lab 推出 AI 模糊测试流程 Fuzzing Taskflow:让 AI 代理自动查找 C/C++ 漏洞
Mokaair 编辑核查流程 · 图片:Mokaair (Original editorial artwork)
阅读完整文字说明

消息会先收集来源、独立核查,再交由 Jev 判断。

据 GitHub 描述,用户只需指向一个 GitHub 仓库,流程便会识别合适的入口点、分析构建系统、编写测试框架、运行模糊测试工具 AFL++、阅读覆盖率报告、改进测试框架、分类每个崩溃,并为每个独特错误撰写漏洞报告。文章指出工具存放于 GitHubSecurityLab/seclab-taskflows-fuzzing 仓库,默认使用 Claude Sonnet 5,原因是它通过了团队所有内部测试,用户也可通过配置文件更换模型。

运作方式:AI 负责决策,工具负责执行

据文章,整个架构分为三层:串联各阶段的 shell 驱动程序、每个阶段一份的 taskflow YAML(实质上是告诉代理每一步要做什么的提示),以及 MCP 工具,也就是代理调用来实际完成工作的工具,例如运行 AFL、编译测试框架或读取覆盖率报告。作者表示,他最看重的设计原则是清晰分工:大语言模型代理负责决策,MCP 工具负责执行,代理从不直接调用 AFL 或 clang。所有状态都存储在 SQLite 数据库中。

文章还提到,每个测试框架会构建两次:.afl 版本负责实际模糊测试,.cov 版本则在之后重放 AFL 的测试队列,以生成真实的源代码行与分支覆盖率报告。

覆盖率反馈循环与停止条件

作者表示,检查覆盖率与改进覆盖率这两步,过去由他手动完成,例如阅读 LCOV 覆盖率报告,查找还没被测试执行到的分支;Fuzzing Taskflow 把两者都交给代理。据文章,每次迭代中代理可选择:新增针对未覆盖分支的种子输入(模糊测试用来变化出新输入的起始样本)、编辑测试框架以调用更多 API、自动扩充 AFL 字典,或跳过不值得追查的缺口。

时间预算每次迭代翻倍,由 30 秒、60 秒、120 秒、240 秒、480 秒到 960 秒,每个目标约 32 分钟。流程采用平台期检测:当连续两次迭代的增益都低于可配置阈值(默认为 1% 绝对行覆盖率)时,便判断已进入收益递减阶段并继续下一步。

结构感知输入

文章称流程提供四种互补机制来生成具备结构感知的输入,也就是符合特定文件格式规则、而不只是随机改动字节的测试输入。对于可识别的格式,包括 JSON、XML、正则表达式、PNG 及长度前缀二进制 TLV,流程附带预建的 AFL 字典与自定义变异器;对于无法识别的格式,则会扫描目标项目自身的 .c/.h 文件,提取字符串字面量与 32 位数值常量作为拼接符号。

人工模糊测试与 Fuzzing Taskflow 的比较(资料来源:GitHub 博客)
工作环节作者描述的人工流程Fuzzing Taskflow 的做法(据 GitHub)
检查覆盖率人工阅读 LCOV 报告查找未覆盖分支代理用 .cov 版本重放队列后阅读未覆盖分支清单
改进覆盖率人工编写新测试框架或制作新输入代理新增种子、编辑测试框架、扩充字典或跳过缺口
何时停止需要人工判断连续两次迭代增益低于阈值(默认 1%)即停止
崩溃处理需要人工分类分类每个崩溃并为每个独特错误撰写漏洞报告

对普通读者的实际影响

  • 对开源维护者:GitHub 将这类工具定位为减少模糊测试中人工监控与分类工作的方法,但实际成效仍需各项目自行评估。
  • 对普通用户:模糊测试的目的是在软件发布前找出错误,更多项目能以较低成本进行测试,长远或有助于提升常用软件的可靠性,但这是推论,文章并未提供成效数据。
  • 对 AI 安全:GitHub 自己的警告表明,让 AI 代理直接执行命令本身就带有提示注入等风险,隔离环境仍是基本要求。
  • 信息来源:以上内容全部来自 GitHub 自家博客,属单一来源,尚未见独立验证。

常见问题

Fuzzing Taskflow 是什么?

据 GitHub 博客,它是 GitHub Security Lab 以 Taskflow Agent 框架打造、针对 C/C++ 项目的自主模糊测试流程,由 AI 代理自动编写测试框架、追查覆盖率并分类崩溃。

它会取代人工安全研究吗?

文章的出发点是探讨有多少人工工作可以交给大语言模型代理,并未声称完全取代人工;作者也强调持续模糊测试并非万灵药。

用哪个 AI 模型?

据文章,默认使用 Claude Sonnet 5,因为它通过了团队所有内部测试;用户可通过配置文件更换模型。

在自己电脑上运行安全吗?

GitHub 自己警告,该流程会在主机上直接执行由 AI 选择的构建命令,没有容器隔离,建议只在可丢弃的环境中以非提升权限运行。

这些说法经过独立验证吗?

没有。本文所有资料均来自 GitHub 博客单一来源,属该公司自述。

查看同分类最新消息

最新旅游情报攻略

资料来源

生活分享