Kann man sich auf Software verlassen, die seit 25 Jahren kontinuierlich weiterentwickelt wird  und die bei Millionen von Unternehmen im Einsatz ist? Die Antwort lautet: lieber nicht! Zumindest nicht, wenn es sich um Microsoft Exchange Server handelt. Gravierende Sicherheitslücken in den Versionen 2010 bis 2019 führten im Januar und Februar 2021 dazu, dass Hacker Hunderttausende von Exchange-Servern übernehmen konnten.

Das nach einer vermutlich regierungsnahen chinesischen Hackergruppe namens Hafnium benannte Debakel ist nur die Spitze des Eisbergs. Die CVE-Liste (Common Vulnerabilities and Exposures), eine Sammlung öffentlich bekannter Schwachstellen, umfasst mehr als 200.000 Einträge. Allein dieses Jahr kamen bis Mitte April über 8000 neue hinzu. Die auf der Plattform Hacker One organisierten Pentester und Cybersecurity-Spezialisten finden im Durchschnitt alle 2,5 Minuten eine Sicherheitslücke. Die Gesamtmenge aller dort dokumentierten Lücken beläuft sich auf mehr als 565.000. Diese Zahlen dürften eigentlich niemanden überraschen. Laut der von Veracode, einem Spezialisten für Applikationssicherheit, herausgegebenen Studie „State of Software Security“ weisen 76 Prozent aller Anwendungen mindestens eine Sicherheitslücke auf. Rund die Hälfte der Schwachstellen ist sechs Monate nach ihrer Entdeckung noch nicht behoben.

Jürgen Bernert, Geschäftsführer von Avision, Spezialist für Software-Modernisierung, glaubt, dass diese Zahlen sogar noch untertrieben sind: „Ich gehe davon aus, dass sich in 100 Prozent der Software Sicherheitslücken finden lassen.“ Mit Testlösungen wie Vega Vulnerability Scanner, HP Fortify und anderen ließen sich viele Schwachstellen zwar aufdecken, das allein reiche aber nicht aus. „Wenn Entwickler keinen Wert auf Sicherheit legen, nutzt das beste Testen nichts.“

Hinzu kommt laut Klaus Lambertz, Gründer und Geschäftsführer der Verifysoft Technology GmbH, dass außerhalb sicherheitskritischer Bereiche die Überprüfung von Software auf Bugs noch immer eher stiefmütterlich behandelt wird. „Bei den funktionalen Tests mag das Produkt dann funktionieren“, erklärt Lambertz. „Ändern sich aber die Umstände – etwa durch eine andere Nutzung oder Erweiterung der Software, können Fehler auftreten, die bei den funktionalen Tests nicht aufgedeckt worden sind.“

Eine Ursache für die gravierenden Sicherheitsprobleme liegt im zunehmenden Tempo bei der Software-Entwicklung: „Die größte Herausforderung ist es, mit den mittlerweile extrem schnellen Zyklen bei der Markteinführung von Software Schritt zu halten und dabei den gestiegenen Qualitätsanforderungen gerecht zu werden“, erklärt Ramiro Millan, Director Product Management, Developer Tools bei Progress. Dafür müssten Unternehmen ihre Teststrategie agiler und schlanker gestalten, meint Roman Zednik, VP Presales Solution Architects bei Tricentis: „Ohne den Einsatz von Testautomatisierung ist dies heutzutage nicht mehr möglich. Manuelles Testen muss auf ein Minimum reduziert werden.“ Laut Nick Mears, Functional Testing Product Marketing Manager bei Micro Focus, beschleunigt Automatisierung das Testen deutlich: „Durch den Wechsel von manuellen zu automatisierten Tests konnten einige unserer Kunden die Testzeit von drei bis vier Arbeitstagen auf nur noch eine Nacht reduzieren.“

