Fuzzying vs. statische Codeanalyse Ist modernes Fuzzing die Zukunft von DevSecOps?

Hinter dem Begriff DevSecOps steckt die Idee, dass jedes Teammitglied eines Softwareprojekts für die Entwicklung, den Betrieb und die Sicherheit des gesamten Softwareprojekts verantwortlich ist. Aus der Sicherheitsperspektive steht die Verantwortungsverteilung für die Sicherheit der Systeme im Mittelpunkt. Dabei versprechen u.A. statische Codeanalysen, Testgeneratoren und zahlreiche Machine Learning-Ansätze einen erhöhten Grad an Automatisierung.

Im Application Security Testing kommt vor allem die statische Codeanalyse (Static Application Security Testing, SAST) zum Einsatz. Hierbei wird der Quellcode gescannt, ohne diesen tatsächlich auszuführen. Der Schwerpunkt der Suche wird auf verdächtige Muster im Kontroll-/Datenfluss gelegt, welche mithilfe von Heuristiken und festen Regeln verfolgt werden. Jene Codestellen, die mit verdächtigen Mustern übereinstimmen und auf potenzielle Schwachstellen hinweisen könnten, werden dem Entwickler als verdächtig oder als Fehler präsentiert. Da SAST-Tools den Code nicht ausführen, sind diese leicht zu integrieren und werden deshalb in nahezu jedem Softwareprojekt eingesetzt. Zudem kann statische Codeanalyse in nahezu jeder Phase des Entwicklungsprozesses eingesetztvv werden. Im besten Fall wird diese bereits in der Entwicklungsumgebung ausgeführt, um bereits in noch nicht fertiggestelltem Code Schwachstellen aufzudecken, noch bevor dieser ins Repository eingecheckt wird.

Einer der größten Nachteile der statischen Analyse ist, dass diese zahlreiche False Positives und False Negatives produziert. Es werden also Warnungen herausgegeben, obwohl keine wirklichen Schwachstellen im Code enthalten sind. Gleichzeitig werden zahlreiche Schwachstellen übersehen, die dann bei der Ausführung (nicht) auftreten. In der Praxis können bei großen Projekten leicht viele Tausend Warnungen auftreten (wovon nur ein geringer Prozentsatz tatsächliche Fehler sind), die im schlimmsten Fall manuell überprüft werden müssen, bevor eine Software releast werden kann. Dies bringt wiederum enorme Benutzbarkeitsprobleme mit sich, welche darin münden, dass Ergebnisse der statischen Analyse häufig von Entwicklern weniger ernst genommen und damit sogar das Thema Sicherheit damit vernachlässigt wird. Eine übliche Lösungsstrategie besteht darin, die Analyse der Warnungen an externe Consultants auszulagern. Ein solches Vorgehen widerspricht allerdings der grundlegenden Philosophie (“Multi-funktionales Team”) von DevSecOps, da so die Verantwortung für die Sicherheit an Dritte u.U. mit fehlendem Domänenwissen abgegeben wird.

Viele Software-Fehler könnten bereits mit einer statischen Analyse vermieden werden. Allerdings wird die Effektivität und Effizienz dieses Verfahrens durch Benutzbarkeitseinschränkungen erschwert, wie durch das häufige Vorkommen von False Positives und Negatives. Bei der Ausführung des Codes kommt es dann in der Praxis zu Abstürzen und Sicherheitsproblemen, die in der Analyse nicht gefunden werden konnten.

Es stellt sich daher die Frage, ob der alleinige Einsatz der statische Codeanalyse in der CI/CD ausreicht, um die Sicherheit eines Produkts und die Effektivität der überprüfenden DevSecOps Teams zu gewährleisten? Viele Organisationen entscheiden sich für Statische Codeanalyse aufgrund der einfachen Integration und damit einhergehenden Eindrucks, Sicherheits- und Qualitätsmaßnahmen ergriffen zu haben. Um Projekte kontinuierlich und qualitativ hochwertig zu sichern, sind allerdings weitere Testansätze in der Pipeline erforderlich.

Fuzzing - Dynamische Codeanalyse für DevSecOps

Die dynamische Codeanalyse, die im Gegensatz zur statischen Codeanalyse die Applikation während ihrer Laufzeit testet und sie mit Eingabewerten ausgeführt, steckt im DevSecOps-Bereich noch in den Kinderschuhen. Allerdings setzt sich das moderne Fuzzing, welches auch Feedback-Based, Coverage-Based sowie instrumentiertes Fuzzing genannt wird, bei Sicherheitsforschern, Software Testing-Experten und Technologieführern wie Google zum effektivsten Werkzeug für automatisiertes Testing durch.

Bei Fuzzing wird die zu testende Software mit einer Reihe von Eingabewerten ausgeführt, die im Folgeprozess gezielt mutiert werden. Die Mutation basiert dabei auf den Rückmeldungen über den auf dem Ausführungspfad abgedeckten Code, aufgetretenen Instruktionen, sowie der unterschiedlichen Zustände, die das Testwerkzeug während der Ausführung der Eingaben erhält. Die Entscheidungen der Fuzzing Engines können so in den Folgeläufen iterativ zu sinnvolleren Mutationen führen. Im Gegensatz zum traditionellen bzw. Black-Box-Fuzzing erkundet das moderne Fuzzing den Programmzustand effektiv und entdeckt Fehler, die tief im Code verborgen sind (z.B. bei Randfällen, die im manuellen Testing vergessen wurden).

