Antonio Morales, Forscher bei GitHub Security Lab, hat am 24. September eine von einem großen Sprachmodell gesteuerte Fuzzing-Pipeline für C/C++-Projekte veröffentlicht. Der Code liegt im GitHub-Repository seclab-taskflows-fuzzing, als Standardmodell ist Claude Sonnet 5 hinterlegt.
Die Pipeline baut auf GitHubs eigenem Taskflow-Agent-Framework auf, das offiziell als "Framework zum Schreiben LLM-gestützter Sicherheitsautomatisierung" beschrieben wird. Nutzer öffnen im Repository einen Codespace, führen ein einzeiliges Skript aus und hängen den Namen des Zielprojekts an, etwa tukaani-project/xz — den Rest übernimmt der Agent.
Vom Einstiegspunkt zum fertigen Bericht
Laut Beschreibung durchläuft die Pipeline folgende Schritte der Reihe nach: Einstiegspunkte im Code identifizieren, automatisch einen Test-Harness schreiben, AFL++ für das Fuzzing aufrufen, den Coverage-Bericht auswerten, den Harness anhand der erreichten Abdeckung überarbeiten, jeden einzelnen Absturz klassifizieren und schließlich einen Schwachstellenbericht samt Patch-Vorschlag im einheitlichen Diff-Format erzeugen.
Beim Coverage-Feedback wird das Zeitbudget jede Runde verdoppelt: beginnend bei 30 Sekunden, dann der Reihe nach 60, 120, 240, 480 und 960 Sekunden — pro Ziel insgesamt etwa 32 Minuten. Nach jeder Runde prüft der Agent die Abdeckung und entscheidet, was als Nächstes angepasst wird.
Damit die zufällige Mutation das Eingabeformat besser versteht, stapelt die Pipeline vier "strukturbewusste" Ebenen übereinander: formatspezifische Wörterbücher samt eigenen Mutatoren, aus dem Quellcode extrahierte Wörterbücher, während des Laufs dynamisch erzeugte AFL-Wörterbücher sowie das Zusammenfügen von Korpusdaten (Splicing).
Die Absturzklassifizierung ist recht feingliedrig: echte Schwachstelle (vulnerability), Empfehlung zur Bibliothekshärtung (library_hardening), Fehler im Harness selbst (harness_bug), Speichererschöpfung, Timeout, fehlgeschlagene Assertion und Duplikat. Abstürze werden zunächst mit afl-tmin minimiert und anschließend anhand des Stacktrace dedupliziert. Während des Laufs zeigt zudem ein HTML-Dashboard auf Port 8765 den Fortschritt in Echtzeit.
Morales formuliert dazu ein klares Prinzip der Arbeitsteilung:
"the LLM agent owns the decisions, and the MCP tools own the execution"
(Die Entscheidungen liegen beim LLM-Agenten, die Ausführung bei den MCP-Werkzeugen.)
Im Vergleich zu OSS-Fuzz
LLMs in Fuzzing-Prozesse einzubinden, hat Google früher begonnen. OSS-Fuzz testet bereits seit 2023 den Einsatz von LLMs zur automatischen Generierung von Fuzz-Targets, und Ende 2024 erklärte Google öffentlich, dieser Ansatz habe geholfen, mehrere Probleme zu finden, darunter eine Schwachstelle in OpenSSL. Jener Ansatz löst vor allem den Schritt "Harness schreiben" — das Projekt selbst muss zuvor an die Infrastruktur von OSS-Fuzz angebunden sein.
GitHubs Ansatz gleicht eher einem mitnehmbaren Werkzeugkasten: Er verlangt keine Anbindung an irgendeine Plattform, es genügt eine cloudbasierte Entwicklungsumgebung, und Triage sowie Berichtserstellung sind gleich mit dabei. Gleich zu Beginn weist der Artikel darauf hin, dass kontinuierliches Fuzzing kein Allheilmittel ist — Projekte, die seit Jahren bei OSS-Fuzz laufen, können trotzdem gravierende Bugs verstecken, und das ist auch der Hintergrund, warum xz als Demoprojekt gewählt wurde. xz war 2024 von einem Hintertür-Vorfall betroffen, der die gesamte Open-Source-Szene erschütterte, doch das war eine gezielte Vergiftung des Codes (Poisoning) und damit eine andere Kategorie als die Speicherfehler, die Fuzzing aufdecken kann.
Was der Artikel nicht verrät
Einige der für Außenstehende interessantesten Zahlen bleiben unveröffentlicht: wie viele Abstürze bei xz und cJSON jeweils gefunden wurden, wie viele davon als echte Schwachstellen eingestuft wurden, ob CVEs vergeben wurden; der Token- und Kostenaufwand für einen kompletten Durchlauf pro Projekt; die Falsch-Positiv-Rate. Der Autor selbst formuliert recht zurückhaltend: Die Triage-Ergebnisse seien als "ein gut vorbereiteter Ausgangspunkt für einen Menschen" zu verstehen, nicht als Endergebnis, und auch die Patch-Vorschläge sind durchweg als prüfungsbedürftig gekennzeichnet.
Auch sicherheitstechnisch gibt es eine wichtige Voraussetzung. Die Pipeline läuft ohne Container-Isolation; offiziell wird empfohlen, sie ausschließlich in Codespaces oder temporären virtuellen Maschinen laufen zu lassen — also in wegwerfbaren Umgebungen — und ihr keine erhöhten Rechte zu geben. Teams, die eine direkte Bereitstellung im firmeninternen Netzwerk planen, stoßen an dieser Stelle früher an Grenzen als bei der Modellwahl.
Für Maintainer quelloffener Bibliotheken in China liegt die Hauptschwelle beim Modell: Die Standardkonfiguration ruft ein Modell von Anthropic auf, eine direkte Verbindung aus China ist unpraktisch. Das Repository ist offen, ein Wechsel auf ein anderes kompatibles Modell wäre theoretisch möglich, ob die Ergebnisqualität dabei erhalten bleibt, ist bislang nicht öffentlich getestet.
Quellen: offizieller GitHub-Blog, Beschreibung im Open-Source-Repository seclab-taskflows-fuzzing, CocoLoop, öffentlich zugängliche Materialien zu Google OSS-Fuzz; Ablauf der Pipeline, Zeitbudget und Absturzklassifizierung folgen der Darstellung im GitHub-Blog.