In einem Blogbeitrag vom 24. September 2026 hat GitHub Security Lab Fuzzing Taskflow als Open Source veröffentlicht, eine LLM-gestützte Fuzzing-Pipeline: Gib ihr eine GitHub-Repository-Adresse, und sie identifiziert automatisch Einstiegspunkte, schreibt Test-Harnesses, fährt AFL++ hoch, liest Coverage-Reports, verbessert Testfälle und triagiert jeden Crash schließlich in einen Vulnerability-Report — ohne dass ein Mensch zuschauen muss.
Ein Befehl, und die Pipeline läuft von selbst
Die Bedienung ist für ein Security-Tool fast komisch einfach. Der Code liegt offen auf GitHub (Organisation GitHubSecurityLab, Projekt seclab-taskflows-fuzzing): Codespace öffnen, ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz ausführen, und der Agent übernimmt den Rest — AFL-Abhängigkeiten installieren, Repository klonen, die testwürdigsten Funktionen im Code finden und Fuzz-Targets dafür generieren.
Autor Antonio Morales fügt im Beitrag eine ausdrückliche Warnung hinzu: Diese Pipeline führt afl-fuzz, clang und beliebige Build-Befehle, die das LLM selbst wählt, direkt auf dem Host-Rechner aus — ohne Container-Isolierung dazwischen. Ein per Prompt Injection manipulierter Agent könnte theoretisch alles tun, was das Benutzerkonto darf, also gehört sie nur in Wegwerf-Umgebungen: einen Codespace oder eine Einweg-VM, und niemals mit erhöhten Rechten.
Der Agent entscheidet, die Tools führen aus
Fuzzing Taskflow baut auf dem Taskflow-Agent-Framework von GitHub Security Lab auf; die gesamte Pipeline ist als Reihe von Taskflows ausgedrückt, die der Agent Ende-zu-Ende ausführt. Die Architektur hat drei Schichten: Shell-Skripte, die die Phasen verketten, YAML-Taskflows, die die Prompts jeder Phase beschreiben, und MCP-Tools, die die eigentliche Arbeit leisten — AFL laufen lassen, Harnesses kompilieren, Crashes speichern, Coverage-Reports lesen.
Die Design-Arbeitsteilung ist klar: Der LLM-Agent hält die Entscheidungsgewalt — was wird getestet, welche Art Harness wird geschrieben, welche Coverage-Lücke wird als Nächstes verfolgt — während die MCP-Tools nur Ausführungsprimitive bereitstellen. Der Agent ruft AFL oder clang nie direkt auf; er setzt die Pipeline aus diesen Bausteinen zusammen. Der gesamte Phasenstatus lebt in einer SQLite-Datenbank; Phasen übergeben niemals Speicherdaten direkt.
Das Standardmodell ist Claude Sonnet 5, gewählt, weil es die vollständigen internen Tests bestand, ohne Sicherheits-Leitplanken auszulösen; zum Wechseln des Modells genügt eine Änderung in src/seclab_taskflows_fuzzing/configs/model_config.yaml.
Kernstück ist die Coverage-Feedback-Schleife
Die beiden mühsamsten Schritte beim manuellen Fuzzing sind: Coverage-Reports lesen, um ungedeckte Branches zu finden, und neue Harnesses dafür zu schreiben. Fuzzing Taskflow übergibt beides dem Agenten: Jede Runde gibt jedem Harness ein AFL-Laufzeitbudget, danach wird die Queue replayt, um echte Line- und Branch-Coverage zu erzeugen; die ungedeckten Branches werden ausgelesen, und aus mehreren Aktionen wird eine gewählt — einen Seed hinzufügen, der genau auf diesen Branch zielt, den Harness erweitern, um eine weitere API aufzurufen, die Magic Numbers der Guard-Bedingungen automatisch ins AFL-Wörterbuch aufnehmen, oder ihn als kalten Error-Pfad einordnen und überspringen.
Das Zeitbudget verdoppelt sich jede Runde: 30 Sekunden, 60 Sekunden, 120 Sekunden, bis zu etwa 32 Minuten. Wann wird gestoppt? Durch einen „Plateau-Detektor": Zwei aufeinanderfolgende Runden mit absoluten Line-Coverage-Gewinnen unter 1 % bedeuten sinkende Grenzerträge — weiter zum nächsten Ziel, statt Rechenleistung für die letzten Bruchteile eines Prozents zu verbrennen.
Für strukturierte Inputs (JSON, XML, Regex, PNG und Ähnliches) bringt die Pipeline vier ergänzende Mechanismen mit: vorseedingte Format-Wörterbücher plus eigene Mutatoren, Source-Level-Wörterbücher, die automatisch durch Scannen von String-Konstanten im Target-Quellcode erzeugt werden, dynamisch mit der Coverage wachsende Wörterbücher sowie Corpus-Splicing-Operatoren.
Crash-Triage, der nervigste Teil, ist ebenfalls automatisiert
Einen Crash zu finden, ist nur die halbe Arbeit; die Triage kostet meist mehr Zeit. Nach dem Fuzzing läuft die Pipeline automatisch drei Schritte: jeden Crash mit afl-tmin minimieren, unter ASan replayen, um Stacks zu erfassen, und per „Stack-Top-Hash" deduplizieren; dann alle historisch bekannten Crashes gegen das neue Binary replayen, um zu sehen, ob Upstream-Fixes sie bereits behoben haben; schließlich liest der Agent die Harness-Quelle und die abstürzende Funktion, verfolgt die Aufrufkette zurück und schreibt pro Crash einen Markdown-Report.
Jeder Report trägt ein Verdict: echte Vulnerability, library_hardening, Bug im Harness selbst, OOM, Timeout, Assertion-Failure oder Duplikat. „Echter Bug" von „Harness falsch geschrieben" zu unterscheiden — genau dieses Urteil erforderte früher einen Menschen, der sich hinsetzte und Code Zeile für Zeile verfolgte. Jeder Report enthält außerdem eine Root-Cause-Analyse (mit Datei- und Zeilennummern), eine Erreichbarkeits-Argumentation, eine Ausnutzbarkeits-Bewertung, einen als „erfordert menschliche Prüfung" markierten Unified-Diff-Fixvorschlag und eine Regressionstest-Skizze.
Nach dem Start öffnet ein Live-Dashboard auf Port 8765, das den Heartbeat jedes Harnesses, Coverage-Trends, Crash-Heatmaps und Iterations-Zeitlinien zeigt.
Open-Source-Maintainer können es ausprobieren
Die unmittelbarsten Nutznießer sind C/C++-Open-Source-Maintainer, die „wissen, dass sie fuzzen sollten, aber keine Leute dafür haben": Nach dem Onboarding zu OSS-Fuzz kosteten Harness-Schreiben, Coverage-Beobachten und Crash-Triage weiterhin Menschen — diesen Teil übernimmt jetzt der Agent. Natürlich räumt Morales selbst ein, dass das Verdict des Agenten nur ein „gut vorbereiteter Ausgangspunkt" ist, kein endgültiges Urteil — darum sind die Fixvorschläge in den Reports als „prüfungsbedürftig" markiert.
Bemerkenswert: GitHub ist nicht das einzige Haus, das KI in die Code-Sicherheit bringt. Wir haben zuvor über Cursors Security Reviewer berichtet, der die „jeden PR scannen"-Route nimmt; GitHubs Pipeline nimmt die „tiefes Fuzzing"-Route. Einer bewacht inkrementellen Code, der andere Altcode — sie ergänzen sich sauber.
