GitHub Security Lab researcher Antonio Morales published a post on September 24 introducing an LLM-driven fuzzing pipeline for C/C++ projects. The code lives in the GitHub repository seclab-taskflows-fuzzing, and the default model is Claude Sonnet 5.
The pipeline is built on GitHub's own Taskflow Agent framework, which the company describes as “a framework for building LLM-driven security automation.” Users open a Codespace in the repo, run a single script followed by a target project name — for example, tukaani-project/xz — and the agent handles the rest.
From Finding Entry Points to Writing Reports
According to the writeup, the pipeline works through these steps in order: identifying code entry points, automatically writing test harnesses, invoking AFL++ to run fuzzing, reading coverage reports, rewriting harnesses based on coverage, classifying each crash, and finally generating a vulnerability report with patch suggestions in unified diff format.
Coverage feedback uses a doubling time budget: each round gets twice the time of the previous one, starting at 30 seconds and doubling through 60, 120, 240, 480, and 960 seconds, for a cumulative total of about 32 minutes per target. The agent reviews the coverage after each round before deciding what to change.
To help random mutation better understand input formats, the pipeline layers four "structure-aware" techniques: format-specific dictionaries and custom mutators, dictionaries extracted from source code, AFL dictionaries generated dynamically during the run, and corpus concatenation.
Crash classification uses fairly granular labels: real vulnerability, library_hardening (hardening suggestions), harness_bug (bugs in the test harness itself), out-of-memory, timeout, assertion failure, and duplicate. Crashes are first minimized with afl-tmin, then deduplicated by call stack. During a run, a live HTML dashboard on port 8765 shows progress.
Morales summed up the division of labor behind the design:
"the LLM agent owns the decisions, and the MCP tools own the execution"
How It Compares to OSS-Fuzz
Google got here earlier. OSS-Fuzz has been experimenting with LLMs to auto-generate fuzz targets since 2023, and Google said in late 2024 that the approach had helped surface a number of issues, including one vulnerability in OpenSSL. That approach mainly solves the "write the harness" step, and a project first needs to be integrated into OSS-Fuzz's infrastructure.
GitHub's approach looks more like a toolbox you can carry with you: it doesn't require a project to sign onto any platform — opening a cloud dev environment is enough to run it, and triage and report-writing are bundled in too. The writeup opens with a reminder that continuous fuzzing isn't a cure-all: projects that have sat on OSS-Fuzz for years can still hide serious bugs, which is part of why the team picked xz as its demo. xz was at the center of a backdoor incident in 2024 that shook the open-source world, but that was a supply-chain poisoning case — a different category of problem from the memory-safety bugs fuzzing can find.
What the Writeup Leaves Out
Several numbers outside observers care about most aren't disclosed: how many crashes were found in xz and cJSON respectively, how many of those were judged real vulnerabilities, whether any CVEs were assigned; the token consumption and cost of running a full project; and the false-positive rate. Morales's own language stays fairly restrained — he writes that triage conclusions should be read as “a well-prepared starting point handed to a human,” not a final result, and that patch suggestions are all flagged as needing human review.
There's also a security caveat. The pipeline runs without container isolation, and the official guidance is to run it only in disposable environments like a Codespace or a temporary VM, and never to grant it elevated privileges. Teams hoping to deploy it directly inside a corporate network will hit that constraint before they even get to picking a model.
For maintainers of open-source base libraries in mainland China, the main barrier is the model: the default configuration calls an Anthropic model, and direct access from China is inconvenient. The repo is open source, so in theory a compatible alternative model could be swapped in, but whether results would hold up hasn't been publicly tested.
Sources: GitHub's official blog, the seclab-taskflows-fuzzing repository documentation, CocoLoop, and public materials from Google's OSS-Fuzz; pipeline steps, time budgets, and crash classification follow GitHub's blog description.