Viele Entwicklungsteams setzen auf statische Codeanalyse und manuelle Reviews. Diese sind zwar wichtige Bestandteile einer sicheren Softwareentwicklung, können jedoch nicht alle Sicherheitsrisiken abdecken. Schwachstellen entstehen nicht ausschliesslich durch den Code selbst, sondern können auch aus dem Zusammenspiel von Komponenten zur Laufzeit oder aus Deployment-Konfigurationen, Abhängigkeiten oder Laufzeitverhalten resultieren – Faktoren, die sich in einer statischen Analyse nicht vollständig abbilden lassen.

Dynamic Application Security Testing (DAST) schliesst diese Lücke, indem eine laufende Webanwendung oder API aus der Perspektive von Angreifern getestet wird. Dadurch lassen sich Schwachstellen identifizieren, die erst im Betrieb sichtbar werden.

In diesem Beitrag erfahren Sie, wie DAST funktioniert, welche Schwachstellen sich damit identifizieren lassen, wo die Grenzen des Verfahrens liegen und wie sich DAST sinnvoll in CI/CD-Prozesse integrieren lässt.

Wie funktioniert DAST?

DAST untersucht Anwendungen aus der Perspektive von externen Angreifern. Dazu sendet der Scanner automatisierte Testanfragen an die Anwendung und analysiert die daraufhin erzeugten Antworten. Im Gegensatz zu statischen Verfahren wird dabei nicht der Quellcode untersucht, sondern das tatsächliche Verhalten der Anwendung während der Laufzeit.

Der Ablauf eines DAST-Scans in vier Phasen

1. Discovery: Ein Spider bzw. Crawler analysiert die Anwendung und erfasst erreichbare Endpunkte, Parameter und Formulare.
2. Authentifizierung: Der Login-Prozess wird ausgeführt und Session-Informationen für authentifizierte Scans werden verwaltet.
3. Angriffssimulation: Der Scanner sendet automatisierte Testanfragen mit generischen Payloads gegen erkannte Eingabepunkte und analysiert die Antworten der Anwendung.
4. Reporting: Identifizierte Schwachstellen werden nach Schweregrad klassifiziert und zusammen mit technischen Nachweisen (Evidence) dokumentiert.

Grundsätzlich gilt: DAST benötigt eine laufende Umgebung. Scans gegen Produktivsysteme sind nicht empfehlenswert, da Datenbankeinträge verändert und Dienste beeinträchtigt werden können. Der richtige Ort ist eine dedizierte Staging-Umgebung, die möglichst produktionsnah konfiguriert ist.

Shift Left: Sicherheit frühzeitig integrieren

Shift Left bezeichnet den Ansatz, Sicherheitsprüfungen möglichst früh im Entwicklungszyklus zu integrieren. Schwachstellen, die bereits während der Entwicklung erkannt werden, lassen sich so mit minimalem Aufwand beheben.

Nach dem Deployment ist eine Behebung deutlich aufwendiger. Studien zeigen, dass die Behebung in späten Phasen um den Faktor 10 bis 100 teurer sein kann. Sicherheitsprüfungen beschränken sich dabei nicht nur auf den Quellcode. DAST erweitert das Shift-Left-Prinzip konsequent in die Laufzeitphase: Ein DAST-Scan, der bei jedem Nightly Build oder Merge Request automatisiert gegen eine frisch deployte Staging-Umgebung läuft, ist gelebtes Shift Left für das Laufzeitverhalten einer Anwendung.

Warum ist Authenticated Scanning entscheidend?

Der sicherheitsrelevante Teil einer Anwendung findet sich fast immer nach dem Login: Datenverwaltung, Transaktionen, Berechtigungslogik, administrative Funktionen – ein DAST-Scan, der sich nur auf öffentlich erreichbare Endpunkte beschränkt, prüft lediglich die Oberfläche und liefert ein unvollständiges, im schlimmsten Fall sogar irreführendes Bild der tatsächlichen Angriffsfläche.

KEIN AUTHENTICATED SCANNING = KEIN SINNVOLLER SCAN

Authenticated Scanning bedeutet, dass das DAST-Tool den Login-Prozess automatisiert durchführt und Session-Tokens über den gesamten Scan hinweg verwaltet. In der Praxis erfordert das eine sorgfältige Konfiguration, insbesondere bei modernen Authentifizierungsverfahren wie OAuth 2.0 oder OIDC.