Ein Blick zu den Technologieführern, wie Google und Microsoft, zeigt, dass dort moderne Fuzzing-Techniken bereits nahezu flächendeckend verwendet werden, um den eigenen Code auf Sicherheit und Zuverlässigkeit zu testen. So wurden beispielsweise in Google Chrome und mehreren Open-Source-Projekten über 27.000 Fehler gefunden. Google gab dazu 2019 an, mittlerweile 80 Prozent ihrer Bugs mittels Fuzzing zu finden. Dabei ist Fuzzing bereits automatisiert in ihren CI/CD Pipelines integriert und zeigt die Wirksamkeit von Fuzzing in der Aufdeckung von Bugs und Schwachstellen.

Genau wie Unit- und System-Tests, hat Fuzzing damit das Potenzial die Art und Weise, wie Software weltweit getestet wird, zu verändern. Entwickler, brauchen weniger Kapazitäten in Unit-Tests eine Bandbreite an möglichen Randfällen abzudecken. Stattdessen können DevSecOps-Teams Fuzz-Tests einrichten, die automatisch viele unvoreingenommene Testfälle erzeugen. Fuzzing kann die Entwicklungskosten durch die Verbesserung der Effektivität und Effizienz der Entwickler massiv zu senken. Dennoch ist es sinnvoll, Fuzzing mit statischer Analyse zu verbinden, um z.B. das Auffinden von externen Schnittstellen, die automatisiert gefuzzt werden können, zu erleichtern und die Maximierung der Code-Abdeckung während der Testläufe zu ermöglichen.

Verschenktes Potenzial nutzen

Bis auf die Technologieführer setzen vor allem in Europa nur wenige Unternehmen auf die vielversprechenden Fuzzing-Technologien. Stattdessen findet das (Pen)Testing nach wie vor hauptsächlich manuell bei der Abnahme mit komplexen PSA-Prozessen (Privacy and Security Assessment) statt. Die führt vor allem zu zwei Konsequenzen:

• 1. Der Einsatz kostspieliger Pentester-Ressourcen führt zu unnötig hohen und vermeidbaren Kosten. Pentester sind zwar für die finalen Abnahmetests unabdingbar, ihre Arbeitskraft sollte allerdings nicht für das Auseinandersetzen mit Fehlern verschwendet werden, die präventiv mit Fuzzing automatisiert gefunden werden könnten.

• 2. Bugs und Sicherheitslücken werden nicht entdeckt und gelangen letztendlich sogar in Produktion. Das liegt daran, dass Applikationssicherheit ohne Fuzzing immer nur so gut ist, wie der jeweilige Pentester selbst. Fuzzing findet erwiesenermaßen Bugs und Sicherheitslücken in Software, die sogar nach erfolgreichen Reviews durch gut ausgebildete Sicherheitsexperten, erfolgreichen statischen Codeanalyse und Pentests durch namhafte Bughunter als sicher eingestuft wurden. Dies wird in Projekten wie den Linux-Kernel und Google Chrome besonders ersichtlich, da diese eine gewisse Größe und eine besonders hohe Komplexität aufweisen.

Warum wird dann Fuzzing, bis auf die führenden Unternehmen in DevSecOps noch kaum eingesetzt? Open Source Fuzz Testing Tools, wie z.B. american fuzzy loop (AFL) oder libFuzzer sind in den meisten Teams noch völlig unbekannt, die Benutzbarkeit wird als noch zu schlecht bewertet, und vor allem gibt es Kritik beim Integrationsaufwand. An dieser Stelle reagiert bereits der Markt, immer mehr kommerzielle Anbieter bieten bereits für unterschiedliche Domänen moderne Fuzzing in DevSecOps an. Ob es tatsächlich funktionieren wird, Fuzzing effektiv in DevSecOps einzubinden, wird entscheidend davon abhängen, ob man diese Integrations- und Benutzbarkeits-Schwierigkeiten in den nächsten Jahren in Griff bekommt. Denn nur wenn dies möglich ist, lässt sich am Ende “Sec” effektiv und zuverlässig mit “DevOps” vereinen.

Betrachtet man die Möglichkeiten und Chancen, die Fuzzing bietet, dürfte eigentlich keine Software mehr ausgeliefert werden, die Fehler enthält, welche mittels Fuzzing hätten verhindert werden können. Auch Angreifer nutzen alle Möglichkeiten, die sich ihnen bieten. Sie können ebenfalls Fuzzing-Techniken verwenden, um Fehler in der Software zu finden und diese auszunutzen. Insbesondere können sie es dann ausnutzen, wenn die ausführbare Software in Besitz ist. Als Softwarehersteller hat man allerdings durch den Besitz der Quellcodes und die damit verbundene Instrumentierung einen enormen Heimvorteil gegenüber dem Angreifer und sollte diese auch nutzen.

Über den Autor: Sergej Dechand ist CEO und Co-Founder von Code Intelligence. Das Unternehmen legt Wert darauf, komplexe Softwaretesting-Methoden für den Entwickler einfacher zu gestalten. Sergej hat einschlägige Erfahrungen als externer Softwareentwickler und IT-Berater für unterschiedliche DAX-Unternehmen und als Projektleiter am Fraunhofer FKIE gesammelt. Neben seinen Aufgaben bei Code Intelligence ist er aktiv an der Forschung im Bereich der Usable Security der Universität Bonn eingebunden, wo er auch als Dozent tätig ist.

(ID:46972340)