Im Bereich des Software Testing ist die Methode des \"Fuzzing\" im Aufwind. Google soll via Fuzzing bereits über 18.000 Bugs in Chrome entdeckt haben. Wir haben mit Sergej Dechand, CEO und Test-Experte des Unternehmens Code Intelligence, über Funktionsweise, Vorteile und Best Practices des Fuzz-Testings gesprochen.

Was ist Fuzzing?

JAXenter: Beginnen wir mit einer kleinen Einordnung. Was versteht man im Kontext des Software Testing unter Fuzzing?

Im Gegensatz zur statischen Analyse hat Fuzzing den großen Vorteil, fast keine False-Positives zu produzieren.

Sergej Dechand: Fuzzing ist eine dynamische Testing-Methode zur Erkennung von Fehlern und Schwachstellen in Software. Im Gegensatz zur statischen Analyse hat Fuzzing den großen Vorteil, fast keine False-Positives zu produzieren. Fuzzing ist in der Lage, White-Box-, Black-Box- oder Grey-Box-Testing durchzuführen. Diese Flexibilität macht Fuzzing zu einem äußerst nützlichen Werkzeug zum Testen von Software, unabhängig von der Verfügbarkeit von Quellcode oder detaillierten internen Informationen. Als Grey-Box-Technik ist das Fuzzing für jeden nützlich, der die Robustheit und Zuverlässigkeit der Systeme, die er betreibt oder einzusetzen plant, verstehen möchte.

JAXenter: Was genau passiert beim Fuzzing?

Sergej Dechand: Beim Fuzzing werden unerwartete Eingaben an die zu testende Software gesendet, um Ausfälle und fehlerhaftes Verhalten zu verursachen. Das erzeugte Fehlverhalten wird auf seine Ursache hin untersucht, und die Fehler können behoben werden, um Zuverlässigkeit und Sicherheit zu gewährleisten. Verursachen die erzeugten Eingaben kein Fehlverhalten, werden neue Eingaben generiert, welche von den vorherigen Eingaben abgeleitet sein können. Software-Lösungen, welche die Fuzzing-Methode einsetzen, nennt man Fuzzer. Ein Fuzzer, welcher diese Generierung bspw. ausführt, ist libFuzzer.

Continuous Integration und Fuzzing

JAXenter: Welche Vorteile bringt es, Fuzzing automatisiert in eine CI-Pipeline zu integrieren?

Sergej Dechand: Ziel ist es, das Testing in den agilen Entwicklungsprozess zu holen und nicht als getrennten Prozess zu betrachten. Es liegt auf der Hand, dass dadurch nicht nur die Effizienz gesteigert wird, sondern auch die Interaktion verschiedener am Prozess beteiligter Disziplinen im positiven Sinne verringert wird. Bugs und Sicherheitslücken können aufgrund eines hohen Automatisierungsgrades früh im laufenden Entwicklungsprozess erkannt und behoben werden, was zu deutlich schnelleren Release-Cycles führt. Im Vergleich zu anderen Testing-Methoden, beispielsweise SAST, können mit Fuzzing mehr Bugs identifiziert und zeitgleich Falschmeldungen, so genannte False-Positives, vermieden werden. 

JAXenter: Können Sie einmal ein Beispiel ausführen, wie eine solche Integration aussehen könnte?

Ziel ist es, das Testing in den agilen Entwicklungsprozess zu holen und nicht als getrennten Prozess zu betrachten.

Sergej Dechand: Nehmen wir an, dass ein Entwicklungsteam einen gemeinsamen Continuous-Integration-Server, beispielsweise Jenkins oder Gitlab CI, nutzt, der mit jeder Änderung des Source-Codes die Software kompiliert und die Tests ausführt. In diesem Schritt wird die Software zusätzlich für das Fuzzing vorbereitet, indem so genannte Fuzz-Targets gebaut werden und die zu testende Software instrumentiert wird. Als Teil der Testing-Pipeline werden die Fuzz-Targets ca. 10 Minuten lang ausgeführt, wodurch der Entwickler quasi sofort Feedback erhält, wenn ein solcher Test fehlschlägt. Zusätzlich werden die Fuzz-Tests nach den 10 Minuten weiter im Hintergrund, ohne dass die Continuous-Integration-Pipeline blockiert wird, ausgeführt, um ggf. tiefer liegende Probleme zu finden.

