Wissen · Leitfaden Anwendungssicherheit

DAST vs. SAST: Was jede Methode findet und was nicht

SAST untersucht deinen Quellcode, ohne ihn auszuführen. DAST greift die laufende Anwendung von außen an. Beide finden unterschiedliche Fehler, deshalb brauchst du in der Regel beide, dazu Abhängigkeitsprüfung und für Logikfehler einen menschlichen Tester.

Aktualisiert: 6. November 2026

Das Wichtigste in Kürze

Static Application Security Testing (SAST) liest Quellcode, Bytecode oder Binärdateien und sucht nach gefährlichen Mustern, bevor das Programm läuft. Dynamic Application Security Testing (DAST) schickt präparierte Anfragen an eine laufende Anwendung oder API und beobachtet die Reaktion, so wie es ein externer Angreifer tun würde.

Zwei verwandte Begriffe gehören dazu. Software Composition Analysis (SCA) erfasst die eingesetzten Fremdbibliotheken und gleicht sie mit bekannten Schwachstellen ab. Interactive Application Security Testing (IAST) setzt einen Agenten in die laufende Anwendung und beobachtet Datenflüsse von innen, während Funktionstests laufen. Der OWASP DevSecOps Guideline führt alle vier als Bausteine einer Security-Pipeline auf und betont, dass Teams die Schritte anpassen und nach und nach einführen können. Du musst also nicht am ersten Tag alles haben.

Was SAST findet und übersieht

Laut OWASPs Übersicht zu Werkzeugen für Quellcodeanalyse skaliert SAST gut, lässt sich bei jedem Build ausführen, zeigt Entwicklern Datei und Zeile und kann in der IDE laufen, sodass Probleme früh auffallen. Gut bekannte Fehlerklassen wie SQL-Injection erkennt es zuverlässig.

OWASP nennt auch die Schwächen: viele Fehlalarme, nur ein relativ kleiner Anteil aller Sicherheitslücken wird entdeckt, Authentifizierung, Zugriffskontrolle und Kryptografie sind schwer automatisch zu prüfen, und Einstellungen außerhalb des Codes bleiben unsichtbar. Außerdem lässt sich allein aus dem Bericht schwer sagen, ob ein Fund tatsächlich ausnutzbar ist.

• Stark bei: Injection-Mustern, fest eincodierten Geheimnissen, unsicherer API-Nutzung, Verstößen gegen Coding-Regeln
• Schwach bei: Laufzeitkonfiguration, Geschäftslogik, fehlerhafter Zugriffskontrolle, Problemen im Zusammenspiel von Komponenten
• Voraussetzung: Zugriff auf den Code und ein Build, den das Werkzeug versteht

Was DAST findet und übersieht

OWASP beschreibt Schwachstellenscanner für Webanwendungen als Werkzeuge, die eine Anwendung meist von außen auf Probleme wie Cross-Site-Scripting, SQL-Injection, Command-Injection, Path Traversal und unsichere Serverkonfiguration testen. Weil DAST das ausgelieferte System prüft, sieht es, was im Netz tatsächlich antwortet: Header, TLS-Einstellungen, erreichbare Pfade, Fehlerbehandlung und das Verhalten des gesamten Stacks.

Die Kehrseite ist das Spiegelbild von SAST. DAST braucht eine laufende, erreichbare Umgebung und kommt deshalb später im Lebenszyklus. Es sagt dir nicht, welche Codezeile zu ändern ist, sondern nur, welche Anfrage sich falsch verhielt. Die Abdeckung hängt davon ab, wie gut der Scanner die Anwendung durchläuft, sich anmeldet und deine API versteht. Schlecht konfigurierte Scans lassen große Teile aus. Und auch DAST tut sich mit Geschäftslogik schwer.

Wo SCA und IAST hineinpassen

Moderne Anwendungen bestehen zum größten Teil aus Open-Source-Abhängigkeiten. Deshalb ist SCA wichtig, selbst wenn dein eigener Code sauber ist. Es meldet bekannte verwundbare Komponenten und in manchen Werkzeugen auch, ob die verwundbare Funktion von deinem Code aus überhaupt erreichbar ist. Die Dokumentation von Semgrep beschreibt zum Beispiel eine solche Erreichbarkeitsanalyse für Lieferkettenscans.

