Seminar OWASP ZAP – Docker, Headless-Betrieb und Packaged Scans

Container vereinfachen reproduzierbare ZAP-Läufe, verbergen aber häufig Netzwerk-, Dateirechte- und Browserprobleme. Ein erfolgreicher Start bedeutet noch nicht, dass Ziel, Konfiguration und Artefakte korrekt erreichbar sind.

Das Seminar beginnt mit einem transparenten Containerlauf und erweitert ihn schrittweise zu Packaged Scans und Automation-Framework-Plänen.

Inhaltsübersicht

1. Seminarziel und Arbeitsweise
2. Image und Ausführungsmodell auswählen
3. Netzwerk, Ports und Zielerreichbarkeit prüfen
4. Volumes, Konfiguration und Reports verwalten
5. Baseline-, Full- und API-Scans einsetzen
6. Automation Framework im Container
7. Browser, Ressourcen und Fehlerdiagnose
8. Praxisübungen und Arbeitsaufträge
9. Zielgruppe, Voraussetzungen und Arbeitsumgebung

Seminarziel

ZAP in Containern sicher, reproduzierbar und diagnostizierbar ausführen sowie den passenden Scanmodus für passive, aktive und API-orientierte Prüfungen auswählen.

Arbeitsweise

Vortrag, Demonstrationen und praktische Übungen werden in kurzen Arbeitszyklen verbunden. Jeder Themenblock beginnt mit einem klar abgegrenzten Testziel, führt über die Konfiguration und Durchführung zur fachlichen Prüfung und endet mit dokumentierten Kontrollpunkten. Belastende oder angreifende Funktionen werden ausschließlich in ausdrücklich freigegebenen Labor- und Zielumgebungen eingesetzt.

Schrittweise Seminarinhalte

1. Image und Ausführungsmodell auswählen

Stable-, minimale und aktuellere Images erfüllen unterschiedliche Anforderungen. Für produktive Automatisierung wird eine bewusst versionierte Variante verwendet.

1. Funktionsumfang und Updatebedarf des Images bestimmen.
2. Imageversion statt unkontrolliertem Latest-Verhalten festlegen.
3. Benutzer, Arbeitsverzeichnis und Dateirechte prüfen.
4. Containerstart mit einfacher Versions- und Hilfeabfrage validieren.

Kontrollpunkte: Imagewahl ist dokumentiert; Container läuft ohne unnötige Root-Rechte.

2. Netzwerk, Ports und Zielerreichbarkeit prüfen

Container-DNS, Hostzugriff und Proxyketten werden isoliert getestet, bevor ZAP gestartet wird.

1. Ziel mit einem einfachen HTTP-Client aus demselben Image erreichen.
2. Bridge-, Host- oder Service-Netzwerk passend auswählen.
3. Listenerport und API-Zugriff nur bei Bedarf veröffentlichen.
4. TLS- und Namensauflösungsprobleme getrennt diagnostizieren.

Kontrollpunkte: Ziel ist aus dem Container eindeutig erreichbar; API-Port ist nicht unnötig extern exponiert.

3. Volumes, Konfiguration und Reports verwalten

Pläne, Contexts, Regeldateien und Berichte benötigen kontrollierte Mounts und konsistente Dateirechte.

1. Eingabe- und Ausgabeverzeichnisse trennen.
2. Read-only Mounts für unveränderliche Konfiguration verwenden.
3. Report- und Sessionpfade explizit setzen.
4. Artefakte nach Containerende auf Vollständigkeit prüfen.

Kontrollpunkte: Konfiguration wird nicht versehentlich im Container verändert; Berichte gehören dem erwarteten Hostbenutzer.

4. Baseline-, Full- und API-Scans einsetzen

Die Packaged Scans unterscheiden passive Kurzprüfung, vollständigen aktiven Scan und definitionsbasierten API-Test.

1. Baseline Scan mit Zeitlimit und Regelkonfiguration ausführen.
2. Full Scan nur gegen freigegebene Umgebung starten.
3. API Scan mit geeignetem Definitionsformat konfigurieren.
4. WARN-, INFO-, IGNORE- und FAIL-Einstellungen nachvollziehen.

Kontrollpunkte: Scanart entspricht dem Freigabestatus; Konfigurationsdatei ist versioniert und geprüft.

5. Automation Framework im Container

Für komplexe Abläufe ersetzt ein YAML-Plan lange Kommandozeilen und bündelt Authentifizierung, Discovery, Scan und Bericht.

1. Plan und Laufzeitvariablen mounten.
2. Environment und Jobs im Container validieren.
3. Secrets über Umgebungs- oder Secretmechanismus einspeisen.
4. Exit-Status und Reportpfade an den Aufrufer zurückgeben.

Kontrollpunkte: Plan läuft lokal und in der Zielplattform gleich; Secrets verbleiben nicht in Containerlayern oder Artefakten.

6. Browser, Ressourcen und Fehlerdiagnose

Client Spider und browserbasierte Regeln benötigen zusätzliche Ressourcen und funktionierende WebDriver-Komponenten.

1. Headless-Browser in einem kleinen Testlauf verifizieren.
2. Speicher, CPU, Shared Memory und Laufzeit begrenzen.
3. Logs, Containerstatus und ZAP-Ausgabe gemeinsam auswerten.
4. Diagnosefolge für Netzwerk, Rechte, Browser und Zielreaktion anwenden.

Kontrollpunkte: Fehlerursache ist einer Schicht zugeordnet; Ressourcenlimit führt zu kontrolliertem Fehler statt stiller Unvollständigkeit.

Praxisübungen und Arbeitsaufträge

• Start eines versionierten ZAP-Containers mit sicherer Dateizuordnung
• Diagnose einer absichtlich gestörten Container-Netzwerkverbindung
• Ausführung und Vergleich von Baseline-, Full- und API-Scan
• Automation-Framework-Lauf mit gemountetem Plan und Report
• Headless-Client-Spider-Test mit Ressourcenmessung

Zielgruppe

DevSecOps Engineers, Administratoren, Application-Security-Teams, Build- und Plattformverantwortliche

Voraussetzungen

ZAP-Grundlagen, Docker- und Kommandozeilenkenntnisse sowie Zugriff auf eine kontrollierte Testanwendung

Arbeitsumgebung

Verwendet werden eine isolierte ZAP-Installation oder ein geeigneter Container, ein getrenntes Browserprofil, eine ausdrücklich freigegebene Laboranwendung, vorbereitete Testkonten und versionskontrollierbare Konfigurationsdateien. Produktive Ziele, persönliche Konten und nicht genehmigte Drittsysteme sind ausgeschlossen.