Avision-Geschäftsführer Bernert warnt jedoch vor übertriebenen Hoffnungen in die Automation: „Man muss den Kunden sagen, dass eine Testautomatisierung nicht billiger ist als manuelles Testen.“ Auch der Pflegeaufwand für eine automatisierte Testumgebung sei nicht zu unterschätzen: „Ich habe viele gute Test-Frameworks veralten sehen.“ Vor allem die traditionelle skriptbasierte Testautomatisierung erfordert ständiges Nachjustieren. Ändern sich Abläufe oder Abhängigkeiten, müssen die Skripte jedes Mal angepasst werden – ein mühsamer Prozess, der selbst für Fehler anfällig ist. Nick Mears’ Kollege Don Jackson, Chief Technologist, Application Delivery Management bei Micro Focus, empfiehlt Unternehmen deshalb, auf eine robuste Automatisierung zu achten: „Um robust zu sein muss die Automatisierung folgende Charakteristika erfüllen: Sie muss belastbar sein und darf nicht abhängig von der Fertigstellung des Codes sein. Des Weiteren sollte sie in die vorhandene Pipeline integrierbar sein, angemessen datenorientiert und vollständig auf die Geschäftslogik, einschließlich der Geschäftsprozesse, abgestimmt sein.“

Schnelleres Testen lässt sich nach Ansicht von Roman Zednik aber auch dadurch erreichen, dass man weniger testet: „Im Durchschnitt bieten 67 Prozent der großteils manuell durchgeführten funktionalen Tests keinen Mehrwert.“ Der Tricentis-Manager empfiehlt statt flächendeckender Tests einen risikobasierten Ansatz: „Unternehmen können den Großteil ihrer Risiken mit nur wenigen Tests abdecken. 20 Prozent des Aufwands reichen bereits aus, um 80 Prozent der Geschäftsrisiken abzudecken.“ Schnelle Risikobewertungen und strukturierte Methoden zum Test-Case-Design helfen dabei, zu bestimmen, welche Tests das sind. „Automatisiert man diese, erhöht sich die Release-Frequenz deutlich.“ Zednik plädiert für eine „neue Währung“ im Software-Testing: „Wir müssen umsteigen und anstatt der Anzahl der Testfälle die erzielte Risikoabdeckung als neue Messgröße einführen.“

Ein weiterer Ansatz, der Software-Qualität bei kürzeren Release-Zyklen garantieren soll, ist „Shift Left“: Das Testen soll früher in die Entwicklungs-Pipeline integriert werden und nicht erst als großer Block am Ende einer Release-Phase stehen. „Das Shift-Left-Testing hilft, Probleme anzugehen, bevor sie auftreten“, sagt Ramiro Millan von Progress. „Idealerweise wird der Code bereits vom Beginn der Entwicklung an regelmäßig statisch untersucht“, ergänzt Klaus Lambertz. Es sei erst dann sinnvoll, den Code durch Code-Reviews, Unit-Tests oder Integrationstests zu prüfen, wenn die statische Code-Analyse keine Fehler mehr anzeigt, so der Verifysoft-Geschäftsführer weiter. Statische Code-Analyse-Tools überprüfen den Code auf Syntax, Semantik, Kontrollfluss- und Datenflussanomalien, Nebenläufigkeitsprobleme sowie die Einhaltung von Codierrichtlinien und -standards. „Werkzeuge für die statische Analyse decken ohne Schreiben von Testfällen eine Vielzahl von Bugs auf und identifizieren sicherheitsgefährdende Schwachstellen“, sagt Lambertz. Die erfassten Code-Metriken geben außerdem Hinweise auf Qualitätsmerkmale wie Wartbarkeit, Erweiterbarkeit, Analysierbarkeit und Testbarkeit der Software, so Lambertz weiter. „Um die Software-Qualität langfristig zu sichern und die Release-Frequenz erhöhen zu können, macht die Beachtung von Metriken durchaus Sinn.“

