GitHub Security Lab veröffentlicht einen Agenten, der Fuzz-Harnesses schreibt
Serguey Asael Shinder2 Min. LesezeitGitHub Security Lab hat den Fuzzing Taskflow veröffentlicht, eine autonome Fuzzing-Pipeline für C- und C++-Projekte auf Basis des hauseigenen Taskflow-Agent-Frameworks; vorgestellt wurde sie am 24. September im GitHub Blog. Mit nichts als dem Kürzel owner/repo eines Repositorys wählt die Pipeline Einstiegspunkte, analysiert das Build-System, schreibt Harnesses, startet AFL++, liest Abdeckungsberichte, verbessert die Harnesses, sichtet Abstürze und schreibt zu jedem eindeutigen Fehler einen Bericht.
Der Entwurf trennt Urteil und Ausführung. Ein LLM-Agent entscheidet, was gefuzzt wird, welches Harness entsteht und welcher Abdeckungslücke nachgegangen wird; eine Reihe von MCP-Werkzeugen erledigt die eigentliche Arbeit - ein Harness kompilieren, AFL für ein Zeitbudget starten, einen Absturz ablegen -, und der gesamte Zustand liegt in einer SQLite-Datenbank statt im Speicher zwischen den Stufen. Jedes Harness wird zweimal gebaut: einmal mit AFL-Instrumentierung sowie AddressSanitizer und UBSan zum Fuzzen, einmal mit clangs quellbasierter Abdeckung, damit die Queue in einen lesbaren Bericht über Zeilen und Verzweigungen übertragen werden kann. Nach jeder Runde liest der Agent die nicht abgedeckten Verzweigungen und entscheidet, ob er ein neues Harness schreibt, magische Konstanten in AFLs Wörterbuch aufnimmt oder einen kalten Fehlerpfad überspringt. Die Zeitbudgets verdoppeln sich von 30 bis 960 Sekunden, und die Schleife endet, wenn zwei Runden hintereinander jeweils weniger als einen Prozentpunkt Zeilenabdeckung bringen. Standardmäßig nutzt die Pipeline laut Beitrag Claude Sonnet 5, weil dieses Modell alle internen Tests bestanden habe; das Modell ist austauschbar.
Der Autor benennt das Risiko ausdrücklich: Der Taskflow führt afl-fuzz, clang und vom Modell gewählte Build-Befehle direkt auf dem Host aus, ohne Container, und ein per Prompt Injection manipulierter Agent könnte alles tun, was der Nutzer darf. Der Rat lautet, ihn nur in einer Wegwerfumgebung wie einem Codespace oder einer Einweg-VM zu starten, ohne erhöhte Rechte.
Was das bedeutet
Die Kernaussage des Beitrags: Teuer am Fuzzing war nie das Laufenlassen des Fuzzers, sondern die menschliche Schleife drumherum - bemerken, dass die Abdeckung stagniert, das nächste Harness schreiben, das Ergebnis sichten. Diese Schleife zu automatisieren macht Fuzzing für Projekte denkbar, die nie jemanden dafür übrig hatten.
Ernst nehmen sollte man die Warnung. Ein Fuzzing-Agent liest Build-Dateien und Quellcode des Zielrepositorys - und genau diese Eingabe kontrolliert ein Angreifer. Einen Agenten, der Build-Befehle ausführt, auf ein nicht vertrauenswürdiges Projekt anzusetzen, heißt, den Code dieses Projekts auszuführen, nur mit Umwegen. Die empfohlene Umgebung - isoliert, ohne Rechte, wegwerfbar - ist die einzig vernünftige, und wer solche Werkzeuge einführt, sollte jedes nicht selbst geschriebene Repository als feindliche Eingabe für den Agenten behandeln, nicht nur für den Fuzzer.