DAST (Dynamic Application Security Testing) prüft eine laufende Webanwendung mit automatisierten Angriffsmustern wie SQL-Injection und Cross-Site-Scripting. Ein Tool wie ZAP sitzt dabei als Proxy zwischen Test und Anwendung, lernt zuerst den normalen Verkehr kennen und baut dann Angriffe in die aufgezeichneten Requests ein. Für Finanzinstitute ist das seit der DORA-Verordnung ein Baustein der verlangten Sicherheitstests, neben SAST, SCA und Pentests.
Das Wichtigste in Kürze
- Während SAST den Quellcode prüft und SCA Fremdbibliotheken gegen Schwachstellendatenbanken abgleicht, greift DAST die laufende Webanwendung mit Mustern wie SQL-Injection und Cross-Site-Scripting an.
- Die DORA-Verordnung verlangt von Banken und Versicherungen Sicherheitstests für Internet-exponierte Anwendungen; der dynamische Test muss mindestens vor jeder Produktivsetzung gelaufen sein.
- ZAP (Zed Attack Proxy) sitzt zwischen Testausführung und Anwendung: Die Explore-Phase zeichnet Requests und Responses auf, danach baut das Tool Angriffe in genau diesen Verkehr ein.
- Vorhandene Playwright- oder Selenium-Regressionstests liefern die Explore-Phase, ein Jenkins-Job startet den Angriffslauf danach, etwa nach dem Deployment auf die Vorproduktion oder am Wochenende.
- Daniel Schmuck will die Befunde aus SAST, SCA, DAST, Pentests und Infrastrukturscans in einer Sicht je Anwendung zusammenführen, weil eine veraltete Bibliothek sonst dreimal gemeldet wird.
Warum landet DAST bei einer Bank im Testmanagement?
Weil die DORA-Verordnung es verlangt und das Thema in die Querschnittseinheit fällt, die den Softwareentwicklungsprozess, das Testmanagement und die Testautomatisierung verantwortet. DAST steht für Dynamic Application Security Testing: automatisierte Sicherheitstests gegen die laufende Anwendung, früh in der Entwicklung, statt Sicherheit erst in Produktion über einen Penetrationstest nachzuweisen. Daniel Schmuck verantwortet bei einer Bank den IT-Prozess Testmanagement. Er übersetzt regulatorische Vorgaben in hauseigene Testvorgaben und kümmert sich um die GUI-basierte Testautomatisierung. Sicherheitstests lagen bis dahin woanders.
Der Digital Operational Resilience Act, kurz DORA, ist seit Januar 2025 für Finanzinstitute verbindlich, für Banken wie für Versicherungen. Die Verordnung und ihr technischer Regulierungsstandard verlangen Sicherheitstests in der Anwendungsentwicklung, darunter statische und dynamische Prüfungen. DAST allein erfüllt DORA nicht, es ist ein Baustein des verlangten Testprogramms. Aber dieser Baustein ist ein dynamischer, automatisierter Test, und wer im Haus der zentrale Ansprechpartner für Testautomatisierung ist, bekommt ihn zwangsläufig auf den Tisch. So landete das Thema bei Daniel.
Für Test- und Qualitätsleute ist das eine späte Genugtuung. Shift-Left, also Fehler möglichst früh finden, in diesem Fall Sicherheitsschwachstellen, wünschen sie sich seit Jahren. Hier zwingt eine Verordnung dazu.
Die Verordnung sagt Quellcode-Prüfung und meint etwas anderes
Der Einstieg lief über Selbststudium: die DORA-Verordnung selbst und der technische Regulierungsstandard, der sie genauer beschreibt. Dort ist von statischen und dynamischen Quellcode-Prüfungen die Rede. Für jemanden mit ISTQB-Hintergrund klingt eine dynamische Quellcode-Prüfung nach einem Widerspruch, denn Quellcode prüft man statisch, dynamisch testet man die laufende Anwendung.
„Ich habe einen ISTQB-Hintergrund, und die dynamische Quellcode-Prüfung war für mich irgendwie ein Widerspruch.“
(Daniel Schmuck)
Die Recherche führte zu drei Begriffen, die so nicht in der Verordnung stehen, wohl aber im ISTQB-Glossar: SAST, DAST und SCA. SAST, Static Application Security Testing, prüft den Quellcode ohne laufende Anwendung, etwa mit SonarQube und dessen Security-Regeln. SCA, Software Composition Analysis, gleicht Fremd- und Open-Source-Bibliotheken mit Schwachstellen-Datenbanken ab. DAST testet die Anwendung im Betrieb auf einer Testumgebung mit Angriffsmustern. Daniel nennt das einen Dreiklang. Die statischen und dynamischen Quellcode-Prüfungen der Verordnung entsprechen SAST und DAST; SCA ist der dritte Aspekt, den Daniel dazuzählt.
Dann die Werkzeugfrage. Daniel hat eine Affinität zu Open Source und startet lieber mit einer kostenfreien Lösung; stößt sie an Grenzen, kann er immer noch kommerzielle Tools vergleichen. Für DAST führt dieser Weg fast zwangsläufig zu ZAP, dem Zed Attack Proxy, heute als ZAP by Checkmarx geführt und vielen noch als OWASP ZAP geläufig. Eingearbeitet hat er sich über die Dokumentation, die Community und Videos zum Tool.
Wie funktioniert ZAP als Proxy zwischen Test und Anwendung?
ZAP schaltet sich als Proxy zwischen Testausführung und Anwendung und arbeitet in zwei Phasen. Das Werkzeug ist für Webanwendungen gebaut, also für HTTP- und HTTPS-Verkehr. Ob jemand die Anwendung manuell im Browser bedient oder ein automatisierter Test sie durchläuft: Jeder Request und jede Response geht durch ZAP.
| Phase | Was passiert | Woher der Input kommt |
|---|---|---|
| Explore | ZAP zeichnet den normalen Verkehr auf und lernt, wie eine gute Interaktion mit der Anwendung aussieht | manuelle Bedienung über die ZAP-Oberfläche, ein schlanker Aufruf per Adresse oder funktionale Tests, bei Bedarf detailliert gesteuert über die REST-API |
| Angriff | ZAP baut Angriffsmuster in die aufgezeichneten Requests ein und fährt sie gegen die Anwendung: SQL-Injection, Cross-Site-Scripting, das volle Spektrum | Profile legen fest, welche Prüfregeln laufen |
Die zweite Phase läuft automatisch, man schaut zu. Profile steuern, welche Angriffsregeln zur Wirkung kommen, und das hängt auch an der Technologie. Steht hinter der Anwendung eine DB2 oder eine SQLite, laufen nur die SQL-Injection-Regeln für diese Datenbank. Den größten Einfluss auf Dauer und Umfang der Angriffe hat aber, was in der Explore-Phase aufgezeichnet wurde.
Trotz solcher Konfiguration bleibt es ein Blackbox-Test über die Schnittstellen des Systems. Das muss kein Browser sein. Für REST-Services nimmt ZAP eine OpenAPI-Definition, für GraphQL eine GraphQL-Definition, für SOAP-Services die WSDL. Service-basierte Schnittstellen lassen sich damit genauso prüfen wie Oberflächen.
Regressionstests liefern den Verkehr für die Explore-Phase
Das Ziel ist, die Explore-Phase nicht von Hand zu füttern. Die manuelle Bedienung über die Oberfläche taugt zum Kennenlernen des Tools, mehr nicht. Stattdessen laufen die vorhandenen funktionalen Regressionstests durch den Proxy. Wer Browser-Tests mit Playwright oder Selenium hat, konfiguriert im Browser ZAP als Proxy, und der komplette funktionale Test zeichnet nebenbei alle Requests und Responses auf. Niemand klickt, niemand protokolliert.
Die vorhandene Testautomatisierung zahlt sich damit zweimal aus. Der Regressionstest prüft weiterhin die Fachlichkeit, derselbe Lauf liefert ZAP die Basis für die Angriffsphase. Je breiter die funktionalen Tests die Anwendung abdecken, desto mehr Angriffsfläche kennt das Tool danach.
Fällt man beim ersten DAST-Report vom Stuhl?
Nein, jedenfalls nicht, wenn vorher schon Penetrationstests liefen. DORA verlangt die Tests ausdrücklich für Internet-exponierte Anwendungen, also für alles, was jeder von außen aufrufen kann, etwa die Website der Bank mit dem geschlossenen Kundenbereich. Genau diese Anwendungen lässt die Bank seit Längerem von externen Experten per Penetrationstest prüfen. Daniel erwartete vom ersten DAST-Lauf deshalb eine Bestätigung der jüngsten Pentest-Ergebnisse. Genau das kam heraus: keine kritischen Treffer, dieselben Befunde.
Der Nutzen liegt woanders. Der Penetrationstest ist eine beauftragte Expertenleistung zu einem Zeitpunkt. Der automatisierte Test wiederholt die Prüfung auf der Testumgebung, so oft die Pipeline ihn anstößt, und zwar vor jeder Produktivsetzung.
Wie oft muss der Sicherheitstest in der Jenkins-Pipeline laufen?
Mindestens einmal vor jeder Produktivsetzung, das ist die regulatorische Anforderung. Alles darüber ist Ermessen. Die Bank bildet ihre CI/CD-Pipelines in Jenkins ab: Quellcode bauen, paketieren, auf die Testumgebung deployen. End-to-End- und GUI-Tests laufen in eigenen Jobs. Für die Sicherheitstests gibt es nun ebenfalls eigene Jenkins-Pipelines je Anwendung, mit der jeweiligen ZAP-Konfiguration dahinter.
Diese Jobs lassen sich an verschiedene Auslöser hängen. Kommt ein neuer Anwendungsstand auf die Vorproduktionsumgebung, läuft nach dem Deployment der Sicherheitstest. Oder er läuft jedes Wochenende. Täglich wie ein funktionaler Regressionstest muss er nicht laufen. Aber vor dem Go-live muss er gelaufen sein.
Plugin-Updates halten die Angriffsregeln aktuell
Open Source ist nicht gleich Open Source, deshalb lohnt der Blick auf die Pflege. ZAP selbst hat seit der Einführung bei der Bank kein neues Release bekommen. Die Funktionen stecken aber in Plugins, und die werden teils alle zwei Wochen aktualisiert, gerade die Prüfregeln. Daniels Eindruck: Hinter dem Tool steht eine aktive Community.
Für Sicherheitstests ist das kein Nebenaspekt. Jeden Tag kommen neue Angriffsvektoren dazu, neue Ideen, wie sich etwas kaputt machen lässt. Ein Regelwerk von vor zwei Jahren prüft gegen die Angreifer von vor zwei Jahren. Dass die Plugins automatisch aktualisiert werden können, hält den Test auf dem Stand von heute.
Eine Sicht auf alle Schwachstellen, damit Entwickler nicht dreimal dieselbe Meldung bekommen
Als Nächstes will Daniel die Ergebnisse zusammenführen, denn ZAP hat keine eigene Ergebnisverwaltung. Anders als SonarQube, wo sich Befunde aus statischer Analyse und SAST im Tool abrufen lassen, liefert ZAP einen Report als JSON, XML, PDF oder HTML und hält sonst keine Daten vor. Daneben gibt es das SCA-Tool mit eigenen Ergebnissen, die Pentest-Berichte der beauftragten Agenturen und betriebsseitige Infrastrukturscans, die PCs, Server und andere Endgeräte regelmäßig auf Schwachstellen und veraltete Bibliotheken prüfen.
Das sind vier, fünf Töpfe mit Befunden, die idealerweise in einer Sicht je Anwendung landen. Sonst passiert Folgendes: Der Pentester meldet eine veraltete Bibliothek. Der DAST-Lauf meldet sie auch. Der Infrastrukturscan findet sie auf dem Testserver ein drittes Mal. Drei Meldungen, eine Ursache. Irgendwann sind die Entwickler mit Doppelmeldungen überlastet, und die sollen ja auch noch Features bauen.
Gleichzeitig rücken Schwachstellen immer weiter nach vorn, und für ihre zeitnahe Behebung gibt es eigene Anforderungen. Wer die Meldungen konsolidiert, nimmt den Entwicklern Doppelarbeit ab und lässt ihnen die Zeit für das, was wirklich offen ist. Redundanzen vermeiden ist deshalb der Punkt, den Daniel als Nächstes angeht.
Häufig gestellte Fragen
Was ist der Unterschied zwischen SAST, DAST und SCA?
Die drei Verfahren prüfen die Anwendungssicherheit an unterschiedlichen Stellen. SAST (Static Application Security Testing) analysiert den Quellcode, ohne dass die Anwendung läuft, etwa mit SonarQube und speziellen Security-Regeln. SCA (Software Composition Analysis) gleicht eingebundene Fremd- und Open-Source-Bibliotheken mit Schwachstellen-Datenbanken ab. DAST testet die laufende Anwendung auf einer Testumgebung, indem es Angriffsmuster gegen sie ausführt.
Welche Sicherheitstests verlangt die DORA-Verordnung?
Der technische Regulierungsstandard zu DORA spricht von statischen und dynamischen Quellcode-Prüfungen, gemeint sind Verfahren wie SAST und DAST. Pflicht sind sie für Internet-exponierte Anwendungen, also alles, was Kunden von außen aufrufen können, und sie müssen vor jeder Produktivsetzung gelaufen sein. DAST ist dabei ein Baustein des Testprogramms, Penetrationstests durch externe Experten laufen weiter.
Ersetzt DAST den Penetrationstest?
Nein. Der Penetrationstest bleibt eine beauftragte Expertenleistung zu einem bestimmten Zeitpunkt. Ein automatisierter DAST-Lauf wiederholt dagegen Angriffsmuster auf der Testumgebung, so oft die Pipeline ihn anstößt, und läuft vor jeder Produktivsetzung. Bei der Bank bestätigte der erste Durchlauf die jüngsten Pentest-Ergebnisse, ohne neue kritische Treffer. Beide Verfahren laufen dort parallel.
Ist ZAP kostenlos?
Ja, ZAP ist Open Source und kostenfrei einsetzbar. Die Funktionen stecken in Plugins, die teils alle zwei Wochen aktualisiert werden, darunter die Prüfregeln für Angriffe. Eine eigene Ergebnisverwaltung bringt das Tool nicht mit, es liefert Reports als JSON, XML, PDF oder HTML. Wer an Grenzen stößt, kann später kommerzielle Werkzeuge vergleichen.
Ist DAST ein Blackbox-Test?
Ja, weitgehend. Das Werkzeug arbeitet über die Schnittstellen des Systems, also über den Browser oder die Services, und braucht keinen Zugriff auf den Quellcode. Für REST nimmt es eine OpenAPI-Definition, für GraphQL eine GraphQL-Definition, für SOAP die WSDL. Über Profile lassen sich die Angriffsregeln an die Technologie anpassen, etwa SQL-Injection-Regeln für eine bestimmte Datenbank.