OWASP ZAP, das bekannteste Open-Source-DAST-Tool, unterstützt verschiedene Authentifizierungsmethoden, darunter formularbasierte Logins, skriptbasierte Flows für komplexere Szenarien sowie die automatische Erkennung von Login-Mechanismen. Die Konfiguration erfolgt heute über das Automation Framework, eine YAML-basierte Konfigurationsdatei, mit der sich der gesamte Scan-Workflow als Code beschreiben und versionieren lässt.

Was sind Vorteile und Grenzen von DAST?

Dynamic Application Security Testing verwendet automatisierte Testmethoden, bekannte Angriffsmuster und generische Payloads, um Schwachstellen im Laufzeitverhalten einer Anwendung zu erkennen. Diese Automatisierung ist zwar eine grosse Stärke, setzt aber gleichzeitig auch Grenzen, wenn Kontext oder tiefes Anwendungswissen erforderlich sind.

Wo DAST wertvolle Hinweise liefern kann

• Mögliche Injection-Angriffspunkte: SQL-, Command- oder SSTI-Injection durch bekannte Payloads und auffällige Unterschiede im Anwendungsverhalten
• Potenzielle XSS-Vektoren: insbesondere Reflected XSS und teilweise DOM-basierte Szenarien in erkannten Eingabepfaden
• Fehlkonfigurationen: fehlende Security-Header, exponierte Administrationsoberflächen oder unsichere Cookie-Konfigurationen
• Schwaches Session Management: fehlerhafte Session-Verwaltung oder offensichtliche Schwächen in Authentifizierungsabläufen
• Unsichere Zugriffsmuster: erkennbare IDOR-Muster oder unsichere Weiterleitungen
• Nicht ausreichend geschützte API-Endpunkte: bei REST-APIs idealerweise auf Basis einer OpenAPI-/Swagger-Spezifikation, da klassisches Crawling bei API-lastigen Anwendungen und Single Page Applications (SPAs) wie React, Vue oder Angular oft an seine Grenzen stösst

Wo DAST an seine Grenzen stösst

• Kontextabhängige und komplexe Injections, die spezifisches Wissen über die Anwendung erfordern
• Business-Logik-Fehler, da ein Scanner die fachliche Erwartung einer Anwendung nicht kennt
• Stored XSS in komplexen Applikationsflüssen mit mehrstufigen Workflows
• Berechtigungsfehler zwischen Rollen, die nur durch manuelle Analyse erkennbar sind

Wo liegt DAST in der CI/CD-Pipeline?

DAST bietet den grössten Mehrwert, wenn es nicht nur punktuell, sondern als wiederkehrender Bestandteil des Deployment-Prozesses eingesetzt wird. Release-Kandidaten können dadurch automatisiert geprüft werden, bevor sie in die Produktion gelangen.

Für den Einstieg empfiehlt sich OWASP ZAP mit dem offiziellen Docker-Image. Die mitgelieferten Scripts unterscheiden zwei Betriebsmodi:

• zap-baseline.py für schnelle CI-Checks mit passiven Prüfungen und geringer Belastung der Anwendung
• zap-full-scan.py für aktive Scans mit vollständiger Angriffssimulation, geeignet für Nightly Builds oder vor Major Releases

Wer Authenticated Scanning, API-Import oder individuelle Scan-Policies benötigt, kann die Scripts als Ausgangspunkt nutzen und sie über das Automation Framework mit einer eigenen YAML-Konfiguration erweitern.

Ein Hinweis für moderne Architekturen: Bei Single Page Applications (z. B. React, Vue, Angular) kann der klassische Crawler an seine Grenzen stossen. JavaScript-gerenderte Inhalte und komplexes State Handling sind möglicherweise nicht vollständig erfassbar. Für API-lastige Anwendungen empfiehlt sich der direkte Import einer OpenAPI- oder Swagger-Spezifikation als Scan-Grundlage. Das erhöht die Abdeckung deutlich und ist präziser als reines Crawling.

