Static Application Security Testing (SAST)

Ein sicherer Quellcode, um den man sich nicht ständig kümmern muss, ist das oberste Ziel in der Softwareentwicklung. Doch oft fehlt es an dem nötigen Sicherheitsbewusstsein, damit anfällige Programmiermuster vermieden und ausschließlich unbedenkliche APIs verwendet werden. Deshalb sollten statische Anwendungssicherheitstests (Static Application Security Testing, SAST) einen zentralen Bestandteil der Anwendungssicherheit bilden. Denn so kann Quellcode auf Sicherheitslücken überprüft werden, ohne dass Sie selbst aktiv werden müssen.

Die sieben Phasen des Static Application Security Testing (SAST)

So funktioniert SAST

Diese fünf Dinge sollten Sie über SAST wissen:

1. Anwendungen werden „von innen“ analysiert.

2. Die Ausführung ist in sämtlichen Phasen des SDLC möglich.

3. Meist ist ein für das Tool verständliches Build-Model erforderlich.

4. Die Analyse basiert auf einem Regelsatz.

5. Es gibt mehrere Analysearten für verschiedene Ergebniskategorien (siehe Abbildung).

Fünf SAST-Analyseverfahren

Worin unterscheidet sich SAST von anderen Testverfahren?

Um zu beurteilen, ob sich ein bestimmtes Testverfahren für die jeweilige Umgebung eignet, sollte man dessen Vorteile und Grenzen kennen. Deshalb werden hier zunächst verschiedene Testverfahren miteinander verglichen.

SAST, DAST und SCA

Beim Static Application Security Testing (SAST) geht es um den Code. SAST setzt früh in der CI an und scannt Quellcode, Bytecode und Binärcode auf problematische Muster, die nicht den gängigen Best Practices entsprechen. SAST ist also programmiersprachenabhängig.

Beim Dynamic Application Security Testing (Dynamisches Testen der Anwendungssicherheit, DAST) handelt es sich um ein Blackbox-Prüfverfahren, bei dem Anwendungen in der Laufzeitumgebung geprüft werden. Es ist in der CI somit weiter hinten angesiedelt. Das Verfahren ist vor allem dazu geeignet, Regressionen zu verhindern, und ist von der verwendeten Programmiersprache unabhängig.

Hier erfahren Sie mehr über SAST und DAST – die Unterschiede und Kombinationsmöglichkeiten.

Das Interactive Application Security Testing (Interaktives Testen der Anwendungssicherheit, IAST) ist DAST insofern ähnlich, als auch hier Anwendungen in der Laufzeitumgebung geprüft werden. Allerdings kommt dabei eine Kombination aus Blackbox-Tests, Scans und der Analyse anwendungsinterner Abläufe zum Einsatz. Der Vorteil von IAST ist die Möglichkeit, DAST-ähnliche Befunde wie bei SAST mit dem Quellcode in Verbindung zu bringen. Der Nachteil besteht darin, dass IAST programmiersprachenabhängig ist und erst spät in der CI zur Anwendung kommt.

Die Software Composition Analysis (SCA) erkennt Abhängigkeiten von Fremdcode, die in der Anwendung enthalten sind. Das Verfahren ist besonders für Anwendungen geeignet, bei denen viele Open-Source-Bibliotheken zum Einsatz kommen. SCA ist ebenfalls programmiersprachenabhängig.

In diesem Artikel erfahren Sie mehr über SAST und SCA und ihre Einsatzmöglichkeiten zur Gewährleistung der Softwaresicherheit.

SAST und andere Testverfahren für die Anwendungssicherheit

SAST nimmt den Quellcode ins Visier und durchsucht Codezeilen auf Schwachstellen. Dagegen ist DAST völlig blind für den zugrunde liegenden Code und berücksichtigt ausschließlich Ein- und Ausgaben der laufenden Anwendung. In der Praxis ergänzen sich beide Verfahren also gegenseitig. Mit SAST lassen sich Schwachstellen finden, die DAST gerne übersieht – und umgekehrt.

Der größte Unterschied zwischen beiden Verfahren ist ihre Geschwindigkeit. So muss die zu prüfende Anwendung bei DAST ausgeführt werden, was vor allem bei komplexeren Programmen mit einigem Zeitaufwand verbunden ist. Bei SAST wird dagegen der Quellcode geprüft und mit gängigen Programmierstandards abgeglichen, um Verbesserungsvorschläge zu generieren.

