GitLab DevSecOps Teil 8: Dynamic Application Security Testing (DAST)

Alles, was wir bisher in der GitLab DevSecOps Pipeline gemacht haben, war statisch — Analyse von Source Code, Dependencies, Containern und Konfiguration. In Teil 8 überschreiten Patrick Steger und ich die Linie zu Continuous Delivery und ergänzen Dynamic Application Security Testing. DAST heisst: Wir deployen die Anwendung, starten sie und greifen sie von aussen mit einem automatisierten Penetration-Testing-Tool an. GitLab liefert das Feature out of the box mit OWASP ZAP.

Was DAST tatsächlich macht

#

Patrick bringt es auf den Punkt: DAST findet Vulnerabilities in der laufenden Anwendung — man kann es sich als automatisierten Penetration Test vorstellen. Der GitLab-Default ist der OWASP ZAP Attack Proxy. ZAP greift das laufende System an und sucht nach Problemen, die ein statischer Scanner nicht sieht — zum Beispiel Response Header, falsch konfiguriertes TLS oder Injection Points, die erst zur Laufzeit auftauchen.

Eine wichtige Einschränkung gleich vorweg: Ohne explizite, manuelle Konfiguration ist DAST sehr basic. Wer Findings will, die in einem echten Produkt etwas bewegen, muss ernsthaft Zeit in die ZAP-Konfiguration investieren. Das machen wir in diesem Video nicht — dazu gibt es eigene Sessions vom OWASP ZAP Projekt selbst. Was wir hier zeigen: wie man DAST so in die Pipeline einbaut, dass es bei jedem Commit läuft.

Warum DAST in Continuous Delivery liegt

#

DAST kann nicht auf Source Code laufen. Es braucht ein deployed, laufendes System. Genau deshalb ist das der erste Schritt, der uns aus reiner CI in CD bringt. Der Container, den wir in den vorherigen Sessions gebaut und gescannt haben, wird jetzt innerhalb der Pipeline gestartet, damit OWASP ZAP ihn angreifen kann.

Stages explizit definieren

#

Die erste Überraschung: DAST aktivieren ist kein “eine Zeile dazu”. Der Default-DAST-Job von GitLab verlangt eine Stage namens dast. Sobald du Stages explizit definierst, musst du alle aufzählen — sonst verlieren die bestehenden Jobs ihre build-, test- und deploy-Stages. In der .gitlab-ci.yml ergänzen wir also:

stages:
  - build
  - test
  - deploy
  - dast

build, test und deploy existieren standardmässig, aber sobald du Stages deklarierst, müssen sie alle dort stehen.

Den laufenden Container anbinden

#

Als Nächstes setzen wir die Variable CONTAINER_TEST_IMAGE auf das Container Image, das wir früher für das Container Scanning gebaut haben. Im dast:-Job erweitern wir dann services, sodass der Container für diesen Job gestartet und unter dem Alias demoApp erreichbar ist.

Der DAST-Job erwartet eine Variable DOCKER_IMAGE, die ihm sagt, was getestet werden soll, und wir setzen DAST_WEBSITE auf den Service-Alias demoApp, damit OWASP ZAP weiss, wohin die Requests gehen. Um sinnvollere Findings zu bekommen, setzen wir zusätzlich DAST_FULL_SCAN_ENABLED: "true". Ohne dieses Flag macht ZAP nur passive Beobachtung. Mit dem Flag führt ZAP aktive Angriffe aus — versucht also wirklich, etwas kaputtzumachen, statt nur zuzuschauen.

Zum Schluss inkludieren wir das von GitLab gelieferte DAST-Template, sodass die Job-Definition selbst hereingezogen wird.

Die Resultate ansehen

#

Wenn die Pipeline läuft, taucht die neue Stage auf. Im Job-Log siehst du zuerst, wie der Service-Container startet — das ist die Anwendung, die getestet wird. Danach startet der ZAP-Server, führt seinen Scan aus und meldet die Findings zurück. In unserer kleinen Java-Anwendung waren es zwei Warnungen.

Die Findings erscheinen an zwei Stellen. Erstens direkt in der Pipeline-Ansicht im Security Tab — die Summary zeigt zwei neue Vulnerabilities, gefiltert nach DAST. Zweitens unter Security and Compliance im Vulnerability Report, ebenfalls nach Tool filterbar. Die zwei Findings, die wir bekommen, sind sehr basic — zum Beispiel, dass HTTPS nicht aktiviert ist. Wie gesagt: Echte Findings brauchen echte ZAP-Konfiguration — aber die Integration selbst funktioniert genau so, wie sie soll, und darum geht es in dieser Session.

Recap

#

Wir haben die neue dast-Stage hinzugefügt und die Default-Stages daneben neu deklariert. Wir haben das GitLab DAST Template inkludiert, den Endpoint konfiguriert, an dem DAST die Anwendung findet, Full Scan aktiviert, damit ZAP aktiv angreift, und den DAST-Job um einen Service erweitert, sodass der Container erreichbar ist. Fünf kleine Bausteine — und DAST läuft bei jedem Commit.

Damit ist das vollständige DevSecOps-Toolset für unsere Pipeline an Ort. In der nächsten Session schauen wir uns das integrierte Vulnerability Management von GitLab an und wie alle diese Findings dort zusammenlaufen.

Key Takeaways

#

1. DAST testet das laufende System, nicht den Code. Genau hier wechselt die Pipeline von CI zu CD. Ohne deployten, laufenden Container hat OWASP ZAP nichts zum Angreifen.

2. Default-DAST ist absichtlich basic. Behandle den GitLab-Default-DAST-Job als Integrations-Gerüst. Echte, hochwertige Findings brauchen dedizierte Zeit für die ZAP-Konfiguration — das ist ein eigenes Projekt.

3. Explizite Stages bedeuten alle Stages. Sobald du eine dast-Stage deklarierst, musst du auch build, test und deploy deklarieren, sonst brechen die bestehenden Jobs. Leicht zu übersehen, leicht zu debuggen.

4. Service nutzen, um die zu testende Anwendung zu hosten. Der vorher gebaute Container wird als Service unter einem Alias gestartet und über DAST_WEBSITE angesteuert. Dasselbe Image, dasselbe Artefakt — kein separater Deployment-Tanz.

5. Full Scan aktivieren oder du schaust nur zu. Ohne DAST_FULL_SCAN_ENABLED: "true" beobachtet OWASP ZAP nur passiv. Mit dem Flag greift ZAP die Anwendung aktiv an — das ist es, was du von einem Penetration Test erwartest.

6. Findings landen im selben Security Dashboard. DAST-Resultate erscheinen im Security Tab der Pipeline und im projektweiten Vulnerability Report — neben SAST, SCA, Secret Detection und Container Scanning. Ein Ort, um alles zu triagieren.