Was macht Bugfinding-Kampagne?
Wähle ein Experiment aus, das eine neue verletzte Garantie aufdecken kann, und setze dann Rechenleistung entsprechend dem ein, was das Experiment tatsächlich beobachtet. Halte die Kosten für Entdeckung, Reproduktion und Triage sichtbar. Geschwindigkeit ist ein genannter Leistungsfaktor neben „Die Codeabdeckung sollte im Laufe der Zeit wachsen“ und der Behebung blockierender Probleme. Ein nützliches Ziel „muss eine gute Abdeckung des zu testenden Codes aufweisen“; die Anzahl der Ausführungen allein begründet keine nutzbringende Reichweite (OSS-Fuzz Integration, Abdeckung, ClusterFuzz Leistung, Leistungsfaktoren).
Aktuelle Fähigkeit feststellen
Lies die tatsächliche Zielrevision, aktivierte Builds, Harness-Produzenten und Assertion-Körper. Erfasse, welche Eingaben, Anfangszustände, Operationen, Effekte, Zeitpläne, Fehler und Konfigurationen jede vorhandene Testlinie ausüben und beobachten kann. Untersuche Ausschlüsse und abgelehnte Fälle. Verwende Abdeckungs- oder Erreichbarkeits-Tools nur dort, wo deren dokumentierter Build/Laufzeit zutrifft; Fuzz Introspector dokumentiert Berichte „Für Projekte, die in C/C++, Python und Java geschrieben sind“, jeweils mit eigenem Build-Tooling, ist also kein universelles Backend (Fuzz Introspector, Übersicht und Unterschiede im Build-Tooling). Für ein JavaScript- oder TypeScript-Projekt lies das JS-Linien-Inventar.
Zähle eine Fähigkeit als vorhanden, wenn die untersuchte Implementierung sie bereitstellt. Für ein Ziel, das bereits Generierung gültiger Programme, ergebnisübergreifenden Engine-Vergleich und Transaktionshistorien verwendet, ist das Hinzufügen derselben Mechanismen unter neuen Namen nicht der vorgeschlagene Fortschritt. Wähle stattdessen eine nicht abgedeckte Interaktion oder Beobachtung: SQLites dbsqlfuzz „mutiert sowohl die SQL-Eingabe als auch die Datenbankdatei gleichzeitig“ und fand Fehler, die „von früheren Fuzzern übersehen wurden“, ein konkreter Präzedenzfall für die gemeinsame Suche über Dimensionen hinweg. Es ist „ein proprietärer Fuzz-Tester“: Leihe den Mechanismus, nicht ein angenommenes öffentliches Tool (SQLite Testen, §2 und §4.1.3).
Einen Kandidaten ausführbar machen
Beschreibe den Kandidaten in der bestehenden Experimentnotiz des Projekts; führe keinen Dienst oder ein obligatorisches Schema ein. Halte diese Entscheidungen zusammen, mit Beweispfaden. OSS-Fuzz fordert, dass ein Ziel „zumindest einige Fortschritte“ in einem kurzen lokalen Lauf macht, und die Reproduktion benötigt den Build, der zum Bericht passt (OSS-Fuzz Integration, Fuzz Target, Reproduktion, Erstelle das Image und die Fuzzer):
- Produzent und Lücke: tatsächlicher Einstiegspunkt plus der von der Basislinie ausgelassene Fehlerraum.
- Garantie und Orakel: maßgeblicher Vertrag, ausführbare Beobachtung und zulässige/nicht unterstützte/nicht schlüssige Ergebnisse.
- Suche: generierte Werte/Zustände/Operationen und etwaige gesteuerte Zeitplan-, Fehler- oder Konfigurationsentscheidungen.
- Pilot: autorisierter Zeit-/Arbeiter-/Ressourcenrahmen, Wiedergabematerial und die Beweise, die die nächste Zuteilung rechtfertigen.
Entwickle Beobachtungen, bevor du Arbeitslasten vervielfachst. Elles nachverfolgbare Objekte offenbaren Abhängigkeiten, die gewöhnliche Überschreibungen verbergen, da blinde Schreibvorgänge auf ein Register „die Historie zerstören“. Seine Inferenz hat auch explizite Grenzen: der Checker ist schlüssig und „kommt der Garantie von Vollständigkeit nahe“, und „Unser Ansatz ignoriert Prädikate und befasst sich nur mit einzelnen Objekten“. Ein Generator, der mehr nichtssagende Historien produziert, repariert diese Grenzen nicht (Elle, §§3, 4.3 und 9). Verwende correctness-oracles für den allgemeinen Vertrag und einen Spezialisten darunter für dessen spezifisches Modell.
| Fehlende Dimension oder Beobachtung | Relevanter Spezialist |
|---|---|
| Abhängige API-Objekte und zulässige Operationssequenzen | stateful-property-testing |
| Erreichbare Browser- oder React-UI-Zustände ohne Operationsmodell, mit zustandsbezogenen Orakeln und Pfadwiedergabe | ui-state-exploration |
| Laufzeitgültige Programme mit erforderlichem Zustand/Effekten | semantic-program-generation |
| Unabhängiger Ausführungsvergleich oder begründete Lauf-zu-Lauf-Beziehung | semantic-differential-testing, metamorphic-testing |
| Instrumentierungs-/Suchmechanismen oder aufbewahrtes Suchmaterial | coverage-guided-fuzzing, corpus-evolution |
| Speicherzugriffsdiagnostik oder gesteuerte Zeitplanungsoptionen | native-memory-instrumentation, race-detection-campaigns, schedule-exploration |
| Nebenläufige Objekt- oder Transaktionsgarantien | linearizability-checking, transactional-history-testing |
| Bereitstellungsfehler, kontrollierte Umgebung oder Wiederherstellungsgrenzen | distributed-fault-testing, deterministic-simulation, crash-consistency-testing |
| Harte Pfadbeschränkungen oder begrenzte Invarianten | symbolic-concolic-execution, bounded-model-checking |
| Ressourcenwachstum, Fortschritt, Build-Interaktionen oder numerische Genauigkeit | resource-complexity-testing, liveness-testing, configuration-differential-testing, numerical-oracles |
Die Tabelle lenkt die Verantwortlichkeiten dieses Pakets; sie stellt nicht fest, dass ein benanntes Tool das Ziel unterstützt. Lies nur den ausgewählten Spezialisten und seine zutreffenden Referenzen. Verwende harness-sensitivity, um Beweise zu erhalten, dass ein neues Orakel repräsentative Verletzungen erreicht und zurückweist, vorzugsweise anhand bestehender Regressionen oder Kontrollen; SQLites Mutationstests „verifizieren, dass die Testsuite die Mutation abfängt“ (SQLite Testen, §7.6). Halte dies proportional zum Experiment, nicht als wiederkehrende Genehmigungsrunde.
Aus Pilotbeweisen zuweisen
Führe innerhalb des autorisierten Rahmens aus. Überprüfe, ob der Zielcode und die beabsichtigte Eigenschaft ausgeführt werden; unterscheide zwischen nicht erreichbaren Pfaden und erreichbaren Pfaden, die die Mutation noch nicht gelöst hat. Fuzz Introspector vergleicht das „statische Erreichbarkeitspotenzial“ jedes Fuzzers mit der dynamischen Abdeckung für diese Unterscheidung. Ändere das Experiment, wenn ein fehlender Produzent, eine semantische Voraussetzung oder eine fehlende Beobachtung der limitierende Faktor ist (Fuzz Introspector, Übersicht). Für Diagnosen lies Pilotdiagnose.
Erweitere eine informative Testlinie, wenn ihre Beweise mehr Suche rechtfertigen. Vergleiche komplementäre Linien, wo sich ihre Suchmechanismen unterscheiden; AFL++ sagt: „Für jeden sekundären Fuzzer sollte es eine Variation geben“ (AFL++ Tiefe, §3.c Mehrere Kerne verwenden). Verwende tatsächliche Zeit, Arbeiter und Ressourcengrenzen, nicht eine universelle Dauer oder Kernanzahl. Behalte Laufzeit-Flags im Spezialisten; Timeout pro Eingabe, Kampagnendauer und Speicherlimits sind unterschiedliche Steuerelemente (libFuzzer 23.1.0 Optionen).
Behalte Rohzähler für Eigenschaftsauswertungen und semantische/Code-Erreichbarkeit, Rohkandidaten und reproduzierte Funde, Duplikate und Unbekannte sowie Setup-/Ausführungs-/Reduktions-/Triage-Kosten. Fasse sie nicht zu einem erfundenen Produktivitätsscore zusammen. Wo vergleichende Aussagen wichtig sind, verwende übereinstimmende Bedingungen und wiederholte Versuche mit Variabilität; FuzzBench berichtet „die Anzahl der Versuche, Mittelwert, Median, Standardabweichung“ und die „Verteilung der erreichten Abdeckungen“ anstelle eines einzelnen glücklichen Laufs (FuzzBench Bericht, Pro-Benchmark Zusammenfassung).
Bewahre ursprüngliche Eingaben, Startzustand, Quelle/Build/Konfiguration, Instrumentierung, Rohausgaben und Wiedergabeoptionen auf, bevor du zusammenfasst. Ein OSS-Fuzz-Testfall „enthält die Bytes, die dem Ziel zugeführt wurden“, und einige Fehler „sind nur im 32-Bit-Modus oder nur im 64-Bit-Modus unter dem gemeldeten Sanitizer reproduzierbar“; ein Seed allein ist nicht dieses vollständige Artefakt (OSS-Fuzz Reproduktion, Fuzz Target Fehler und Erstelle das Image und die Fuzzer). Leite Kandidaten an failure-reduction und evidence-based-triage weiter; lasse unzuverlässige oder ungeklärte Ergebnisse sichtbar, anstatt sie still zu zählen oder zu verwerfen. ClusterFuzz filtert nach Zuverlässigkeit der Reproduktion und führt Statistiken „darüber, wie oft Probleme auftreten und unter welchen Bedingungen“ (ClusterFuzz Triage, Testfälle filtern und Absturzstatistiken).
Zuteilungsentscheidung abschließen
Halte fortfahren, Dimension ändern, reproduzieren/reduzieren/triage oder stoppen fest, mit dem beobachteten Grund und verbleibendem Raum. Ein Plateau motiviert Diagnose; es beweist weder Korrektheit noch dass ein anderes Tool hilft. Bewahre Nullergebnisse als begrenztes Ergebnis auf. Eine Warteschlange unverarbeiteter Kandidaten kann die Verwendung des nächsten Tranches für Beweise statt für Generierung rechtfertigen. Für abdeckungsgesteuerte libFuzzer- oder AFL-Ziele rät ClusterFuzz: Wenn ein Ziel viele neue Abstürze findet, „ist deren Behebung wahrscheinlich wichtiger als die Analyse der Leistung“ (ClusterFuzz Leistung, Wann die Leistung des Fuzz-Ziels analysiert werden sollte).
Gib die getestete Garantie, das tatsächliche Budget, das erreichte Verhalten, Beweispfade, klassifizierte Funde und die nächste Entscheidung zurück. Beschreibe benutzersichtbare Effekte, wo sie festgestellt wurden; halte eine mögliche Ursache von einer nachgewiesenen Verletzung getrennt. Für eine ausgearbeitete Zuteilung und Aufzeichnung lies Kampagnenbeispiel; für irreführende Abkürzungen lies häufige Fehler.
Der Aufruf erhält den bestehenden Geltungsbereich und die Ausführungsregeln des Benutzers. Er autorisiert selbst keine Zieländerungen, Installationen, Cloud-Ausgaben, Produktionsfehlerinjektion oder externe Veröffentlichung.