SAST sollte daher bereits früh im Entwicklungsprozess eingesetzt werden, also etwa beim Programmieren in der Entwicklungsumgebung, spätestens aber zu Beginn der CI/CD-Pipeline auf den Entwicklungsservern. Später kann dann DAST auf das kompilierte Programm angewendet werden. Bei Sicherheitslücken, die mit beiden Verfahren erkannt werden können, sollte man daher auf das schnellere SAST setzen. Der Rest wird dann in einem späteren Schritt per DAST abgearbeitet.

SAST: Vor- und Nachteile

Wie bereits erwähnt wurde, sind auch SAST-Tools kein Allheilmittel und sollten nach Möglichkeit in Kombination mit DAST verwendet werden. Im Folgenden werden die Vor- und Nachteile von SAST-Tools analysiert und auf ihre praktischen Auswirkungen hin geprüft.

Vorteile:

• Frühzeitiger Einsatz: SAST prüft ausschließlich Quelltext und gleicht diesen mit gängigen Programmierstandards ab. Deshalb kann SAST bereits beim Programmieren ausgeführt werden. IDE-Plugins für SAST-Tools sind weit verbreitet und erkennen Mängel noch vor der Versionskontrolle.

• Erkennung problematischer Codestellen: Da SAST den Quellcode prüft, lässt sich auch die genaue Ursache der gefundenen Schwachstellen identifizieren. Und das erleichtert natürlich deren Beseitigung.

• Keine Testfälle erforderlich: Bei DAST-Tools muss man genau festlegen, was geprüft werden soll. Bei SAST werden die Regeln dagegen auf die gesamte Codebasis angewendet. Diese basieren meist auf mehreren Projekten und vielen Jahren Programmiererfahrung. So lassen sich auch Schwachstellen finden, von denen man bisher nicht die geringste Ahnung hatte. Die Regeln können zudem manuell implementiert oder aber automatisch per ML erzeugt werden. Die verwendeten Algorithmen basieren dabei auf gängigen Open-Source-Repositories.

• Keine Ausführung nötig: SAST setzt vor der Ausführung am Quellcode an. Deshalb ist das Verfahren deutlich schneller als DAST-Testsuites.

• Unkomplizierte Automatisierung: Für die Prüfung von Textdateien ist keinerlei Interaktion mit dem GUI erforderlich. Deshalb lassen sich SAST-Tools viel einfacher automatisieren als DAST-Programme, deren Einrichtung und Verwendung einen deutlich größeren Aufwand verursacht.

Nachteile:

• Fehlalarme: Da SAST am Quelltext ansetzt, ist das Verfahren relativ blind für das große Ganze. Deshalb werden beim ersten Durchlauf meist viel zu viele Treffer gefunden. Die meisten davon erweisen sich jedoch schnell als falsch-positive Ergebnisse. Denn viele der als problematisch eingestuften Codezeilen werden an späterer Stelle entschärft.

• Mangelnder Kontext: Ein Beispiel für die erwähnten Fehlalarme sind unbereinigte Benutzereingaben. Diese bergen zwar ein hohes Sicherheitsrisiko, werden aber meist bereits im Backend beseitigt. Zudem befinden sich Frontend- und Backend-Code oft gar nicht im selben Repository. Die Bereinigung entgeht dem SAST-Programm also völlig und es werden trotzdem entsprechende Meldungen ausgegeben.

• Sprachabhängigkeit: SAST ist stark von der verwendeten Programmiersprache abhängig. Für gängige Sprachen wie Java oder C# gibt es dabei zahlreiche SAST-Tools, während das Angebot für eher unbekannte Programmiersprachen (wie ReScript und Nim) sehr überschaubar ist.

Drei Tipps zur Implementierung

SAST-Programme sind recht einfach in der Implementierung, sofern man einige Dinge beachtet und rechtzeitig anfängt. Wenn allerdings schon Tausende von Codezeilen vorliegen, kann es kompliziert werden. In diesem Fall sollten Sie mehrere Tage Vorlauf einplanen. Das kann beträchtliche Entwicklerressourcen binden, wobei vor allem die Vermeidung von Fehlalarmen recht aufwendig ist.

1\. Das passende Programm finden

Zunächst sollten Sie sich ein Programm suchen, das mit Entwicklungsprozess, Programmiersprache und Budget harmoniert.

Außerdem sollten Sie sich über die Unterschiede zwischen konventionellen und entwicklerfreundlichen Tools im Klaren sein.

