Quality Gates und aktueller Automatisierungsstand

Aktive Baseline

Das Profil quality-gates und das gleichnamige Jenkins-Stage sind opt-in:

mvn -T 1C -Pquality-gates verify

Es prüft eine Java-Laufzeit ab 17 bei festem Compiler-Release 17, erzeugt einen JaCoCo-Coverage-Report, erstellt mit CycloneDX

ein SBOM im jeweiligen target-Verzeichnis und lässt seit 2026-08-29 zusätzlich OWASP

Dependency-Check (dependency-check-maven, aggregate-Ziel, einmal für den gesamten Reactor statt

elfmal pro Modul) über alle Maven-Abhängigkeiten laufen. Jenkins führt dieses Profil im Stage

Quality baseline: Java, Coverage, SBOM nur mit RUN_QUALITY=true aus und archiviert die

erzeugten Reports. Die lokale Verifikation des verify-Profils überschritt am 10.08.2026 das

Zeitfenster von 180 Sekunden; deshalb bleibt der normale Jenkins-Build davon entkoppelt.

Zusätzlich prüft die immer aktive Jenkins-Stage Frontend: Install & Test seit 2026-08-29 die

npm-Abhängigkeiten des Angular-Frontends mit npm audit --omit=dev --audit-level=high — anders

als die Java-Quality-Baseline blockierend, weil ein npm audit ohne externe Datenbank-

Downloads schnell und reproduzierbar läuft und aktuell (Stand 2026-08-29) 0 Findings liefert.

Checkstyle und SpotBugs sind noch keine blockierenden Gates. Dafür fehlen eine abgestimmte

Regelbasis und eine projektweite Baseline für zulässige Findings. OWASP Dependency-Check ist zwar

jetzt im quality-gates-Profil konfiguriert (s. o.), aber bewusst noch ohne

failBuildOnCVSS (reines Reporting) — der erste tatsächliche Lauf gegen die NVD-CVE-Datenbank

wurde in dieser Umgebung nicht verifiziert (kein NVD_API_KEY gesetzt; ein Erstlauf ohne API-Key

kann laut Projekt-Dokumentation der Tools mehrere Minuten bis Stunden dauern und wurde deshalb

nicht blind ausgeführt). Der nächste sinnvolle Schritt: NVD_API_KEY als Jenkins-Credential

hinterlegen, einen Lauf beobachten, dann anhand der realen Findings eine Baseline abstimmen und

erst danach failBuildOnCVSS aktivieren.

Optionaler Jenkins-Stage Security: OWASP ZAP Baseline Scan (RUN_ZAP=true) führt einen passiven

Baseline-Scan gegen den bereits laufenden Docker-Compose-Stack (http://procurex.localhost) aus

und archiviert den Report als Build-Artefakt. Wie bei Checkstyle/SpotBugs/OWASP Dependency-Check

(Java-Seite) gilt: kein Pflicht-Gate. zap-baseline.py liefert bei WARN-Funden einen Exit-Code ungleich 0;

die Stufe wird bewusst nicht rot, solange keine abgestimmte Findings-Baseline für dieses Projekt

existiert. Details und Begründung direkt im Jenkinsfile, Stage-Kommentar.

Ein grüner Quality-Baseline-Lauf beweist Java-Kompatibilität, Test-/Coverage-Instrumentierung

und SBOM-Erzeugung.

Er beweist noch nicht, dass eine Mindest-Coverage erreicht wird; ein Schwellenwert wird erst

nach einer fachlich vereinbarten Baseline aktiviert.

Das SBOM erfasst die Maven-Abhängigkeiten; OWASP Dependency-Check prüft sie zusätzlich auf

bekannte CVEs (Reporting, noch nicht blockierend). Die npm-Abhängigkeiten des

Angular-Frontends deckt seit 2026-08-29 der blockierende npm audit-Schritt in

Frontend: Install & Test ab.

Ein grüner npm audit-Lauf beweist die Abwesenheit bekannter High/Critical-Advisories zum

Zeitpunkt des Builds — nicht die Abwesenheit aller Sicherheitsrisiken, und nicht rückwirkend

für spätere, neu veröffentlichte Advisories in bereits gebauten Artefakten.