Sergej Dechand, Gründer und Geschäftsführer der Firma Code Intelligence, die eine Plattform für automatisierte Software-Security-Tests anbietet, warnt allerdings davor, statische Code-Analysen überzubewerten: „Das reine Scannen des Codes führt dazu, dass viele Fehler übersehen und jede Menge Fehlalarme generiert werden.“ Sobald die Software lauffähig ist, sollten die statischen Analysen durch dynamische ergänzt werden. „Bei sicherheitskritischer Software – also Software, bei der im Problemfall Menschen zu Schaden kommen können – sind dynamische Testverfahren und der Nachweis der Testabdeckung aus gutem Grund verpflichtend“, betont Klaus Lambertz.

Programmierer und Tester stehen vor der Herausforderung, dass sich das ganze Spektrum möglicher Nutzeraktionen nur schwer vorhersehen lässt. Unerwartete Eingaben können zu Sicherheitslücken und Qualitätsproblemen führen. „Bei funktionalen Tests fokussiert man sich auf die er­warteten Anforderungen“, erklärt Code-Intelligence-Chef Dechand. „Es gibt aber so viele andere Ereignisse, die passieren können, an die ein Entwickler vielleicht nicht denkt.“ Jürgen Bernert von Avision empfiehlt daher, eine zweite Qualitätsstufe einzubauen und einen unabhängigen Tester mit der Überprüfung zu betrauen. „Wir haben eigens Kollegen im Team, die genau für diese Aufgabe zuständig sind.“

Eine weitere Möglichkeit, auch unerwartete Eingaben zu finden, die Fehler oder Sicherheitsprobleme nach sich ziehen, ist das sogenannte Fuzz-Testing. Seit den 1980er- Jahren nutzt man dieses Verfahren, um nach der Schrotschussmethode Software so lange mit zufälligen Eingaben zu konfrontieren, bis diese abstürzt. Code Intelligence hat diesen Ansatz verfeinert und weiterentwickelt. Die Lösung des Anbieters analysiert Reaktionen der Software auf Eingaben und passt die Testfälle auf Basis der Ana­lyseergebnisse so an, dass die Code-Abdeckung maxi­miert wird. „Wir überlassen das Testen nicht dem Zufall, sondern versuchen, möglichst alle Zustände zu erreichen, die auftreten können“, erklärt Dechand. Je breiter die Abdeckung, desto mehr potenzielle Sicherheitslücken und Fehler würden aufgedeckt. „So lässt sich der Grad der IT-Sicherheit in Software deutlich erhöhen“, verspricht der CEO von Code Intelligence.

Dechand vergleicht seine Lösung gerne mit Penetra­tionstests, bei denen Security-Experten versuchen, Software zu hacken und in Systeme einzudringen. Da sie jedoch nur ein begrenztes Zeitbudget zur Verfügung haben, finden sie nicht notwendigerweise alle kritischen Sicherheitslücken. „Ein Pentester hat vielleicht fünf Tage Zeit für seine Prüfung – was passiert aber, wenn ein Krimineller zehn Tage in seinen Angriff investiert?“, fragt Dechand. Die Code-Intelligence-Lösung skaliere wesentlich besser als der Einsatz von Personal und könne so die Risiken weiter reduzieren: „Wir finden auch nach abgeschlossenen Pentests fast immer noch Fehler.“ Fuzz-Testing entlaste außerdem die menschlichen Experten: „Statt sich mit trivialen Code-Fehlern zu beschäftigen, können sich Pentester auf Fehlerklassen konzentrieren, bei denen wir nicht so gut sind, etwa Fehler in der Kryptografieanwendung oder bei Pfaden, die sich nicht automatisiert erreichen lassen.“

Die Vorteile des Fuzz-Testings werden laut Dechand auch zunehmend von Behörden und Standardisierungsgremien erkannt. „Im Sommer wird mit der ISO 21434 ,Road ve­hicles – Cybersecurity engineering‘ ein neuer Standard zur Cyber-Security im Automobilbereich veröffentlicht, in dem Fuzz-Testing als Ersatz für Pentesting genannt wird.“ Auch im medizinischen Bereich gebe es ähnliche Ansätze. „Ich denke, es ist nur eine Frage der Zeit, bis auch die Bafin und ähnliche regulatorische Instanzen das Fuzz-Testing zum Pflichtprogramm hinzufügen.“