Feedback-based Application Security Testing

JAXenter: Sie haben mit FAST (Feedback-based Application Security Testing) eine eigene Terminologie entwickelt. Können Sie diese etwas genauer erläutern?

Sergej Dechand: Der Ansatz, den Code Intelligence mit CIFuzz verfolgt, lässt sich aufgrund der Komplexität nicht in herkömmliche Kategorien (SAST/ DAST / IAST) einordnen. Aus diesem Grund haben wir den Entschluss gefasst, eine eigene Terminologie einzuführen. Genau genommen ist FAST aber eine Subkategorie von DAST, da die Applikation während der Runtime getestet wird. Der entscheidende Unterschied im Vergleich zu DAST ist jedoch, dass Feedback, welches von der Applikation zurückkommt, direkt in den Testing-Prozess mit eingebunden wird. Das ist auch ganz klar der USP des Feedback-basierten Fuzzings.

Kürzliche Erfolge von Fuzzing geben unserer Meinung nach dieser Kategorie eine gewisse Berechtigung – so hat zum Beispiel Google über 18.000 Bugs mit Fuzzing in Chrome entdeckt und MongoDB hat verkündet, dass keine Technologie intern so produktiv Bugs findet wie Fuzzing.

Ganz unabhängig von Code Intelligence sind wir davon überzeugt, dass sich Fuzzing zukünftig in Softwareentwicklungsprozessen implementieren muss – in Übersee kann man diesen Trend bereits beobachten!

JAXenter: Die Integration von Software-Testing möglichst früh in den Entwicklungsprozess wird auch als Shift-left bezeichnet. Im DevOps-Kontext spricht man oft von DevSecOps. Neben den entsprechenden Tools benötigt es hier vor allem die richtige Kultur. Wie ist das aus Ihrer Erfahrung: Welche (agilen) Methoden helfen dabei, eine automatisierte Testumgebung einzurichten?

Sergej Dechand: Generell baut automatisiertes Fuzz-Testing auf Continuous-Integration auf, d. h. der Code kann bei Änderungen weitestgehend automatisiert gebaut werden. Gegebenenfalls werden hierbei dann auch Unit Tests ausgeführt.

Eines der Prinzipien des Agilen Manifestos (3. Prinzip nach https://agilemanifesto.org/principles.html) ist, funktionierende Software regelmäßig und in kurzen Intervallen auszuliefern. Integriertes und automatisiertes Testing hilft hierbei enorm. Andernfalls leidet die Agilität, und Kunden halten das Produkt erst später in den Händen, wenn langwierige manuelle Prozesse, wie manuelles Testen oder Pen-Tests, zwischen einem Code-Checking und einem Release stehen.

Bei der Einführung hilft es, auf Security Champions zu setzen, die das Fuzz-Testing für das restliche Team einsetzen und betreuen. Dies ist analog zu dem 5. Prinzip: “Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“

JAXenter: Vielen Dank für dieses Interview!

Sergej Dechand ist CEO und Co-Founder von Code Intelligence. Zuvor arbeitete er als Projektleiter für das Industrial-Data-Space-Projekt am Fraunhofer-Institut FKIE. Er hat einschlägige Erfahrungen als externer Softwareentwickler und IT-Berater in der Nutzfahrzeugentwicklung der Volkswagen AG gesammelt. Neben seinen Aufgaben bei Code Intelligence ist er aktiv an der Forschung im Bereich der Usable Security an der Rheinischen Friedrich-Wilhelms-Universität Bonn eingebunden, wo er auch als Dozent tätig ist.