Dokumentation
Fachliche und technische Dokumentation aller Seiten, Felder und Funktionen
Security Evidence
Security Evidence fasst alle sicherheitsrelevanten Nachweise einer Anwendung strukturiert zusammen: statische und dynamische Scans, Abhängigkeits- und Container-Analysen, Secrets-Detection, SBOMs sowie dokumentierte Risikoakzeptanzen. Das Modul liefert damit die faktische Grundlage für Service-Scorecards, Freigabeentscheidungen in AccessHub, Compliance-Reports und Rezertifizierungsentscheidungen.
Zweck
Zentrales, auditierbares Inventar aller Sicherheitsbefunde je Service, Tenant und Umgebung mit nachvollziehbarem Lifecycle von Open bis Closed.
Quellen
SonarCloud (SAST), OWASP ZAP (DAST), Dependency-Check und Trivy (SCA/Container), GitLeaks (Secrets), CycloneDX-SBOMs und manuell erfasste Pentest-Reports.
Konsumenten
Backstage Service-Cards, AccessHub Approval Policies (Prod-Gate), Security/Compliance-Reports, CISO-Board, Rezertifizierungen und interne Auditnachweise.
Integrationspipeline
Findings werden pro Lauf eingesammelt, auf CVE/CWE normalisiert, mit externen Datenquellen angereichert (CISA KEV, EPSS, MITRE ATT&CK), dedupliziert, dem zuständigen Owner-Team zugeordnet und risikobasiert priorisiert. Erst dann landen sie im Evidence Store als authoritative Referenz.
Lifecycle und Severity-Flow
- •Open: Finding wurde vom Scanner erzeugt, aber noch nicht bewertet.
- •Triaged: Owner und Severity sind bestätigt, MITRE-Taktik und EPSS angereichert.
- •In Progress: Fix-Branch, Ticket oder WAF-Regel aktiv; SLA-Clock läuft.
- •Mitigated: Re-Scan bestätigt, dass Finding nicht mehr reproduzierbar ist.
- •Accepted / Closed: Formale Risk Acceptance durch CISO oder endgültiger Abschluss nach Fix.
Severity-Verteilung und SLA-Fristen
Erfasste Attribute pro Finding
| Attribut | Bedeutung |
|---|---|
| ID · Source | Eindeutige Finding-ID und auslösender Scanner (z. B. DC-2026-014 · Dependency-Check). |
| Service · Tenant | Bezug zur CMDB-Entity und zum Ziel-Tenant (fis, tnt, fise, dso). |
| CVE · CWE | Referenzierte Schwachstellenkategorie und -klasse. |
| CVSS · EPSS · KEV | Quantitative Bewertung, Exploit-Wahrscheinlichkeit, CISA KEV-Flag. |
| Attack Vector Profile | AV/AC/PR/UI gemäß CVSS v3 für kontextuelle Risikoeinschätzung. |
| Exploit Maturity · Patch verfügbar | Zustand des bekannten Exploits und Verfügbarkeit eines Fixes. |
| MITRE ATT&CK Tactics | Taktik-/Technik-Mapping für Defense-in-Depth und Detection Engineering. |
| Owner · Age · Due | Verantwortliches Team, Alter des Findings, SLA-basierte Fälligkeit. |
| Timeline | Lückenloser Audit-Trail: Erkennung, Triage, Fix, Re-Scan, Freigabe. |
| Remediation · References | Konkrete Fix-Anleitung und externe Quellen (NVD, Vendor, KEV). |
Kopplung mit AccessHub und Backstage
- •Prod-Zugriffe auf Services mit offenen Critical-Findings oder KEV-Flag werden durch AccessHub-Approval-Policies blockiert bzw. mit Vier-Augen-Prinzip und Zeitbegrenzung versehen.
- •Backstage zeigt je Component/Resource eine Security-Card mit Open, Critical, KEV, Ø CVSS und MTTR und verlinkt auf das Evidence-Detail.
- •Rezertifizierungskampagnen in AccessHub konsumieren den Evidence-Snapshot, damit Genehmiger die aktuelle Risikolage bei jeder Verlängerung sehen.
- •Reports/Compliance-Exporte bündeln Findings pro Tenant, Geschäftsbereich und Schutzklasse als nachweisfähige Belege.