Was ist der Unterschied zwischen SAST, DAST und IAST?
Kurzantwort
SAST liest den Quellcode, ohne ihn auszuführen, und findet Fehler wie Injection-Sinks früh, aber mit vielen Fehlalarmen. DAST greift die laufende Anwendung von außen ohne Code-Einblick an und findet echte ausnutzbare Probleme, aber spät und mit oberflächlicher Abdeckung. IAST instrumentiert die laufende Anwendung, um Laufzeitverhalten mit dem Code zu korrelieren, und liefert präzise Ergebnisse mit Code-Kontext, benötigt aber eine ausgeübte Anwendung und Agent-Unterstützung.
Diese drei Akronyme beschreiben ergänzende Wege, um Schwachstellen in einer Anwendung zu finden, und ein starker Kandidat erklärt die Kompromisse, statt Definitionen aufzusagen.
Statisch (SAST)
Das Static Application Security Testing analysiert Quellcode, Bytecode oder Binärdateien, ohne sie auszuführen. Es verfolgt den Datenfluss von nicht vertrauenswürdigen Eingaben (Sources) bis zu gefährlichen Operationen (Sinks), um Dinge wie SQL-Injection oder XSS zu kennzeichnen. Da es die gesamte Codebasis sieht, läuft es früh — oft bei jedem Commit oder Pull Request — und zeigt auf die genaue Zeile. Der Preis sind Fehlalarme: Es kann nicht erkennen, ob ein markierter Pfad zur Laufzeit tatsächlich erreichbar ist, sodass der Triage-Aufwand real ist.
Dynamisch (DAST)
Das Dynamic Application Security Testing greift die laufende Anwendung von außen an, wie ein nicht authentifizierter Angreifer, ohne Einblick in den Quellcode. Es findet wirklich ausnutzbare Probleme — defekte Authentifizierung, Fehlkonfigurationen, Injections, die tatsächlich auslösen — und produziert weniger Fehlalarme. Die Nachteile: Es läuft spät (man braucht eine bereitgestellte Umgebung), die Abdeckung hängt davon ab, wie gründlich es die Anwendung durchsucht, und es kann nicht auf den fehlerhaften Code zeigen.
Interaktiv (IAST)
Das Interactive Application Security Testing platziert einen Agenten innerhalb der laufenden Anwendung und beobachtet die Code-Ausführung, während die Anwendung ausgeübt wird (oft durch vorhandene funktionale Tests oder DAST-Tests). Durch die Korrelation des Laufzeit-Datenflusses mit dem tatsächlichen Code liefert es präzise Befunde mit Kontext auf Zeilenebene — weniger Fehlalarme als SAST, mehr Code-Einblick als DAST. Der Haken: Es benötigt Laufzeit-Instrumentierung, Sprach-/Laufzeitunterstützung und gute Testabdeckung, um die Pfade auszuüben.
Was keiner gut erkennt
Fehler in der Geschäftslogik, defekte Autorisierung und Designschwächen entgehen allen dreien — diese erfordern Bedrohungsmodellierung und manuelle Prüfung.
Worauf Interviewer achten
Sie wollen, dass Sie diese als Schichten in einer Pipeline positionieren, eine konkrete Stärke und Schwäche jedes Tools nennen und anerkennen, dass automatisiertes Scannen niemals die menschliche Prüfung ersetzt.
Wahrscheinliche Anschlussfragen
- Warum produziert SAST so viele Fehlalarme und wie verwaltet man sie?
- An welcher Stelle der Pipeline würden Sie jeden Testtyp ausführen?
- Welche Arten von Schwachstellen erkennt keiner dieser Tests zuverlässig?