SAST einfach erklärt
SAST steht für Static Application Security Testing, auf Deutsch etwa „statische Sicherheitsprüfung von Anwendungen“. „Statisch“ heißt: Ein Werkzeug liest den Code, startet das Programm aber nicht. Es sucht nach Mustern, die erfahrungsgemäß zu Sicherheitslücken führen – etwa Eingaben, die ungeprüft weiterverarbeitet werden, gefährliche Funktionsaufrufe oder Passwörter, die fest im Code stehen.
Ein Vergleich aus dem Alltag: SAST gleicht der Prüfung der Baupläne, bevor ein Haus gebaut wird. Wer die Statik prüft, erkennt schon auf dem Papier, wenn eine tragende Wand fehlt. Ob die Haustür später wirklich abgeschlossen wird, verrät der Plan dagegen nicht. Dafür muss man am fertigen Haus rütteln – das ist die Aufgabe von DAST, das die laufende Anwendung von außen prüft.
So funktioniert SAST
- Code einlesen: Das Werkzeug analysiert den Quellcode, also die von Menschen geschriebenen Programmtexte – manche Werkzeuge auch bereits übersetzten Code wie Bytecode oder Binärcode – und bildet daraus ein Modell der Anwendung.
- Datenflüsse verfolgen: Es verfolgt, welchen Weg Daten durch das Programm nehmen. Gelangt etwa eine Benutzereingabe ungeprüft in eine Datenbankabfrage, droht eine SQL-Injection: Angreifer könnten eigene Datenbankbefehle einschleusen.
- Regeln anwenden: Hinterlegte Regeln erkennen bekannte Fehlermuster, etwa veraltete Verschlüsselungsverfahren oder fest eingebaute Zugangsdaten.
- Ergebnisse melden: Jeder Fund erscheint mit Datei, Zeilennummer, Schweregrad und Erklärung.
- Bewerten und beheben: Das Entwicklungsteam prüft die Funde, sortiert Fehlalarme aus und korrigiert den Code.
SAST lässt sich direkt in die Entwicklungsumgebung einbinden, also in das Programm, in dem das Entwicklungsteam den Code schreibt. Es kann auch bei jeder Codeänderung automatisch laufen – in der sogenannten CI/CD-Pipeline, die Software automatisch baut, testet und ausliefert. Fachleute sprechen von „Shift Left“: Sicherheit rückt im Entwicklungsprozess nach vorn.
Ein Beispiel aus der Praxis
Ein mittelständischer Softwareanbieter entwickelt eine Plattform für Terminbuchungen und bindet ein SAST-Werkzeug in seine Pipeline ein. Schon bei der nächsten Codeänderung schlägt es Alarm: Ein neues Suchfeld übergibt Eingaben ungefiltert an die Datenbank. Die Entwicklerin behebt den Fehler in wenigen Minuten, bevor der Code live geht.
Einen anderen Fehler findet das Werkzeug nicht: Über eine manipulierte Buchungsnummer können angemeldete Kunden fremde Termine einsehen. Der Code enthält kein Fehlermuster, nach dem das Werkzeug suchen könnte – es fehlt schlicht eine Berechtigungsprüfung, eine typische IDOR-Schwachstelle. Diese Lücke deckt erst ein manuelles Code Review durch Sicherheitsfachleute auf.
Warum ist das für Unternehmen wichtig?
Je später ein Fehler entdeckt wird, desto aufwendiger wird seine Behebung. Was während der Entwicklung oft in Minuten korrigiert ist, kann in ausgelieferter Software Notfall-Updates, Kundeninformationen und im schlimmsten Fall einen Sicherheitsvorfall nach sich ziehen.
Hinzu kommen Anforderungen von außen. Der Cyber Resilience Act verlangt von Herstellern künftig, die Sicherheit ihrer Produkte wirksam und regelmäßig zu testen und zu überprüfen. Auch ISO/IEC 27001:2022 und PCI DSS 4.0.1, der Sicherheitsstandard der Kartenzahlungsbranche, enthalten Anforderungen an sichere Entwicklung und an die Prüfung von Code. SAST ist ein effizienter Baustein, um solche Anforderungen nachweisbar zu erfüllen.
Allerdings liefern SAST-Werkzeuge auch Fehlalarme, also Meldungen zu Problemen, die gar keine sind, und übersehen ganze Fehlerklassen – vor allem Logikfehler und fehlende Berechtigungsprüfungen. Wer sich allein auf das Werkzeug verlässt, wiegt sich in falscher Sicherheit.
Worauf Sie achten sollten
- Früh und automatisch prüfen: Binden Sie SAST in Entwicklungsumgebung und Pipeline ein, damit jede Änderung geprüft wird.
- Regeln anpassen: Stimmen Sie die Regeln auf Ihre Programmiersprachen und Software-Gerüste (Frameworks) ab und dokumentieren Sie bekannte Fehlalarme.
- Klare Schwellen festlegen: Kritische Funde sollten eine Auslieferung stoppen, weniger dringende in einem festen Zeitraum behoben werden.
- Fremdcode nicht vergessen: SAST prüft vor allem Ihren eigenen Code. Für eingebundene Bibliotheken braucht es zusätzlich eine Abhängigkeitsprüfung (Software Composition Analysis), die Fremdbausteine mit bekannten Schwachstellen abgleicht, und eine SBOM.
- Mensch und Werkzeug kombinieren: Lassen Sie sicherheitskritische Teile wie Anmeldung, Berechtigungen und Zahlungsfunktionen zusätzlich manuell prüfen.
- Laufende Anwendung testen: Ergänzen Sie SAST um DAST und einen Penetrationstest.
Wie Rootsektor unterstützt
Im Rahmen unserer Leistung Code Review & Reverse Engineering nutzen wir SAST-Werkzeuge als Ausgangspunkt, bewerten jeden Treffer manuell und suchen gezielt nach den Fehlern, die Werkzeuge übersehen. Gern unterstützen wir Sie auch dabei, SAST und Abhängigkeitsprüfungen sinnvoll in Ihre Entwicklungsprozesse einzubinden. Nach dem Scoping erhalten Sie ein Festpreisangebot – anfragen können Sie es über unser Pentest-Angebot.