GlossarSichere EntwicklungTesten

SAST und DAST

SAST analysiert Quellcode, DAST greift die laufende Anwendung an. Was beide finden und übersehen, wo sie in die Pipeline gehören, warum keines den Pentest ersetzt.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

SAST (Static Application Security Testing) analysiert Quellcode oder Binärdateien, ohne sie auszuführen, und findet Muster wie unsichere Funktionen, Injection-Senken und fest kodierte Geheimnisse. DAST (Dynamic Application Security Testing) schickt Anfragen an die laufende Anwendung und beobachtet ihr Verhalten. Beide sind automatisiert, beide gehören in die Build-Pipeline, und beide übersehen Logikfehler, Autorisierungsfehler und alles, was Verständnis des Geschäfts braucht. Das ergänzen manuelles Testen und Code Review.

Was ist SAST und DAST?

SAST und DAST sind die zwei Grundformen automatisierter Anwendungssicherheitstests.

SAST betrachtet die Anwendung von innen, ohne sie auszuführen. Es parst Quellcode (oder Bytecode oder Binärdateien) und verfolgt, wie Daten von Eingaben zu gefährlichen Operationen fließen: ein Request-Parameter, der in einer SQL-Abfrage landet, ein Netzwerkpuffer, der ohne Längenprüfung per memcpy kopiert wird, ein Passwort in einer Konstante. Es kennt jede Codezeile, auch die, die kein Test je erreicht.

DAST betrachtet die Anwendung von außen, während sie läuft. Es crawlt oder bekommt die Schnittstellenbeschreibung, schickt präparierte Anfragen und beobachtet die Antworten: Fehlermeldungen mit Stack Trace, Parameter, die Eingaben reflektieren, missbrauchbare Redirects, fehlende Security-Header, veraltete Serverkomponenten. Vom Code weiß es nichts, nur vom Verhalten.

Verwandte Varianten: IAST instrumentiert die laufende Anwendung und kombiniert beide Sichten, SCA (Software Composition Analysis) prüft Drittkomponenten gegen Schwachstellendatenbanken und erzeugt die SBOM, und Secret Scanning sucht Zugangsdaten in Repositories.

Wo ist es definiert?

Keines von beiden ist ein Standard; beide sind Werkzeugkategorien. OWASP listet und beschreibt SAST-Werkzeuge auf der Seite Source Code Analysis Tools und DAST-Werkzeuge auf der Seite Vulnerability Scanning Tools, und der OWASP ASVS definiert, was die Tests prüfen sollen. NIST SP 800-218, das Secure Software Development Framework, verlangt in Praktik PW.7, dass Code zur Schwachstellensuche reviewt oder analysiert wird, und in PW.8, dass ausführbarer Code getestet wird, mit automatisierten Werkzeugen als üblichem Mittel. Der Cyber Resilience Act verlangt in Anhang I Teil II, dass Hersteller wirksame und regelmäßige Tests und Überprüfungen der Produktsicherheit anwenden; SAST und DAST in der Pipeline sind der Nachweis, den die meisten Hersteller dafür zeigen werden.

Was es in der Praxis bedeutet

Beide Werkzeuge sind gut in der Breite und schlecht in der Tiefe. SAST findet denselben Bug in Sekunden an 40 Stellen, meldet aber auch 400 Dinge, die keine Bugs sind; ohne Tuning hören Teams binnen Wochen auf, die Ergebnisse zu lesen. DAST findet offenliegende Konfigurationsfehler zuverlässig und fast nie einen Autorisierungsfehler, weil es nicht weiß, dass Nutzer A die Bestellung B nicht sehen darf.

In Code Reviews und Web- und API-Penetrationstests wiederholt sich das Muster: Das Projekt betreibt SAST und DAST, die Berichte sind grün oder werden ignoriert, und das kritische Finding ist ein IDOR, eine kaputte Zustandsmaschine im Checkout oder eine Diagnoseroutine, die unter einer Bedingung die Authentifizierungsprüfung überspringt. Nichts davon ist ein Muster, das ein Werkzeug erkennt. Die Werkzeuge verdienen ihren Platz, indem sie die einfachen Bugs vom Tisch nehmen, damit Menschen ihre Zeit für die schweren haben.

Häufige Missverständnisse

Ein sauberer SAST- oder DAST-Lauf ist keine Sicherheitsaussage über das Produkt; es ist eine Aussage über die Abwesenheit bekannter Muster. “Wir lassen einen Scanner laufen” erfüllt auch nicht die Erwartung eines Kunden, Auditors oder einer Regulierung, die einen Penetrationstest verlangt; beides ergänzt sich. Und SAST ersetzt kein Secure Coding: Es findet Vorkommen von Fehlern, während Schulung und Review die Rate senken, mit der sie gemacht werden.

FAQ

Häufig gestellte Fragen

Brauche ich SAST oder DAST, oder beides?

Beides, wenn du Software entwickelst, von der andere abhängen. SAST läuft bei jedem Commit und fängt Bugs dort, wo sie am günstigsten zu beheben sind; DAST läuft gegen ein Test-Deployment und fängt Konfigurations- und Laufzeitprobleme, die SAST nicht sehen kann, etwa fehlende Security-Header, offene Debug-Endpunkte oder eine Authentifizierung, die anders funktioniert, als der Code vermuten lässt. Fang mit SAST an, wenn du dich entscheiden musst, weil es keine laufende Umgebung braucht.

Funktioniert SAST für Embedded-C-Firmware?

Ja, und es ist einer der nützlichsten Einsatzorte. Statische Analysatoren für C und C++ finden Pufferüberläufe, Integer-Überläufe, verbotene Funktionen und MISRA-Verstöße in Firmware, die nie einen Web-Scanner sehen wird. Die Grenzen: Dein Protokoll verstehen sie nicht, also sieht ein UDS-Handler, der jeden Security-Access-Key akzeptiert, für sie in Ordnung aus. Fuzzing und ein manuelles Review der Protokoll-Handler schließen diese Lücke.

Wie stark überschneidet sich der Pentest mit SAST und DAST?

Weniger, als die meisten erwarten. Im Penetrationstest nehmen wir an, dass du Scanner bereits laufen hast, und investieren die Zeit in das, was sie übersehen: Findings verketten, Autorisierungslogik, Geschäftsabläufe, Protokollsemantik und die Prüfung, ob die Scanner-Findings echt sind. Deine SAST- und DAST-Ergebnisse lesen wir gern, wenn du sie teilst; das spart Zeit und schärft den Fokus.

Quellen

Passende Seiten

← Glossar