google/oss-fuzz-gen: Fuzz-Targets von LLMs erzeugen und gegen OSS-Fuzz messen

Welche Lücke das Projekt schließt

Fuzz-Targets zu schreiben ist Handarbeit. Wer eine C- oder C++-Bibliothek absichern will, muss die Einstiegspunkte kennen, die Eingabeformate verstehen und einen Harness bauen, der libFuzzer oder einem anderen Motor eine sinnvolle Schnittstelle bietet. Genau dieser Schritt skaliert nicht mit der Zahl der Bibliotheken, die abgesichert werden müssten. Das Repository setzt dort an: Ein Large Language Model erzeugt den Fuzz-Target-Code, das Framework kompiliert ihn und misst anschließend, ob er mehr erreicht als ein von Menschen geschriebener Harness. Die Zielgruppe sind laut README Forschende und Mitwirkende, die Fuzz-Targets für reale Projekte in C, C++, Java und Python generieren und über die OSS-Fuzz-Plattform benchmarken wollen. Das ist ein enges Publikum. Wer keinen Zugang zu einem OSS-Fuzz-Projekt hat, kann den Auswertungsteil nicht nutzen.

Der Ablauf: Prompt, Generierung, Kompilierung, vier Metriken

Die Kette beginnt bei einem Prompt-Builder. Das README verweist auf prompts/template_xml als Standardvorlage und nennt daneben einen Test-to-harness-Ansatz, bei dem aus vorhandenen Tests ein Harness abgeleitet wird. Das Modell erzeugt daraus Quelltext für einen Fuzz-Target. Danach übernimmt die OSS-Fuzz-Plattform: Der generierte Code wird kompiliert, gegen die aktuellen Produktionsdaten ausgeführt und mit vier Metriken bewertet. Diese vier sind Compilability, Runtime crashes, Runtime coverage und der Line-Coverage-Unterschied gegenüber bestehenden, von Menschen geschriebenen Targets in OSS-Fuzz. Der letzte Punkt ist der interessante, weil er nicht nur fragt, ob der generierte Harness läuft, sondern ob er mehr Code erreicht als der bereits vorhandene. Die Datenbasis sind laut README über 1300 Benchmarks aus 297 Open-Source-Projekten, Stand Januar 2024. Die Detailberichte sind nicht öffentlich, weil sie unveröffentlichte Schwachstellen enthalten können.

Modellauswahl als Konfigurationsfrage

Das Framework bindet mehrere Anbieter an. In der Liste stehen Vertex AI code-bison und code-bison-32k, Gemini Pro, Gemini Ultra, Gemini Experimental und Gemini 1.5 sowie von OpenAI GPT-3.5-turbo, GPT-4, GPT-4o, GPT-4o-mini und GPT-4-turbo, dazu dieselben OpenAI-Modelle über Azure. Diese Aufzählung ist kein Marketing, sie bestimmt den Aufwand beim Aufsetzen: Jeder Anbieter braucht eigene Zugangsdaten und eigene Endpunktkonfiguration. Wer das Framework ausprobieren will, muss sich zuerst für einen dieser Wege entscheiden und die entsprechenden Schlüssel hinterlegen. Die Modellwahl schlägt sich auch in den Ergebnissen nieder. In der Tabelle der gefundenen Fehler ist durchgehend Vertex AI als Modell vermerkt, was schlicht daran liegen dürfte, dass die Experimente mit diesem Anbieter gefahren wurden. Ein Vergleich der Modellqualität lässt sich aus der Tabelle nicht ableiten.

Was die Fehlertabelle tatsächlich zeigt

Das README listet 30 gemeldete Fehler und Schwachstellen, die aus automatisch generierten Targets stammen. Die Einträge reichen von Out-of-bounds-Reads in cJSON, libplist, hunspell und htslib über einen Out-of-bounds-Write in zstd bis zu CVE-2024-9143 in openssl. Bei mehreren Zeilen steht als Target-Oracle derselbe Eintrag: Far reach, low coverage. Das ist die eigentliche Aussage der Tabelle. Die Auswahl der generierten Targets, die überhaupt weiterverfolgt werden, hängt an Heuristiken wie weitreichender Erreichbarkeit bei gleichzeitig niedriger Abdeckung. Wer diese Oracle-Logik nicht versteht, kann die Trefferquote nicht einordnen. Bemerkenswert ist auch die Verteilung: Ein großer Teil der Einträge stammt aus einer kleinen Zahl von Projekten, gpac taucht mehrfach auf. Das deutet darauf hin, dass die Ausbeute stark vom jeweiligen Projektzuschnitt abhängt und nicht gleichmäßig über die 297 Projekte streut.

Inbetriebnahme und der Weg über USAGE.md

Das README selbst bleibt bei der Bedienung knapp. Es verweist für die Ausführung und die Reporterzeugung auf USAGE.md und für das separate Ausführen oder Bewerten einzelner Agenten auf agent_tests/readme.md. Konkrete Kommandozeilenaufrufe stehen im vorliegenden Material nicht, deshalb lässt sich hier kein Befehl nennen, der garantiert funktioniert. Klar ist nur die Struktur: Es gibt einen vollständigen Experimentpfad über die Benchmark-Sammlung und einen zweiten, leichteren Pfad, mit dem einzelne Agenten oder Agentensequenzen ohne vollständiges Experiment ausgeführt werden können. Der zweite Pfad ist für die Fehlersuche relevant, weil er den Modellaufruf vom OSS-Fuzz-Auswertungslauf trennt. Wer das Framework evaluiert, sollte mit diesem Pfad beginnen und erst danach ein vollständiges Experiment starten. Alles Weitere ist USAGE.md zu entnehmen.