IAST liegt zwischen den beiden Ansätzen. Weil es Anfrage und Codepfad zugleich sieht, liefert es präzise Ergebnisse mit wenig Rauschen. Es deckt aber nur ab, was deine Tests tatsächlich ausführen, braucht einen Agenten für Sprache und Laufzeitumgebung und verursacht etwas Betriebsaufwand. Sieh es als optionale Verfeinerung, wenn SAST, SCA und DAST schon laufen.

Einbindung in Lebenszyklus und CI/CD

Ordne jede Methode der frühesten Phase zu, in der sie funktioniert. Das Secure Software Development Framework des NIST (SP 800-218, Version 1.1) ist bewusst ergebnisorientiert und schreibt keine Werkzeuge vor, erwartet aber, dass Organisationen Code prüfen und ausführbaren Code auf Schwachstellen testen. Im Dezember 2025 hat NIST außerdem eine überarbeitete Fassung, SSDF Version 1.2, als Entwurf zur öffentlichen Kommentierung veröffentlicht. Die Kommentierungsfrist ist beendet. Prüfe daher die endgültige Fassung, bevor du sie in einem Vertrag zitierst.

OWASP SAMM in Version 2.0 führt Security Testing als eine von drei Praktiken in der Funktion Verification. Es stellt eine skalierbare Basis aus automatisierten Tests neben einen tieferen Strang aus manuellen Tests und Penetrationstests. Das erklärt gut, warum du beides brauchst.

• In der IDE und im Pull Request: SAST, Secret-Erkennung und SCA mit schnellen, schmalen Regelsätzen
• Bei jedem Build: vollständiges SAST und SCA mit einem Quality Gate, das nur sichere und schwerwiegende Funde blockiert
• Auf der Staging-Umgebung: DAST-Basisscans nach jedem Deployment, tiefere authentifizierte Scans nachts oder wöchentlich
• Vor großen Releases und nach größeren Änderungen: manuelle Tests der riskantesten Komponenten

Umgang mit Fehlalarmen

Ein Scanner, dem niemand traut, wird abgeschaltet. Beginne mit einem kleinen, gut abgestimmten Regelsatz, passe ihn an deinen eigenen Code an und erweitere ihn später. Lass den Build nur bei bestätigten Risikoklassen scheitern und führe alles andere als Backlog. Dokumentiere Unterdrückungen mit Begründung und Ablaufdatum, damit daraus keine dauerhaften blinden Flecken werden.

Bestimme eine Person, die Funde bewertet, und nicht nur jemanden, der Scans startet. Ohne diese Entscheidung wird aus den Ergebnissen binnen weniger Wochen Rauschen.

Werkzeugwahl und der Bedarf an Menschen

Das eine beste Produkt gibt es nicht, und OWASP betont, keinen der gelisteten Scanner zu empfehlen. Beispiele helfen beim Vergleich der Kategorien. Bei DAST ist ZAP kostenlos und quelloffen unter der Apache-2.0-Lizenz. Seit September 2024 wird es als ZAP by Checkmarx entwickelt, und das Projekt erklärt, dass es Open Source bleibt und unter Kontrolle seines Kernteams steht. Burp Suite von PortSwigger gibt es als kostenlose Community-Edition, als Professional-Edition für Tester und als DAST-Edition für Unternehmen. Bei SAST ist SonarQube Server ein selbst betriebenes Werkzeug für viele Sprachen und Infrastructure as Code. Semgrep vereint Codescan, Abhängigkeitsscan und Secret-Erkennung auf einer Plattform. Snyk und Checkmarx One bündeln mehrere Scan-Arten, darunter SAST und SCA, in kommerziellen Plattformen.

Vergleiche Werkzeuge anhand deines eigenen Stacks: unterstützte Sprachen und Frameworks, API- und Single-Page-App-Unterstützung bei DAST, CI-Anbindung, Triage der Funde, Ort der Datenverarbeitung und Gesamtkosten inklusive der Menschen, die es betreiben.

• Open-Source-Werkzeuge sind ein guter Start, wenn du Zeit für Abstimmung und Pflege hast
• Kommerzielle Plattformen sparen Integrationsaufwand und bieten Reporting, kosten aber Lizenzgebühren
• Ein Managed-Service für Anwendungssicherheitstests lohnt sich, wenn dir Personal für die Triage fehlt, viele Anwendungen abzudecken sind oder du Prüfern und Kunden regelmäßig Nachweise liefern musst
• Einen manuellen Penetrationstest brauchst du bei Logikfehlern, Zugriffskontrolle oder einem folgenreichen Release; Scanner ergänzen ihn, ersetzen ihn aber nicht