Menschliche Tester stehen vor einer ganzen Reihe von Herausforderungen. Sie müssen die richtigen Testfälle finden und priorisieren, Muster in großen Datenmengen ausfindig machen, Fehlerquellen identifizieren und mögliche Pro­bleme vorhersagen. Künstliche Intelligenz kann dabei in allen Bereichen helfen. „KI wird das Software-Testen enorm unterstützen“, ist sich Ramiro Millan von Progress sicher. Künstliche Intelligenz sei in vielen Fällen schneller und genauer als menschliche Experten: „Es wird deshalb zu einer engen Zusammenarbeit und guten Partnerschaft zwischen Mensch und Maschine kommen, und das wird unweigerlich die Art und Weise fundamental verändern, wie wir Software-Tests durchführen.“

Machine Learning lässt sich beispielsweise bei der statischen Code-Analyse einsetzen, um Anomalien zu identifizieren, die bei der herkömmlichen Analyse unentdeckt blieben. „Diese Technik, die besonders nützlich ist, um Ano­malien in der API-Nutzung zu finden, kann insbesondere für beliebte Betriebssystemschnittstellen oder Open-Source-Bibliotheken eingesetzt werden“, sagt Verifysoft-Geschäftsführer Lambertz. „Die Erfahrung zeigt, dass ein erheblicher Anteil der über die KI gefundenen Anomalien echten Defekten entspricht.“

KI-basierte Testautomatisierung macht es laut Nick Mears von Micro Focus überflüssig, für jede zu testende Plattform eigene Skripte zu erstellen. Der Anbieter kombiniert beispielsweise Machine Learning, Natural Language Processing, Computer Vision und neuronale Netze, um unabhängig von Plattformen, Geräten oder Browsern testen zu können. „Grundsätzlich heißt das, dass die KI genauso testen würde wie ein Mensch, nämlich visuell, ohne sich auf den komplexen Skriptcode zu konzentrieren.“

Das österreichische Start-up Symflower setzt auf Künstliche Intelligenz, um die Erstellung der Unit-Tests zu automatisieren. Dem Anbieter zufolge lassen sich auf diese Weise Testfälle im Vergleich zum manuellen Schreiben um mehrere Größenordnungen schneller generieren. Symflower nutzt dazu „Symbolic Execution“, eine KI-Methode, bei der Gleichungssysteme statt konkreter Werte für die Testfälle eingesetzt werden. „Das erlaubt es uns, alle Ausführungsmöglichkeiten eines Programms zu betrachten und Fehlerquellen flächendeckend zu identifizieren“, erklärt Evelyn Haslinger, Managing Director/Operations bei der Symflower GmbH.

Derzeit kommen die Kunden hauptsächlich aus dem Banken- und Versicherungswesen sowie aus der Telekommunikation. „Wir unterstützen aktuell die Programmiersprachen Java und Go“, sagt Haslinger, „die typischerweise im Businesslogikbereich beziehungsweise bei Server-In­frastrukturanwendungen im Einsatz sind.“

Software-Testing ist essenziell, um die Qualität und Sicherheit von Applikationen zu optimieren. Ob man dabei einem eher risikobasierten Ansatz folgt, wie Roman Zednik von Tricentis empfiehlt, oder auf möglichst breites Testen durch Fuzzing-Methoden und KI setzt, hängt im Wesentlichen von der eigenen Risikobereitschaft ab, aber auch von den Folgen, die Software-Fehler nach sich ziehen können. Im Automobilsektor oder dem medizinischen Bereich wird man daher andere Maßstäbe anlegen als bei der Entwicklung einer Spiele-App.

Vor allem aber müssen Unternehmen die Vorstellung überwinden, Software-Testing sei in erster Linie ein Kostenfaktor und bremse die Entwicklung aus. „Software-Tests tragen – wenn sie richtig eingesetzt werden – nicht nur zur Qualitätssteigerung, sondern ganz erheblich auch zur Kostensenkung bei“, sagt Verifysoft-Geschäftsführer Klaus Lambertz.