SAST (Static Application Security Testing)

Wie funktioniert ein SAST-Scan?

Ein SAST-Scan übersetzt den Code zuerst in ein Modell, meist einen Syntaxbaum mit den Datenflüssen zwischen Funktionen. Gegen dieses Modell laufen Regeln. Eine verbreitete Regelart verfolgt Werte aus unsicheren Quellen, etwa einem HTTP-Parameter, bis zu einer gefährlichen Stelle wie einer Datenbankabfrage. Kommt der Wert dort ungeprüft an, meldet das Tool eine mögliche Injection. Andere Regeln suchen nach bekannten Mustern wie Pufferüberläufen in C-Code. Manche Werkzeuge brauchen dafür Code, der sich bauen lässt, samt Bibliotheken und Build-Anweisungen, und OWASP nennt genau das als häufige Hürde. Am Ende steht eine Liste von Befunden mit Regel, Schweregrad und Fundstelle, die die Pipeline als Report zum Build ablegt.

Was ist der Unterschied zwischen SAST und DAST?

SAST prüft den Code von innen, DAST (Dynamic Application Security Testing) die laufende Anwendung von außen. DAST schickt präparierte Anfragen an eine installierte Version, meist in Staging, und findet dabei, was im Quelltext nicht steht, etwa eine fehlerhafte Server-Konfiguration oder eine Anmeldung, die sich umgehen lässt. Die Fundstelle im Code kennt DAST dafür nicht. Das Secure Software Development Framework (SSDF) des US-Instituts NIST (National Institute of Standards and Technology) trennt beides ebenso, als Praktik PW.7 für die Analyse lesbaren Codes und PW.8 für Tests ausführbaren Codes. Eine dritte Prüfart ist SCA (Software Composition Analysis). Sie gleicht die eingebundenen Bibliotheken gegen bekannte Schwachstellen ab und lässt den eigenen Code aus. In einer DevSecOps-Pipeline laufen SAST und SCA im Build, DAST nach dem Deployment in Staging.

Die Schwäche von SAST sind Fehlalarme. OWASP nennt neben vielen False Positives, dass sich Prüfungen zu Authentifizierung und Zugriffsrechten schwer automatisieren lassen und Konfigurationsfehler oft unentdeckt bleiben, weil sie nicht im Code stehen. Ein Entwickler, der dreimal hintereinander einen Fehlalarm wegklicken muss, liest den vierten Befund nicht mehr. Das SSDF beschreibt statische Analyse deshalb zusammen mit einem Menschen, der die gemeldeten Befunde sichtet und behebt. In Deutschland empfiehlt das BSI in der Technischen Richtlinie TR-03185 zum sicheren Software-Lebenszyklus von 2024 eine automatische statische Codeanalyse als Teil der entwicklungsbegleitenden Tests und verweist dabei auf die IEC 62443-4-1, die Norm für die sichere Entwicklung industrieller Komponenten.

Für Steuerungscode nach IEC 61131-3 gibt es eigene statische Prüfwerkzeuge. CODESYS Static Analysis prüft in Version 5.2 vom April 2026 mehr als 100 Regeln, darunter die mögliche Nutzung einer nicht initialisierten Referenz. Welche Regeln für die Sicherheit einer Steuerung zählen, sammelt die Liste Top 20 Secure PLC Coding Practices von 2021, etwa Eingaben vom Bedienpanel in der Steuerung selbst zu prüfen und Speicherbereiche gegen Pufferüberläufe abzugrenzen. In der CI/CD-Pipeline gehört SAST in den Build, parallel zu Dependency- und Container-Scan. Ein Quality Gate blockiert neue Befunde ab einem festgelegten Schweregrad, den Altbestand arbeitet das Team im Backlog ab. So bleibt der Scan eingeschaltet, auch in einem Repository mit zehn Jahren Geschichte.