# Quality Gates und aktueller Automatisierungsstand

## Aktive Baseline

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

```powershell
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.

## Bewusste Grenze

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.

## OWASP ZAP Baseline Scan (seit 2026-08-17)

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.

## Nachweisinterpretation

- 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.