Static Application Security Testing (SAST) – Statische Analyse nicht erst am Ende beginnen

Statische Analyse steht in dem Ruf, schwierig in Handhabung und Umsetzung zu sein. Es gibt aber einige gute Strategien für Security-Tests, die sich bereits im praktischen Einsatz bewährt haben. Ein Schlüssel: Nicht erst am Ende mit den Tests beginnen.

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Microelectronics Consulting & Training GmbH

RTI Real-Time Innovations

In Zeiten von IoT müssen alle Anwendungen Safe&Secure sein, also größtmögliche Sicherheit erfüllen. Es ist easy, das Security-Thema erst ganz am Schluss anzugehen, indem man in einer späten Phase des Entwicklungszyklus externe, das gesamte System abdeckende Tests wie etwa Penetration Tests durchführt (ich würde dies als DevTestOpsSec bezeichnen). Solche Tests eignen sich prima für den Nachweis, dass die Applikation bzw. das System keine der in OWASP aufgezählten Sicherheitslücken aufweist.

Aber dieses Blackbox-Testen ist nicht die wirksamste Art, um Code zu erstellen, der einen höheren Anspruch an die Sicherheit erfüllt. Man sollte sich nicht auf das Blackbox-Testen zum Absichern seiner Software oder zum Aufdecken von Bugs verlassen, und es auch nicht zum Nachweis einsetzen, dass die Software geschützt ist. Wenn also ein Penetrationstest eine Schwachstelle aufdeckt, muss man den Grund dafür herausfinden und die dahintersteckende Ursache aufspüren.

An dieser Stelle wechselt man vom ‚Test-Security-In‘-Prinzip, also durch Testen für Security zu sorgen, in eine ‚Security-by-Design‘-Mentalität. Hierfür gibt es die SAST-Tools (Static Application Security Testing) wie etwa die statische Codeanalyse mit Unterstützung für OWASP.

Das Elegante an der statischen Analyse ist, dass die Applikation oder das System nicht komplett fertiggestellt sein muss. So kann man bereits in einer sehr viel früheren Phase mit dem Aufspüren von Security-Problemen beginnen (zeitliche Vorverlegung der Security-Tests). Nimmt man sich des Security-Themas erst spät oder gegen Ende der Entwicklung an (DevOpsSec), so kann man mit der statischen Analyse die Security viel früher angehen, noch bevor das Testen überhaupt beginnt, nämlich schon während der Code geschrieben wird (DevSecOps).

Einsatz von SAST – schwierig oder nicht?

Leider genießt die statische Analyse den zweifelhaften Ruf, „noisy“ zu sein und beispielsweise Hunderte oder gar Tausende von Regelverletzungen zu melden, wenn man gerade dachte, man sei bereit zum Release. Für den Umgang damit gibt es zum Glück einige sehr gute Strategien, damit umzugehen. Beachten sollte man:

• Sparen Sie die Security-Tests nicht bis zum Ende auf, sondern beginnen Sie mit der statischen Analyse, sobald Sie mit dem Programmieren beginnen. Wenn Sie stattdessen abwarten und die statische Analyse nur im Rahmen Ihrer CI/CD-Pipeline durchführen, summieren sich die Ergebnisse auf und überfordern das Entwicklungs-Team. Führen Sie sie am Desktop durch, um Probleme zu finden, und arbeiten Sie sie in der CI/CD-Pipeline ab, um auf einfache Weise zu verifizieren, dass der Code einwandfrei erstellt wurde.

• Nehmen Sie eine Feinabstimmung Ihrer Konfiguration vor. Einige statische Analyse-Checker werden im Kontext des Codes vielleicht gar nicht benötigt. Prüfen Sie Ihre Applikation und stellen Sie fest, welche Security-Risiken für Sie relevant sind – und befassen Sie sich nur mit diesen. Halten Sie niemals Ausschau nach Problemen, deren Beseitigung Sie ohnehin nicht vorhaben.

• Es kommt auf das Alter des Codes an. Der mittlerweile uralte Grundsatz „If it ain’t broken, don’t fix it” (Nichts reparieren, was nicht kaputt ist) sollte auch auf Bestandscode angewandt werden. Prüfen Sie älteren Code nur mit den wichtigsten Security-Scannern. Kleinere Probleme bedeuten nur Zeitverschwendung, und die damit einhergehenden Änderungen bergen ihrerseits Risiken. Prüfen Sie niemals Code, den Sie nicht zu reparieren beabsichtigen.

