Eine brauchbare **Absturzmeldung aus einem Fuzz-Test** enthält neben der auslösenden Eingabe den genauen Build des Zielprogramms, den Befehl, die Umgebung und den beobachteten Fehler. Halten Sie fest, wie zuverlässig sich der Fehler reproduzieren lässt, wer ihn untersucht und welche Fragen zu den Sicherheitsfolgen offenbleiben. Sobald ein Patch vorliegt, bewahren Sie auch die Ergebnisse des erneuten Tests auf. Kümmern Sie sich um diese Übergabe, bevor Sie einen weiteren Nachmittag lang Eingaben erzeugen. Ein Verzeichnis voller Absturzdateien lässt für den zuständigen Entwickler womöglich grundlegende Fragen offen: Welches Programm hat diese Dateien erzeugt? Tritt der Fehler auch außerhalb des Fuzzing-Prozesses auf? Wurde das Zielprogramm mit einem Sanitizer gebaut, der Speicherfehler erkennt? Welches Ergebnis würde als Fehlerbehebung gelten? Chris Wellons’ [Hinweise zum Testen mit AFL++](https://nullprogram.com/blog/2025/02/05/) waren am 2. November 2026 erneut Gegenstand einer [Diskussion auf Hacker News](https://news.ycombinator.com/item?id=50271106). Der Artikel stammt vom 5. Februar 2025; die aktuelle Diskussion greift also einen älteren technischen Leitfaden auf. Sein Praxisbezug eignet sich als Ausgangspunkt für eine andere Frage: Wie wird aus einem Fund eine Aufgabe, die jemand anderes übernehmen kann? Das folgende Vorgehen ist ein Vorschlag für die Übergabe in einem kleinen Entwicklungsteam. Es stützt sich auf die Dokumentation von AFL++ und ClusterFuzz. Wir berichten hier weder von einer selbst durchgeführten Fuzzing-Kampagne, noch beschreibt das Parserbeispiel eine tatsächlich entdeckte Schwachstelle. ## Sichern Sie den Versuchsaufbau, bevor Sie ihn vereinfachen Bewahren Sie genügend Kontext auf, um den fehlgeschlagenen Durchlauf nachzustellen. Die Eingabe allein reicht nicht: Erst zusammen mit Programmdatei, Test-Harness, Konfiguration und Beobachtungen wird der Befund nachvollziehbar. Der **Test-Harness** ist der Code, der erzeugte Eingaben an die zu prüfende Funktion oder das Programm übergibt. Erfassen Sie seine Revision zusammen mit der Revision des Zielprogramms. Ändert jemand die Initialisierung eines Parsers oder die Übergabe eines Puffers im Harness, prüft dieselbe Eingabe womöglich einen anderen Versuchsaufbau. Speichern Sie die ursprüngliche Eingabe in einer zugriffsbeschränkten Artefaktablage und hinterlegen Sie eine dauerhafte Referenz in der Meldung. Sichern Sie die relevanten Ausgaben, bevor Sie Programmdateien ersetzen oder die Umgebung neu aufbauen. Erfassen Sie Plattform, Compiler, Build-Optionen, Sanitizer-Konfiguration und Laufzeitoptionen, soweit diese bekannt sind. Kennzeichnen Sie fehlende Angaben ausdrücklich, statt sie aus dem Gedächtnis zu ergänzen. Angenommen, ein fiktiver Test-Harness für einen Dokumentenparser stürzt bei einer gespeicherten Datei ab. „Parser stürzt bei diesem Anhang ab“ lässt mehrere Erklärungen zu. Die Datei könnte einen Fehler im Zielprogramm auslösen, der Harness könnte den Parser falsch aufrufen, oder der Fehler könnte nur mit einer bestimmten Laufzeiteinstellung sichtbar werden. Die erste Notiz sollte den Ablauf festhalten, ohne sich vorschnell auf eine dieser Erklärungen festzulegen. Wellons behandelt zwei nützliche Fehlerquellen im Harness innerhalb seines beschriebenen Einsatzbereichs: C/C++ mit verfügbarem Quellcode unter Linux mit glibc. Zum einen kann Zustand zwischen Durchläufen im Persistent Mode erhalten bleiben. Zum anderen können übergroße Eingabepuffer manche Lesezugriffe außerhalb der vorgesehenen Grenzen vor AddressSanitizer verbergen. Diese Beispiele zeigen, warum auch der Versuchsaufbau geprüft werden muss. Sie sind keine Aufforderung, sämtliche Compiler-Einstellungen auf eine andere technische Umgebung zu übertragen. Bewahren Sie die einzige Kopie einer sensiblen Eingabe nicht als Anhang in einem öffentlichen Issue auf. Ein erzeugter Testfall kann harmlos sein; bei einer Untersuchung können aber auch echte Dokumente, interne Pfade oder Diagnoseausgaben anfallen. Klären Sie, wer Zugriff braucht, und bewahren Sie das Artefakt dort auf, wo diese Personen es abrufen können. Kann der nächste Entwickler einen Link nicht öffnen, bleibt die Übergabe unvollständig. ## Machen Sie den Reproduktionsbefehl übertragbar Eine Anleitung zur Reproduktion sollte es dem nächsten Entwickler ermöglichen, den vorgesehenen Fall ohne Rätselraten über lokale Gepflogenheiten auszuführen. Dokumentieren Sie den Befehl zusammen mit Arbeitsverzeichnis, benötigter Eingabe und relevanten Umgebungsangaben. [ClusterFuzz stellt bei der Fehlerbehebung](https://google.github.io/clusterfuzz/using-clusterfuzz/workflows/fixing-a-bug/) den auslösenden Testfall und den Build bereit und erfasst Befehlszeile sowie wichtige Umgebungsvariablen. Laut Dokumentation können diese Variablen nötig sein, um den Fehler zu reproduzieren. Das ist auch dann ein nützliches Vorbild, wenn Ihr Team ein anderes Werkzeug verwendet. Identifizieren Sie die Programmdatei für die Übergabe über eine dauerhafte Build-Referenz und die Quellcode-Revision. Erklären Sie, ob das Programm eine Datei, die Standardeingabe oder eine andere Schnittstelle liest. Beschreiben Sie, wie sich die ausführbare Datei beschaffen oder bauen lässt. Ersetzen Sie rechnerspezifische Pfade erst dann durch dokumentierte Ablageorte, wenn Sie geprüft haben, dass die überarbeitete Anleitung weiterhin denselben Durchlauf beschreibt. Trennen Sie Vorbereitung und Ausführung. Benötigt der zuständige Entwickler ein bestimmtes Container-Image, ein Verzeichnis mit Testdaten oder eine Build-Konfiguration, gehört diese Voraussetzung vor den Reproduktionsbefehl. Verstecken Sie einen notwendigen Vorbereitungsschritt nicht in einer alten Chatnachricht. Beschreiben Sie anschließend die Beobachtung genau. „Schlägt fehl“ kann eine Sanitizer-Meldung, ein Prozesssignal, eine Zeitüberschreitung oder eine unerwartete Ausgabe bedeuten. Sichern Sie die relevante Diagnose und nennen Sie das stattdessen erwartete Verhalten. Ein Bildschirmfoto kann beim Wiedererkennen des Ergebnisses helfen. Es sollte jedoch nicht die einzige Aufzeichnung eines Befehls oder einer Fehlermeldung sein, die jemand kopieren und untersuchen muss. Dokumentieren Sie Versuche als Beobachtungen. Lässt sich ein Fall nur gelegentlich reproduzieren, nennen Sie das und beschreiben Sie die geprüften Bedingungen. Ein einzelner erfolgloser Wiederholungsversuch belegt nicht, dass der ursprüngliche Fund ungültig war. Legen Sie einen Versuch fest, der den Unterschied erklären könnte, etwa einen Vergleich mit dem ursprünglichen Build oder eine Prüfung des Harness-Zustands. ## Trennen Sie einen kleineren Testfall von der Sicherheitsbewertung Eine verkleinerte Eingabe kann die Untersuchung erleichtern. Sie belegt für sich genommen weder, dass der Fehler ausnutzbar ist, noch, dass er in Ihrem Produkt erreichbar ist. [AFL++ beschreibt `afl-tmin`](https://aflplus.plus/docs/fuzzing_in_depth/#4-triaging-crashes) zur Minimierung von Testfällen. Bewahren Sie den ursprünglichen Fall neben der verkleinerten Variante auf und dokumentieren Sie, wie diese entstanden ist. Prüfen Sie die relevante Beobachtung erneut, bevor Sie die verkleinerte Variante als Ersatz verwenden. Die kleinere Datei soll den untersuchten Fehler verständlicher machen, statt lediglich irgendeinen Fehler auszulösen. Dieselbe Dokumentation weist darauf hin, dass die Bewertung der Ausnutzbarkeit erheblichen Aufwand bei Fehlersuche und Codeanalyse erfordern kann. Halten Sie diese Unterscheidung in der Meldung fest. „Vom Sanitizer gemeldeter Fehler reproduziert“ ist ein nützliches Ergebnis. „Aus der Ferne ausnutzbare Schwachstelle bestätigt“ erfordert deutlich mehr Nachweise als einen abgestürzten Prozess. Beim fiktiven Parser könnten sich die nächsten Fragen darauf richten, ob der betroffene Code im ausgelieferten Build enthalten ist, ob nicht vertrauenswürdige Dokumente ihn erreichen können und welche Berechtigungen der Parserprozess hat. Das sind Untersuchungsfragen, keine feststehenden Tatsachen des Beispiels. Dokumentieren Sie die bekannte Angriffsfläche getrennt von Annahmen. Auch eine Gruppierung dient zunächst der Organisation der Untersuchung. Mehrere gespeicherte Dateien oder ähnliche Stacktraces belegen für sich genommen nicht, wie viele unterschiedliche Fehlerursachen oder ausnutzbare Schwachstellen vorliegen. Verknüpfen Sie zusammengehörige Beobachtungen, und lassen Sie die Gruppierung für neue Erkenntnisse offen. Benötigt die Untersuchung ein Verfahren zur öffentlichen Offenlegung, nutzen Sie Ihr [Vulnerability Disclosure Program](/blog/how-to-set-up-vulnerability-disclosure-program). Reproduktionsnachweise helfen dabei; sie bestimmen weder den Offenlegungszeitpunkt, noch berechtigen sie zur Veröffentlichung sensibler Artefakte. ## Übergeben Sie eine Meldung mit einem klaren nächsten Versuch Die Meldung sollte zwei Fragen schnell beantworten: Was kann die nächste Person reproduzieren, und welche Unklarheit soll sie als Nächstes untersuchen? Sie können diese Vorlage an Ihr Meldungssystem anpassen. Sie ist ein Dokumentationsvorschlag, keine Vorgabe eines Werkzeugs. Verlinken Sie auf zugriffsbeschränkte Artefakte, statt alles in die Beschreibung zu kopieren. ```text Zielprogramm und Quellcode-Revision: Harness-Revision und Einstiegspunkt: Plattform, Compiler, Build-Optionen und Sanitizer-Einstellungen: Ursprüngliche Eingabe und Artefaktablage: Verkleinerte Eingabe und Verkleinerungsmethode, falls vorhanden: Reproduktionsbefehl und Arbeitsverzeichnis: Beobachteter Fehler und relevante Ausgabe: Erwartetes Verhalten: Reproduktionsversuche und Ergebnisse: Bekannte Angriffsfläche und noch zu bewertende Auswirkungen: Zuständige Person und nächster Versuch: Patch-Revision, Ergebnisse des erneuten Tests und Regressionstest: ``` Sie brauchen nicht jede Antwort, bevor Sie eine Meldung anlegen. Sie müssen aber ein leeres Feld von einer überprüften Schlussfolgerung unterscheiden. „Revision des Zielprogramms unbekannt; Build-Referenz bei meldender Person angefragt“ sagt mehr aus als ein selbstsicher gesetzter Status auf unvollständiger Grundlage. [Die Dokumentation von ClusterFuzz zur Sichtung](https://google.github.io/clusterfuzz/using-clusterfuzz/workflows/triaging-new-crashes/) nennt die Zuverlässigkeit der Reproduktion, Absturztyp, Plattform und die Eingrenzung der fehlerverursachenden Revisionen als hilfreiche Untersuchungsdaten. Diese Eingrenzung steht für zuverlässig reproduzierbare Abstürze zur Verfügung. Ihre eigene Dokumentation kann dieselben Unterschiede festhalten, ohne zu behaupten, der verursachende Commit sei bereits ermittelt. Eine kurze Entscheidungstabelle zeigt, welche Handlung als Nächstes sinnvoll ist: | Vorliegende Nachweise | Nächste sinnvolle Handlung | Noch offene Schlussfolgerung | | --- | --- | --- | | Eingabe ohne passenden Build oder Befehl | Fehlenden Reproduktionskontext anfordern | Ob ein anderer Entwickler den Fehler wiederholen kann | | Wiederholbarer Fehler im dokumentierten Aufbau | Untersuchung von Ursache und Angriffsfläche zuweisen | Sicherheitsfolgen und betroffene Produktbereiche | | Sporadischer Fehler | Versuche sichern und unterschiedliche Bedingungen untersuchen | Warum sich die Zuverlässigkeit verändert | | Mehrere offenbar zusammenhängende Fälle | Nachweise vergleichen und Verknüpfungen pflegen | Anzahl unterschiedlicher Fehlerursachen | | Patch ohne Ergebnisse eines erneuten Tests | Dokumentierten Fall mit dem korrigierten Build prüfen | Ob der beobachtete Fehler behoben ist | Benennen Sie eine Person für den nächsten Versuch. Im Parserbeispiel könnte das der Entwickler sein, der das Verhalten des Harness mit dem Einstiegspunkt im Produktivbetrieb vergleichen kann. Die Meldung sollte festhalten, was diese Person prüft und wo sie das Ergebnis dokumentiert. Bleibt ein bestätigter Fund später bei einer Kompatibilitäts- oder Freigabeentscheidung liegen, ist das eine andere Aufgabe. Unser [Leitfaden zur Eskalation von Sicherheitskorrekturen](/blog/security-fix-decision-escalation) beschreibt, wie Sie dafür eine zuständige Person und einen Prüftermin festlegen. ## Prüfen Sie den Patch anhand des dokumentierten Fehlers Eine Patch-Referenz zeigt, was geändert wurde. Das Ergebnis des erneuten Tests zeigt, was beim erneuten Test des relevanten Falls mit dieser Änderung geschah. Bewahren Sie die fehlerhafte Revision, die korrigierte Revision, Konfiguration, Testfallreferenz und Ergebnisse zusammen auf. Nehmen Sie den Fall nach Möglichkeit in Ihre Regressionstests auf, damit spätere Änderungen das korrigierte Verhalten erneut prüfen. Beschreiben Sie das erwartete Ergebnis so deutlich, dass ein späterer Entwickler den Zweck des Tests versteht. ClusterFuzz beschreibt bei der Fehlerbehebung, wie Testfälle erneut gegen spätere Builds geprüft werden. Diese Automatisierung gehört zu ClusterFuzz. Wiederholt Ihr Team einen Test manuell oder in einem anderen System, dokumentieren Sie die tatsächliche Methode und das Ergebnis, statt die Prüfkennzeichnung eines anderen Werkzeugs zu übernehmen. Prüfen Sie, ob sich der Versuchsaufbau unbeabsichtigt verändert hat. Ein unauffälliges Ergebnis nach dem Abschalten des relevanten Sanitizers oder einer Änderung am Harness beantwortet womöglich eine andere Frage. Erklären Sie beabsichtigte Konfigurationsänderungen und deren Einfluss auf die möglichen Schlussfolgerungen. Beschreiben Sie bei einem sporadischen Fehler die verbleibende Unsicherheit sowie den gewählten Beobachtungszeitraum oder zusätzliche Tests. Es gibt keine allgemeingültige Anzahl von Versuchen, die das Verschwinden jedes solchen Fehlers belegt. Ebenso stützt ein erfolgreicher erneuter Test eines einzelnen Falls eine Aussage über genau diesen Fall und diese Konfiguration; er bescheinigt nicht die Sicherheit des gesamten Parsers. ## Halten Sie Nachweise und Meldungsstatus in Kit zusammen Fuzzer, Build-System, Debugger und Entwickler liefern die technischen Nachweise. Ein Meldungssystem hilft dabei, diese mit der Untersuchung und der zugehörigen Kommunikation zu verbinden. Sicherheitsmeldungen in Kit unterstützen Reproduktionsnotizen, Bewertungen und Status wie „Klärung erforderlich“, „Bestätigt“, „Behoben“ und „Behebung verifiziert“. Sie können die Zusammenfassung zur Reproduktion und die Referenzen während der Bearbeitung bei der Meldung aufbewahren. Kit verschlüsselt Textfelder der Meldung einschließlich der Reproduktionsschritte im Ruhezustand. Daraus folgt keine Aussage über Artefakte, die Sie andernorts speichern. Ein Status sollte die dokumentierte Arbeit zusammenfassen. Verlinken Sie vor dem Bestätigen einer Fehlerbehebung das tatsächliche Ergebnis des erneuten Tests und machen Sie verbleibende Einschränkungen deutlich. Kit führt weder AFL++ aus, noch minimiert es einen Absturzkorpus, belegt die Ausnutzbarkeit oder führt Ihre Regressionstests aus. Beginnen Sie mit dem nächsten Fund, der bereits auf Bearbeitung wartet. Prüfen Sie, ob ein anderer Entwickler die Eingabe beschaffen, den Build bestimmen, den Befehl ausführen und den beobachteten Fehler verstehen kann. Ergänzen Sie fehlende Angaben, legen Sie den nächsten Versuch fest und bewahren Sie dessen Ergebnis bei der Meldung auf. So kann Ihr Team die Untersuchung konkret fortsetzen.