Ein strukturiertes Quality Gate entscheidet automatisch: Findings ab einem definierten Schweregrad blockieren den Deployment-Prozess. Konfiguration, Ziel-URL, Authentifizierung, Scan-Tiefe und Ausschlusslisten leben als YAML-Datei im Repository und werden wie Code versioniert und reviewt.

Was grenzt DAST von statischen Tests (SAST) ab?

Im Bereich Application Security ergänzen sich statische und dynamische Testverfahren. Beide verfolgen unterschiedliche Ansätze und betrachten die Anwendung aus verschiedenen Blickwinkeln.

Die Empfehlung lautet nicht entweder SAST oder DAST, sondern eine Kombination aus beiden:

• SAST früh im Entwicklungsprozess zur Prüfung des Quellcodes
• DAST in der Staging-Umgebung zur Validierung des Laufzeitverhaltens

Wer beide Methoden kombiniert, deckt den gesamten Entwicklungszyklus ab – jeweils genau dort, wo der grösste Mehrwert geboten wird.

Wie hilft DAST mit Compliance-Anforderungen?

Auch aus Compliance-Perspektive liefert Dynamic Application Security Testing einen konkreten Mehrwert:

• PCI-DSS v4.0 fordert explizit Security Testing für webbasierte Anwendungen.
• ISO 27001 Control 8.29 verlangt nachweisbare Sicherheitstests im Entwicklungsprozess.
• Der EU Cyber Resilience Act verpflichtet Hersteller digitaler Produkte ab 2027 zum Nachweis systematischer Sicherheitsprüfungen. Ein automatisierter, versionierter DAST-Prozess ist einer der wenigen Ansätze, der diese Anforderungen vollständig dokumentierbar erfüllt.

Typische Fehler beim Einsatz von DAST

Aus unserer Erfahrung in der Security-Beratung treten beim Einsatz von DAST immer wieder ähnliche Herausforderungen auf. Die folgenden Fehler sollten vermieden werden:

• Nur einmal im Jahr scannen – DAST sollte kontinuierlich laufen und nicht nur kurz vor dem jährlichen Penetration Test. Durch jede Codeänderung können neue Schwachstellen eingeführt werden.
• Gegen die Produktionsumgebung scannen – Aktive Scans verändern Datenbankeinträge und können Dienste beeinträchtigen. Es sollte immer gegen eine isolierte Staging-Umgebung getestet werden.
• Nur ohne Authentifizierung scannen – Der relevante Teil der Anwendung findet sich nach dem Login. Fehlendes Authenticated Scanning bedeutet unvollständige Ergebnisse.
• Kein Prozess und Budget für Findings – DAST kann initial eine hohe Anzahl an Findings, teilweise viele False Positives, erzeugen, die bewertet werden müssen. Wer keinen definierten Remediation-Prozess hat und den Teams keine Kapazität für die Abarbeitung einräumt, wird DAST nach dem ersten Scan wieder einstellen. Prozess, Verantwortlichkeiten und Remediation-Budget müssen vor dem ersten Scan feststehen.
• DAST als Ersatz für Penetration Testing – DAST kann zwar bekannte Muster automatisiert finden, Business-Logik-Fehler und anwendungsspezifische Schwachstellen erfordern jedoch erfahrene Tester. Dementsprechend sollte DAST nicht als Ersatz, sondern vielmehr als Ergänzung zu Penetration Tests und anderen Sicherheitsprozessen angesehen werden.

Fazit und nächste Schritte

Webanwendungen und APIs gehören zu den häufigsten Einstiegspunkten bei Cyberangriffen (Data Breach Report). Wer ausschliesslich den Quellcode auf Sicherheit prüft, hat blinde Flecken im laufenden Betrieb. DAST schliesst diese Lücke automatisiert, reproduzierbar und auditierbar.

Die wirtschaftliche Logik ist klar: Je früher Schwachstellen gefunden werden, desto günstiger ist die Behebung. DAST als fester Bestandteil des Deployment-Prozesses verlagert den Zeitpunkt des Auffindens von der Produktionsumgebung in die Staging-Umgebung und reduziert damit sowohl Kosten als auch Risiken.

Im ersten Schritt sollte ein Baseline-Scan in einer Staging-Umgebung erfolgen. Die Ergebnisse zeigen, wo die grössten Lücken liegen, und bilden die Grundlage für eine strukturierte Application-Security-Strategie.