使用 GitHub 安全实验室任务流代理进行人工智能驱动的模糊测试
在这篇博文中，我解释了如何使用基于 GitHub 安全实验室任务流代理 AI 框架的新模糊测试任务流。使用 GitHub 安全实验室任务流代理进行人工智能驱动的模糊测试首先出现在 GitHub 博客上。
来自 GitHub AI 的官方动态，版本与适用范围以发布方说明为准。
GitHub AI · 查看官方发布中文机器翻译 · 原文附后
正文 · 来源原文
如果您是模糊测试新手并想先学习基础知识，请查看我们的 Fuzzing 101 课程：gh.io/fuzzing101。
连续模糊测试并不是解决所有问题的神奇解决方案。即使已经加入 OSS-Fuzz 多年的项目仍然可以隐藏关键错误，其原因几乎总是相同的：需要有人密切关注覆盖范围，为无人触及的代码编写新的工具，并对另一端出现的崩溃进行分类。换句话说，模糊测试仍然需要有人参与其中。
因此，我不断问自己的自然问题是：我们实际上可以将多少人力工作移交给法学硕士代理人？
这就是我构建 Fuzzing Taskflow 的原因，这是一个用于 C/C++ 项目的自主模糊测试管道。您只需将其指向 GitHub 存储库，它就会完成剩下的工作：识别合适的入口点、分析构建系统、编写工具、运行 AFL++、读取覆盖率报告、改进工具、对每次崩溃进行分类，并为每个独特的错误编写漏洞报告，所有这些都无需人工照管。
模糊测试任务流构建在 GitHub 安全实验室任务流代理之上，这是我们用于编写 LLM 驱动的安全自动化的框架，因此管道表示为代理端到端运行的一组任务流。
在这篇文章中，我将向您介绍它的工作原理及其背后的设计决策。让我们开始吧！
如何运行它
运行它的最简单方法就是访问 https://github.com/GitHubSecurityLab/seclab-taskflows-fuzzing 并启动一个代码空间。
然后，像这样运行脚本：
因此，例如：
就是这样。参数只是 GitHub 所有者/repo slug。然后，代理自行处理所有初步步骤：
安装 AFL 等软件 克隆存储库 识别代码中最相关的函数 为这些函数创建模糊目标
如果您只想在进行长期活动之前进行快速冒烟测试，请将其指向一些小东西：
在运行之前请注意：此任务流直接在主机上运行 afl-fuzz、clang 和 LLM 选择的任意构建命令，中间没有容器。原则上，提示注入的代理可以做用户可以做的任何事情。因此，请仅在一次性环境（例如 Codespace 或一次性虚拟机）内运行它，而无需提升权限。
选型
一些前沿模型对其输出施加了安全护栏。对于模糊测试任务流程，我们默认使用 Claude Sonnet 5，因为它通过了我们所有的内部测试，没有出现任何问题。您可以通过修改以下文件来选择不同的模型：src/seclab_taskflows_fuzzing/configs/model_config.yaml。
一分钟了解架构
在进入有趣的部分之前，了解各个部分如何组合在一起会有所帮助。共有三层：
将管道阶段链接在一起的 shell 驱动程序 (run_fuzzing.sh)。一组任务流 YAML，每个阶段一个，本质上是告诉 LLM 代理在每个步骤做什么的提示。代理调用的一组 MCP 工具来实际完成工作：运行 AFL、编译工具、存储崩溃、读取覆盖率报告等。
查看英文原文
AI-powered fuzzing with the GitHub Security Lab Taskflow Agent
In this blog post, I explain how to use the new fuzzing taskflow based on the GitHub Security Lab Taskflow Agent AI framework. The post AI-powered fuzzing with the GitHub Security Lab Taskflow Agent appeared first on The GitHub Blog .
正文 · 来源原文
If you’re new to fuzzing and want to learn the fundamentals first, check out our Fuzzing 101 course at gh.io/fuzzing101.
Continuous fuzzing is not a magic solution that solves all your problems . Even projects that have been enrolled in OSS-Fuzz for years can still hide critical bugs, and the reason is almost always the same: someone needs to keep an eye on coverage, write new harnesses for the code that nobody is reaching, and triage the crashes that come out the other end. In other words, fuzzing still needs a human in the loop.
So the natural question I kept asking myself was: how much of that human work can we actually hand over to an LLM agent?
That is what led me to build the Fuzzing Taskflow, an autonomous fuzzing pipeline for C/C++ projects. You only need to point it at a GitHub repository, and it does the rest: it identifies the suitable entrypoints, analyzes the build system, writes the harnesses, runs AFL++, reads the coverage reports, improves the harnesses, triages every crash, and writes a vulnerability report for each unique bug, all without a human babysitting it.
The Fuzzing Taskflow is built on top of the GitHub Security Lab Taskflow Agent, our framework for writing LLM-driven security automation, so the pipeline is expressed as a set of taskflows that an agent runs end to end.