SAST ist nichts Neues, doch herkömmliche SAST-Tools sind relativ schwerfällig und brauchen oft mehrere Stunden oder gar Tage. Hinzu kommt noch, dass sie übermäßig viele falsch-positive Ergebnisse liefern und deshalb gerne gemieden werden.

Konventionelle SAST-Programme werden häufig aus der CI/CD-Pipeline herausgelöst und in einen eigenen Prozess überführt, was die Sache noch komplizierter macht und den Releasezyklus in die Länge zieht. Ein weiteres Problem ist die Kommunikation, da die meisten Programme lediglich Listen mit Sicherheitslücken ausgeben, ohne jedoch konkrete Handlungsempfehlungen anzubieten.

Neue entwicklerfreundliche SAST-Tools wie Snyk Code beseitigen diese Mängel und sind ganz auf Schnelligkeit ausgelegt. Zudem lassen sie sich in die Entwicklungsumgebung einbinden und weisen bereits während des Programmierens auf mögliche Schwachstellen hin.

Je nach Arbeitsweise können schnelle SAST-Tools auch erst bei der Übertragung in die Code-Repositories ausgeführt werden. Und mit konkreten Hinweisen und Handlungsempfehlungen unterstützen entwicklerfreundliche SAST-Tools die Problembehebung.

2\. Falschmeldungen aussortieren

In einem nächsten Schritt sollten die falsch-positiven Ergebnisse aussortiert werden. Denn übermäßig viele Falschmeldungen können dazu führen, dass das Programm schlicht nicht mehr ernst genommen wird. Je nach Umfang der Codebasis kann dieser Prozess einige Zeit in Anspruch nehmen, da alle Ergebnisse, die das SAST-Tool findet, von fachkundigen Entwicklern durchgegangen und geprüft werden müssen.

Die KI-Engine von Snyk Code beruht auf der handverlesenen Schwachstellen-Datenbank von Snyk und wurde an erfolgten Commits trainiert. Dadurch wird die Anzahl an Fehlalarmen deutlich reduziert.

3\. In die CI-Pipeline einbinden

Der nächste Schritt besteht darin, das SAST-Tool in die kontinuierliche Integration einzubinden. Wie bereits erwähnt wurde, verfügen einige Programme zwar durchaus über eine vorkonfigurierte IDE-Integration. Doch Entwickler sind meist recht wählerisch, wenn es um ihre Entwicklungsumgebungen geht. Und die Wahrscheinlichkeit, dass das jeweilige SAST-Programm nicht alle davon unterstützt, ist groß.

Zudem kann es die Entwicklungsabteilung auch schlicht versäumen, das Programm auszuführen, bevor neuer Code eingegeben wird. Deshalb ist die CI-Integration bei SAST-Tools äußerst wichtig. Denn so ist sichergestellt, dass jede Codezeile mindestens einmal auf Schwachstellen überprüft wird, bevor sie in die Produktion gelangt.

Entwicklerfreundlichkeit

Mit SAST-Programmen können Sie Sicherheitsmängel früh im Entwicklungsprozess erkennen. Selbst bei knappen Fristen muss sich die Entwicklungsabteilung also nicht ständig damit befassen.

Je nachdem, wann das SAST-Tool in die Softwareentwicklung eingebunden wird, kann es aber durchaus einige Zeit in Anspruch nehmen, bis alles rund läuft. Zu beachten ist außerdem, dass herkömmliche Programme zu viele falsch-positive Ergebnisse liefern, die dann manuell aussortiert werden müssen. Und für eher unbekannte Programmiersprachen gibt es möglicherweise nicht einmal eines, das infrage kommt. Doch entwicklerfreundliche SAST-Tools beseitigen diese Nachteile und gewährleisten damit einen lückenlosen und effizienten Prozess. Entwicklerfreundliche SAST-Tools bieten also signifikante Vorteile und sollten daher im Standardrepertoire jedes sicherheitsbewussten Unternehmens sein.

Tipps, wie Sie das passende SAST-Tool für Ihr Unternehmen finden, erhalten Sie in unserem SAST-Käuferleitfaden.

Halten Sie sich nicht mit falsch-positiven Ergebnissen auf. Sorgen Sie mit dem entwicklerfreundlichen SAST-Tool Snyk Code für einen effizienten, praxisorientierten Entwicklungsprozess – basierend auf maschinellem Lernen und für Open-Source-Repositories kostenlos. Und mit unserem gebührenfreien Code Checker können Sie sich einen ersten Überblick über die Sicherheit Ihres Codes verschaffen.