• Es geht um die Risiken. SAST-Tools decken reale als auch potenzielle Schwachstellen auf, aber nicht mit allen Resultaten ist das gleiche potenzielle Risiko verbunden. OWASP hat hier geholfen, indem für jeden Eintrag in der Top-10-Liste das Risiko im Hinblick darauf definiert wurde, wie einfach sich eine Schwachstelle ausnutzen lässt, wie leicht die Schwachstelle zu entdecken ist und welche tatsächlichen Folgewirkungen ein Exploit haben kann.

Absichern der Anwendung: Vermeidung ist wirkungsvoll

Will man seine Anwendung wirklich abhärten sollte man berücksichtigen,das es wesentlich einfacher ist, auf Sicherheit zu testen, als Sicherheit mit einzubauen. Zum Glück sind statische Analyse-Checker in den verschiedensten Varianten verfügbar. Einige halten Ausschau nach typischen Problemen wie „tainted data“ und versuchen herauszufinden, ob es in der Applikation einen Ablauf gibt, bei dem das Problem vorkommen kann. Dies sind die gängigsten Checker vieler SAST-Tools. Der größere Nutzen von statischen Codeanalysen liegt jedoch in Checkern, die zwei ganz besondere Dinge durchsetzen:

Zum einen ein Muster, mit dem es in der Vergangenheit häufig Probleme gab. Dies mag nicht so interessant aussehen wie ein bestimmter Stack-Trace, der zu einem Exploit hinführt. Es kann jedoch wesentlich gründlicher sein, einfach alles zu reparieren, das schwächer ist als gewünscht, anstatt sich bei der Reparatur auf solche Probleme zu beschränken, für die es einen erwiesenen Angriffsvektor gibt.

Und zum anderen Anforderungen bestimmter Codierungsweisen, um eine einwandfreie Funktion zu gewährleisten. Automobil- und Luftfahrt-Normen wie MISRA oder JSF bedienen sich dieser Technik, um die funktionale Sicherheit zu gewährleisten. Die gleiche Technik, nicht nur schlechten Code zu melden, sondern guten Code zu verlangen, ist hilfreich beim Erstellen sichererer Applikationen.

Paradoxerweise wird diese Vorgehensweise seit Jahrzehnten in sicherheitskritischen Branchen im Zusammenhang mit Hard- und Software angewandt. Irgendwie denkt man bei Cybersecurity aber, dass sich eine Applikation durch Testen sicher machen lässt, anstatt sich auf das Erstellen von sicherem Code zu konzentrieren. Es ist also angeraten, sämtliche Fähigkeiten der proaktiven statischen Analyse und der Früherkennungs-Checker zu nutzen. Auf diese Weise lässt sich der größtmögliche Nutzen erzielen.

Die Umsetzung der OWASP Top 10 ist nicht einfach, wenn man sich niemals gezielt mit dem Thema Security auseinandergesetzt hat, aber möglich ist sie. SAST ist eine einfache Möglichkeit, mit den Top 10 anzufangen, und SAST hilft anschließend bei der zeitlichen Vorverlegung der Security-Tests. Richtig implementiert, kann die Methode sogar Probleme vermeiden, anstatt sie nur zu detektieren. Von Vorteil sind darum Tools, die den Standard mit sowohl Detektierung als auch präventiven Checkern vollständig abdecken.

Man sollte lernen, wie man die OWASP-Risikobewertung einsetzt, damit sie bei der Priorisierung der erhaltenen Ergebnisse hilfreich sind und um sicherzustellen, dass die Tools diese Risikoinformationen zusammen mit den Resultaten ausgeben. Das ist wertvolle Hilfe, um sich auf das Wesentliche zu konzentrieren, und entscheidend für eine OWASP-Implementierung. Gerüstet mit diesen Tipps, sollte man in der Lage sein, sofort mit der Beseitigung der verbreitetsten und gefährlichsten Sicherheitsrisiken für Web-Applikationen zu beginnen.

10 Tipps für die DevSecOps-Strategie

* Arthur Hicken ist Chief Software Evangelist bei Parasoft

(ID:46038971)