Grenzen und Fälle, in denen das Werkzeug nicht passt

Die offensichtlichste Einschränkung steht im README selbst: Die Ergebnisberichte sind nicht öffentlich. Wer die Zahlen nachprüfen will, muss sie selbst erzeugen, und das setzt Zugang zu einem Modellanbieter sowie zu OSS-Fuzz voraus. Ein zweiter Punkt ist die Datenbasis. Die zitierten 1300 Benchmarks und die 160 C/C++-Projekte mit gültigen Targets stammen aus einem Experiment vom Januar 2024. Ob die aktuellen Benchmark-Sets dieselbe Abdeckung haben, sagt das Material nicht. Drittens die Sprachverteilung: Genannt werden C, C++, Java und Python, die Erfolgszahlen im README beziehen sich aber ausschließlich auf C/C++-Projekte. Für Java und Python liefert das Material keine vergleichbare Ausbeute. Und schließlich die Abhängigkeit von der Plattform. Ohne ein OSS-Fuzz-Projektverzeichnis für die Zielbibliothek gibt es keinen Ort, an dem kompiliert und gemessen werden kann. Für eine kleine Bibliothek, die nie in OSS-Fuzz aufgenommen wurde, ist das Framework der falsche Weg. Ein einzelner libFuzzer-Harness von Hand ist dort schneller geschrieben als jede Pipeline aufgesetzt.

Der Unterschied zu ClusterFuzzLite

ClusterFuzzLite ist die naheliegende Alternative, wenn es um das Ausführen von Fuzzing in CI geht, nicht um das Erzeugen von Targets. Der Unterschied liegt im Ansatzpunkt. ClusterFuzzLite nimmt vorhandene Fuzz-Targets und betreibt sie in einer CI-Umgebung, mit Korpusverwaltung und Absturzberichten. oss-fuzz-gen geht eine Stufe davor an und versucht, den Harness selbst zu erzeugen und ihn gegen die bestehenden, menschlich geschriebenen Harnesses zu messen. Die beiden überschneiden sich kaum: Wer bereits gute Targets hat und nur kontinuierlich fuzzen will, braucht ClusterFuzzLite und nicht dieses Framework. Wer umgekehrt wissen will, ob ein Modell brauchbare Targets für eine bestimmte Bibliothek produzieren kann, braucht die vier Metriken aus oss-fuzz-gen. Eine dritte Option ist, den Harness einfach selbst zu schreiben. Das kostet je nach Bibliothek Stunden bis Tage, liefert aber Code, dessen Qualität man kennt, ohne eine Modellabhängigkeit im Build zu haben.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Repository steht unter Apache-2.0, einer permissiven Lizenz mit einer ausdrücklichen Patentgewährung. Für die Nutzung im Unternehmen ist das unproblematisch, solange die Lizenz- und Urheberrechtshinweise erhalten bleiben. Rechtlich relevant ist eher der vorgelagerte Schritt: Der generierte Fuzz-Target-Code stammt aus einem Modell, und die Bedingungen des jeweiligen Anbieters können die Verwendung der Ausgaben regeln. Das Framework selbst trifft dazu keine Aussage, und eine Einschätzung dazu gehört in die Rechtsabteilung, nicht in dieses Review. Wartungsseitig fällt auf, dass keine Releases im Material auftauchen und dass die zitierten Zahlen aus Januar 2024 stammen, während der letzte Push im März 2026 liegt. Ob die Experimente in der Zwischenzeit wiederholt wurden, geht aus dem README nicht hervor. Die Modellliste ist ein Wartungspunkt für sich: Anbieterdeprecations bei Vertex AI oder OpenAI machen Anpassungen nötig. Vor einem Einsatz sind drei Dinge zu klären: ob das Zielprojekt in benchmark-sets/all enthalten ist, ob ein OSS-Fuzz-Projektverzeichnis existiert, und welcher Modellendpunkt verwendet werden soll. Steht eine dieser drei Fragen offen, ist der Aufwand nicht abschätzbar.

Redaktionelles Fazit

Wer bereits OSS-Fuzz-Projekte betreibt, Zugang zu Vertex AI oder OpenAI/Azure-Endpunkten hat und die vier Metriken (Compilability, Runtime crashes, Runtime coverage, Line-Coverage-Diff) reproduzierbar messen will, findet hier den passenden Rahmen. Wer nur schnell einen Harness für eine kleine Bibliothek braucht, greift zu libFuzzer direkt oder zu ClusterFuzzLite. Vor dem ersten Lauf ist zu klären, ob das Projekt in benchmark-sets/all auftaucht und ob ein passendes OSS-Fuzz-Projektverzeichnis existiert, denn ohne dieses Ziel kann die Auswertung nicht ansetzen.

Offizielle Quellen

1. google/oss-fuzz-gen on GitHub
2. Issues
3. License: Apache-2.0
4. README