Sicherheit und Zuverlässigkeit spielt eine zentrale Rolle in der Softwareentwicklung – für Entwickler:innen ebenso, wie für die Nutzer:innen. Berichte über Datenlecks und Sicherheitspannen sind mittlerweile fast an der Tagesordnung.
Tatsächlich handelt es sich hierbei nicht nur um eine reines Medienphänomen, denn die Anzahl der bekannten Sicherheitsschwachstellen in Softwaresystemen steigt jährlich konstant an. Die National Vulnerability Database (NVD), die de-facto Primärquelle für dokumentierte Softwareschwachstellen, verzeichnete im letzten Jahr über 28.000 neue Einträge. 2016 lag die Zahl noch bei etwa 6.000 neuen Einträgen – und dieses Jahr wird aller Wahrscheinlichkeit nach die 30.000 Marke überschritten.
Für Softwarehersteller geht dieser Trend mit der steigenden Gefahr einher, dass auch das eigene Produkt von Sicherheitsschwachstellen betroffen ist. Gerade im Rahmen gesetzlichen Vorgaben, wie der DSGVO und dem Cyber Resilience Act, birgt dies nicht unerhebliche rechtliche Risiken. Es ist entsprechend wenig verwunderlich, dass in der Softwareentwicklung eine Vielzahl von Maßnahmen ergriffen werden, um ein Bewusstsein für Sicherheitsrisiken zu schaffen und Schwachstellen möglichst früh im Entwicklungszyklus identifizieren und beseitigen zu können. Security Testing Tools spielen eine wichtige unterstützende Rolle bei der Erreichung dieses Ziels.
Dieser Artikel liefert eine Übersicht über die die relevantesten Kategorien von Tools in diesem Bereich, ihre Funktionsweise, sowie Stärken und Schwächen.
1. Security Testing Techniken im Überblick
Beim Testen von Software auf Sicherheitsrisiken kommen eine Vielzahl von Techniken zum Einsatz. Grob unterteilen lassen sich diese in Abhängigkeit vom erforderlichen Zugriffslevel auf das System und deren interne Struktur (inkl. Source-Code). Hier spricht man entweder von Black-Box (kein Zugriff), White-Box (kompletter Zugriff) oder Gray-Box (teilweiser Zugriff) Techniken. Für jede dieser Kategorien gibt es automatisierte und manuelle Ansätze.
Als manuelle Ansätze kommen vor Allem klassische Code Reviews sowie das Penetration Testing (auch Pentesting genannt) zum Einsatz. Bei manuellen Code Reviews, wird der Source Code der Anwendung von Entwicklern begutachtet und nach möglichen Fehlern und Schwachstellen abgesucht. Da solche Reviews ohnehin empfehlenswert für die Qualitätswahrung der Software sind, bietet es sich an hier ebenfalls verstärkt auf mögliche Sicherheitsrisiken zu achten. Im Gegensatz dazu wird beim Penetration Testing nicht zwangsweise ein Zugriff auf den Source Code der Anwendung benötigt. Bei dieser Technik geht es darum existierende Sicherheitslücken im System offenzulegen, indem man sich in die Position eines potenziellen Angreifers versetzt und mit passenden Tools und Methoden sicherheitsrelevante Angriffe durchführt. Dementsprechend ist hier lediglich ein lauffähiges System (möglichst nahe am Produktivsystem) eine zwingende Voraussetzung, auch wenn zusätzliches Wissen über den Aufbau und Code des Systems bei der Durchführung solcher Tests hilfreich sein kann.
Manuelle Security Testing Techniken haben sich in der Praxis als sehr effektiv erwiesen und ihre regelmäßige Anwendung ist essenziell, um ein sicheres Softwaresystem zu gewährleisten. Allerdings haben sie einige zentrale Nachteile:
- Der Erfolg beim manuellen Security Testing hängt stark von der Erfahrung und Expertise der jeweiligen Entwickler/Tester auf dem Gebiet ab. Häufig müssen entsprechende Kompetenzen im Team erst aufgebaut werden.
- Die Techniken können zeitaufwendig sein, weshalb sie oftmals nicht in angemessener Häufigkeit angewendet werden (können).
Hier kommen die automatisierten Security Testing Tools ins Spiel, denn mit ihnen lässt sich diesen Aspektenentgegenwirken. Am häufigsten werden dabei Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST) Tools verwendet. SAST-Tools suchen den Anwendungscode statisch nach Schwachstellen, Fehlern oder Code Smells (verdächtigen Mustern) ab, während DAST-Tools Angriffe simulieren, um die laufende zu testende Anwendung nach ausnutzbaren Schwachstellen abzusuchen. In einem späteren Abschnitt betrachten wir SAST- und DAST-Tools, sowie einige verwandte Tool-Kategorien, etwas genauer.
2. Wieso sind automatisierte Security Testing Tools wichtig?
Security Testing Tools lassen sich meist problemlos in die CI/CD-Pipeline (Continuous Integration/Continuous Deployment) des Projekts einbinden. Nach einem initialen Aufwand für die Integration in das Projekt ist der Zeitaufwand somit stark reduziert und alle Entwickler:innen können von regelmäßigen Sicherheitstests profitieren – auch jene, die noch nicht so viel Erfahrung in diesem Bereich haben.
Ein weiterer entscheidender Punkt für die Relevanz solcher Tools ist die Schnelllebigkeit der Security-Welt. Neue Angriffstechniken auf Softwaresysteme und Schwachstellen in populären Bibliotheken werden praktisch täglich veröffentlicht. Der aktuelle Sicherheitszustand eines Systems ist somit nur eine Momentaufnahme und Software die heute als sicher gilt kann schon morgen anfällig für neuartige Angriffe sein. Auch bereits betrachteter Anwendungscode sollte deshalb regelmäßig erneut auf aktuelle Sicherheitsrisiken getestet werden.
Ein gutes Beispiel dafür ist die Log4Shell Schwachstelle, die durch eine populäre Java-Bibliothek verursacht wurde und Ende 2021 weltweit für Panik bei vielen Entwicklungsteams sorgte. Bei der Menge an Bibliotheken die moderne Softwareprojekte einbinden ist ein manuelles Absuchen auf Schwachstellen in der Praxis kaum möglich, hier ist die Unterstützung durch Tools zwingend erforderlich.
Gleiches gilt für neuartige Angriffstechniken, die eventuell noch nicht dem gesamten Entwicklerteam bekannt sind. Security Tools weisen auf solche Risiken hin und helfen somit auch dabei Wissen aus diesem Bereich in das Team zu streuen und Entwickler:innen gegenüber neuen Gefahren zu sensibilisieren.
Im Übrigen bieten viele Tools auch Funktionen zur Lizenzprüfungen von Abhängigkeiten im Projekt und helfen so Compliance-Risiken zu minimieren.
3. SAST- und SCA-Tools
Die wahrscheinlich am häufigsten eingesetzten Security Tools im Entwicklungsbereich sind die zuvor erwähnten SAST-Tools. Sie analysieren den Anwendungscode (entweder auf Source Code oder Bytecode Ebene) und suchen so nach sicherheitsrelevanten Schwachstellen. Der Code wird hierbei je nach Tool in verschiedene Repräsentationen und Modelle überführt, um bestimmte auffällige Muster besser zu erkennen. Durch den Einsatz so genannter Taint–Analysen eignen sich moderne Tools meist gut, um bekannte Schwachstellen zu identifizieren, die durch bösartige Nutzereingaben ausgenutzt werden können (wie etwa SQL-Injections in Web-Anwendungen). Einige Tools neigen allerdings dazu viele Fehlalarme (False-Positives) auszugeben.
Wie gut sich solche Tools für das eigene Projekt eignen ist stark von den verwendeten Technologien, Programmiersprachen und Frameworks abhängig. Glücklicherweise gibt es eine Vielzahl an kommerziellen und kostenfreien Lösungen in diesem Bereich, so dass das Team verschiedenste Tools ausprobieren kann. Als Orientierungshilfe bietet das Open Worldwide Application Security Project (OWASP) eine Übersicht mit Tipps für die Auswahl solcher Tools an. Für eine erste Einschätzung über die Effektivität der Tools im Java Umfeld lohnt sich zudem ein Blick auf das OWASP Benchmark Project.
Neben der reinen Analyse des eigenen Codes gibt es mit den Software Composition Analysis (SCA) Tools auch solche, die sich auf das Erkennen von Schwachstellen in Projektabhängigkeiten fokussieren. Sie gleichen beispielweise eingebunde Bibliotheken mit NVD-Einträgen ab, um Sicherheitsrisiken zu identifizieren und weisen zum Teil sogar auf potenzielle Lizenzprobleme hin.
4. DAST- und Fuzzing-Tools
Neben der statischen Auswertung des Anwendungscodes besteht auch die Möglichkeit einer dynamischen Analyse mittels DAST-Tools. Hierbei wird die laufende Anwendung mit teils zufallsgenerierten Eingaben auf Sicherheitsrisiken getestet, Zugriff auf den Anwendungscode ist meist nicht nötig. Schwachstellen, die auf dynamisch generiertem Output basieren (wie etwa Cross-Site Scripting/XSS) oder Konfigurationsprobleme, die sich erst zur Laufzeit bemerkbar machen (z.B. bei der Authentifizierung) lassen sich mit diesen Tools oftmals besser identifizieren als mit statischen Methoden. Zudem sind False-Positives bei solchen Tools eher selten, da sich ein auftretender Fehler in einer laufenden Anwendung meist auch auf eine produktionsnahe Umgebung übertragen lässt.
Die Voraussetzung einer laufenden Anwendung stellt gleichzeitig einen der größten Nachteile dieser Tools dar, denn es bedeutet, dass sie erst deutlich später im Entwicklungszyklus eingesetzt werden können. Auch ist ein zusätzlicher Aufwand für die Konfiguration der Testumgebung einzuplanen und die Tools sind meist nicht so performant wie statische Analysen.
Auch für DAST-Tools gibt es zahlreiche Anbieter und Variationen. Häufig werden in diesem Zusammenhang so genannte Fuzzing-Tools verwendet, die auch außerhalb des Security Kontexts genutzt werden können, um das Verhalten der Anwendung auf unerwartete Eingaben zu prüfen. Eine Übersicht mit zahlreichen DAST-Tools wird auf der OWASP-Website bereitgestellt.
5. Fazit
Security Testing Tools sind kein Ersatz für regelmäßige Security-Fortbildungen oder das manuelle Testen der eigenen Anwendung auf potenzielle Sicherheitsrisiken. Sie spielen jedoch eine essenzielle Rolle bei der Entwicklung sicherer Software, da sie Aufgaben übernehmen, die im Entwicklungsalltag kaum in angemessenem Umfang von Hand durchführbar sind. Einmal in den CI/CD-Pipeline eingebunden, profitiert das gesamte Team von automatischen Tests auf potenzielle Security- und Compliance-Risken und wird dies bezüglich sensibilisiert.
Durch die Vielzahl an angebotenen SAST-, SCA- und DAST-Lösungen und hilfreichen Ressourcen im Netz, lässt sich für nahezu jedes Projekt eine brauchbare Lösung finden – teils sogar komplett kostenlos. Für den Einstieg empfiehlt sich ein Blick auf die OWASP Auflistungen gängiger SAST- und DAST-Tools.
Sichern Sie Ihre IT!
Lassen Sie potenzielle Sicherheitslücken nicht unentdeckt. Unser IT-Security-Team hilft Ihnen, Ihre Systeme optimal abzusichern.
Autor
Fabian Ochmann
Fabian ist als Softwareentwickler bei der BREDEX tätig. Neben der Java- und Web-Entwicklung beschäftigt er sich mit Themen rund um das Gebiet Application Security.
Ihr Ansprechpartner
Gerne erzählen wir Ihnen mehr zu diesem Thema.
Jobs
