Für Teams, die Parser, Bibliotheken, SDKs, Protokolle oder Anwendungskomponenten für nicht vertrauenswürdige Eingaben entwickeln.

Wenn fehlerhafte Dateien, Nachrichten oder Eingaben eine Schwäche offenlegen könnten.

Was wir prüfen

Eignung des Ziels, Build-Anforderungen, Einstiegspunkte und Testziele bewerten.
Den vereinbarten Testansatz für die ausgewählte Komponente einrichten und ausführen.
Fehler untersuchen und deduplizieren, nützliche Beispiele minimieren und ihre Sicherheitsrelevanz bewerten.

Ein klarer Einstieg. Ein brauchbares Ergebnis.

Die Aufgabe beschreiben

Nennen Sie Produkt, Stack, Ziel und Termin. Ein kurzer Überblick genügt für den ersten Austausch.

Den Auftrag vereinbaren

Vor Beginn erhalten Sie schriftlich Umfang, Ergebnisse, Abnahmekriterien, Preis und Zeitplan.

Den Fortschritt gemeinsam prüfen

Bei Prüfungen besprechen wir Nachweise und Prioritäten. Bei Entwicklung prüfen wir vereinbarte Umsetzungsschritte.

Das Ergebnis nutzen

Sie erhalten eine technische Erläuterung und brauchbare Übergabe. Weitere Umsetzung oder Verifikation vereinbaren wir nach Bedarf.

Ich untersuche bis zur Ursache.

Forschung an Facebook und Instagram, über 300 untersuchte Linux-Kernel-Berichte und Befunde, acht Patches und zwei veröffentlichte CVEs. Ich verbinde auffälliges Verhalten mit dem Code, den auslösenden Bedingungen und den Folgen für Ihr Produkt.

Kernel-Befunde und Korrekturen ansehen

Fragen vor dem Beginn

Was macht ein geeignetes Fuzzing-Ziel aus?

Eine Komponente mit klaren Eingabegrenzen und einer zugänglichen Build- oder Ausführungsumgebung. Parser, Bibliotheken und Protokollhandler sind geeignete Kandidaten. Wir bestätigen die Eignung vor der Vereinbarung einer Kampagne.

Können wir mit einem kleinen Pilotprojekt beginnen?

Ja. Eine bezahlte Machbarkeitsphase kann klären, ob das Ziel praktikabel ist, welche Einrichtung es braucht und was eine größere Kampagne umfassen sollte.

Erhalten wir einen Harness oder einen weiter nutzbaren Testaufbau?

Die Artefakte werden bei der Umfangsplanung vereinbart. Je nach Ziel können sie einen Harness, Startinputs, Ausführungsanleitungen, Reproduktionsbeispiele oder Integrationshinweise umfassen. Das Angebot benennt sie.

Bedeutet jeder Absturz eine Schwachstelle?

Nein. Fehler müssen untersucht werden. Der Bericht unterscheidet beobachtetes Verhalten, bestätigte Sicherheitsauswirkungen und offene Fragen; eine Anzahl von Schwachstellen oder CVEs wird nicht versprochen.

Gezieltes Fuzzing