Nach dem Audit: Findings priorisieren und tatsächlich fixen

Der Pentest-Report liegt auf dem Tisch. 47 Findings, davon 3 Critical, 12 High, 18 Medium, 14 Low. Die Security-Verantwortlichen (CISO oder vergleichbare Rolle) wollen einen Remediation-Plan bis Freitag. Das Dev-Team stöhnt. Und in drei Monaten findet der Re-Test dieselben Probleme. Warum passiert das – und wie verhindern Sie es?

Ein Audit ist kein Erfolg, wenn der Report fertig ist. Ein Audit ist ein Erfolg, wenn die Findings gefixt sind.

Warum Findings versanden

Ich habe Organisationen gesehen, die denselben Pentest-Report drei Jahre in Folge bekommen haben. Nicht weil sie inkompetent waren, sondern weil der Prozess nach dem Audit nicht funktioniert hat.

Die typischen Gründe:

• Keine klare Ownership: „Das ist ein Security-Thema" – aber Security kann keine Code-Changes machen
• Unrealistische Deadlines: „Alle Criticals in 2 Wochen" – bei einem Team, das im Sprint ist
• CVSS-Blindheit: Alles nach Score priorisieren, ohne Business-Kontext
• Kein Tracking: Findings verschwinden in Jira-Backlogs und werden nie wieder gesehen
• Fehlende Eskalation: Wenn nichts passiert, passiert auch nichts

Der erste Tag nach dem Report

Sie haben den Report bekommen. Was jetzt?

Schritt 1: Findings verstehen, nicht nur zählen

Bevor Sie priorisieren, müssen Sie verstehen. Lesen Sie jeden Finding. Nicht die Executive Summary – die einzelnen Findings.

Für jedes Finding klären:

• Was genau ist das Problem? (Nicht „SQL Injection", sondern „SQL Injection im Login-Formular über den username-Parameter")
• Ist der Finding reproduzierbar? (Manchmal sind Pentest-Findings False Positives)
• Welches System/welcher Code ist betroffen?
• Gibt es bereits einen Fix in der Pipeline? (Manchmal wurde das Problem schon gefunden)

Schritt 2: Findings-Review mit dem Team

Holen Sie die relevanten Entwickler dazu. Nicht als Anklage („Ihr habt das verbockt"), sondern als Arbeitssitzung:

• Stimmt der Finding? Verstehen wir, was der Auditor meint?
• Wie aufwändig ist der Fix? (T-Shirt-Sizing: S/M/L/XL)
• Gibt es Abhängigkeiten? (Muss erst X gefixt werden, bevor Y möglich ist?)
• Wer kennt den Code am besten?

Das Ziel: Jeder Finding hat nach diesem Meeting einen vorläufigen Owner und eine Aufwandsschätzung.

Priorisierung: CVSS ist nicht genug

Der Auditor hat jedem Finding einen CVSS-Score gegeben. Critical, High, Medium, Low. Das ist ein Ausgangspunkt – aber kein Priorisierungsschema.

Warum CVSS allein nicht funktioniert

CVSS (Common Vulnerability Scoring System) bewertet die technische Schwere einer Schwachstelle. Was CVSS nicht berücksichtigt:

• Business-Kontext: Eine SQL Injection im Admin-Panel (hinter VPN, 3 Benutzer) ist anders als eine im öffentlichen Login
• Ausnutzbarkeit in Ihrer Umgebung: Gibt es kompensierende Kontrollen?
• Daten-Sensitivität: Was kann ein Angreifer mit Zugriff erreichen?
• Reputationsrisiko: Manche Schwachstellen sind PR-Desaster, andere nicht

Ein pragmatisches Priorisierungsmodell

Kombinieren Sie CVSS mit Business-Kontext. Beispielhafte Gewichtung – anpassbar je nach Organisation und Risikoappetit:

Faktor	Fragen	Gewichtung
CVSS-Score	Wie schwer ist die Schwachstelle technisch?	30%
Erreichbarkeit	Internet-exponiert? Authentifizierung nötig? Hinter VPN?	25%
Daten-Impact	PII? Zahlungsdaten? Geschäftsgeheimnisse? Öffentliche Daten?	25%
Fix-Aufwand	Quick Win oder mehrwöchiges Refactoring?	10%
Exploit-Verfügbarkeit	Gibt es öffentliche Exploits? Wird aktiv ausgenutzt?	10%

Priorisierungs-Matrix in der Praxis

# Beispiel: Finding-Priorisierung

FINDING: SQL Injection im Login-Formular
CVSS: 9.8 (Critical)
Erreichbarkeit: Internet-exponiert, keine Auth nötig
Daten-Impact: Zugriff auf User-Datenbank (PII, Passwort-Hashes)
Fix-Aufwand: S (Prepared Statements einführen)
Exploit: Trivial, Standard-Tools

→ PRIORITÄT: P0 (Sofort)

---

FINDING: XXE in XML-Import (Admin-Bereich)
CVSS: 9.1 (Critical)
Erreichbarkeit: Nur für Admins (5 Personen), hinter VPN
Daten-Impact: Potentiell Server-Dateien lesbar
Fix-Aufwand: S (XML-Parser konfigurieren)
Exploit: Benötigt Admin-Zugang

→ PRIORITÄT: P1 (Diese Woche)

---

FINDING: Reflected XSS in Suchergebnissen
CVSS: 6.1 (Medium)
Erreichbarkeit: Internet-exponiert
Daten-Impact: Session Hijacking möglich (User-Sessions)
Fix-Aufwand: S (Output Encoding)
Exploit: Einfach, aber Social Engineering nötig

→ PRIORITÄT: P1 (Diese Woche)

---

FINDING: Missing Security Headers
CVSS: 5.3 (Medium)
Erreichbarkeit: Alle Seiten
Daten-Impact: Indirekt (Clickjacking, MIME-Sniffing)
Fix-Aufwand: XS (Webserver-Config)
Exploit: Theoretisch, praktisch selten

→ PRIORITÄT: P2 (Diesen Monat)

Remediation-Tracking: Das System

Priorisierung ist nutzlos ohne Tracking. Sie brauchen ein System, das:

• Jeden Finding einem Owner zuordnet
• Deadlines trackt
• Status-Updates erzwingt
• Eskalation ermöglicht

Option 1: Dediziertes Vulnerability-Management-Tool

Tools wie DefectDojo, Nucleus, Vulcan oder ThreadFix sind dafür gebaut. Vorteile:

• Import von Audit-Reports (oft automatisch)
• Deduplizierung (dasselbe Problem in mehreren Scans)
• Trend-Tracking über Zeit
• Integration mit CI/CD

Nachteil: Ein weiteres Tool. Wenn Ihr Team Jira lebt und atmet, wird ein separates Tool ignoriert.

Option 2: Jira/Linear mit Struktur

Wenn Sie Jira nutzen, können Sie Findings dort tracken – aber mit Disziplin:

# Jira-Ticket-Template für Security Findings

[SEC-XXX] SQL Injection in Login-Formular

## Finding
- **Quelle:** Pentest Report Q4/2025, Finding #17
- **CVSS:** 9.8 (Critical)
- **Priorität:** P0
- **Deadline:** 2025-11-08

## Beschreibung
[Exakte Beschreibung aus dem Report, ggf. mit Screenshot]

## Betroffene Komponente
- Repository: backend-auth
- Datei: src/auth/LoginController.java:142
- Endpoint: POST /api/v1/login

## Reproduktion
[Curl-Beispiel oder Burp-Request aus dem Report]

## Empfohlener Fix
[Aus dem Report oder eigene Einschätzung]

## Akzeptanzkriterien
- [ ] Fix implementiert
- [ ] Code Review durchgeführt
- [ ] Fix in Staging verifiziert
- [ ] Re-Test durch Security bestätigt

## Labels
security, pentest-2025-q4, priority-p0

Governance-Regel: Security-Findings dürfen kein normales Backlog-Item sein – sie brauchen eigene Sichtbarkeit und WIP-Limits.

Status-Tracking

Definieren Sie klare Status:

Status	Bedeutung	Verantwortung
New	Finding erfasst, noch nicht analysiert	Security
Triaged	Analysiert, priorisiert, Owner zugewiesen	Security
In Progress	Fix wird entwickelt	Dev-Team
Ready for Retest	Fix deployed, wartet auf Verifikation	Dev-Team
Verified	Re-Test bestätigt Fix	Security/Auditor
Risk Accepted	Bewusst akzeptiert (dokumentiert!)	Management
False Positive	Kein echtes Problem (dokumentiert warum)	Security

Risk Acceptance: Wann Sie nicht fixen

Nicht jedes Finding muss sofort gefixt werden. Manchmal ist Risk Acceptance die richtige Entscheidung – aber nur wenn sie bewusst und dokumentiert ist.

Legitime Gründe für Risk Acceptance

• System wird abgeschaltet: Das Legacy-System geht in 3 Monaten offline
• Kompensierende Kontrollen: Andere Maßnahmen reduzieren das Risiko ausreichend
• Unverhältnismäßiger Aufwand: Fix würde 6 Monate dauern, Risiko ist begrenzt
• False Positive: Der Finding ist technisch korrekt, aber praktisch nicht ausnutzbar

Risk Acceptance dokumentieren

# Risk Acceptance Form

## Finding
XXE Vulnerability in Legacy XML Import (Finding #23)

## CVSS Score
9.1 (Critical)

## Risikobewertung nach Business-Kontext
- Nur für 5 Admin-Benutzer zugänglich
- Zugang erfordert VPN + MFA
- System wird am 31.01.2026 abgeschaltet
- Keine neuen Daten-Importe geplant

## Kompensierende Kontrollen
- Admin-Aktivitäten werden geloggt
- Admins wurden über Risiko informiert
- File Upload ist auf 1MB begrenzt

## Entscheidung
Risiko akzeptiert bis System-Abschaltung

## Verantwortlich
Name: [CISO/CTO Name]
Datum: 2025-11-05
Gültig bis: 2026-01-31

## Review
Automatischer Review am: 2026-01-15

Pushback: Wenn der Finding falsch ist

Auditoren sind nicht unfehlbar. Manchmal ist ein Finding:

• False Positive: Tool hat falsch erkannt
• Missverstanden: Auditor hat Kontext nicht verstanden
• Übertrieben: Severity zu hoch angesetzt
• Bereits gefixt: Wurde zwischen Scan und Report behoben

Wie Sie pushbacken

Professionell, mit Evidenz:

## Finding #17: Outdated jQuery Version

### Auditor Statement
jQuery 3.4.1 is used, which has known vulnerabilities (CVE-2020-11022).
CVSS: 6.1 (Medium)

### Our Response
We acknowledge the finding. However, we believe the severity should
be reduced to Low (Informational) for the following reasons:

1. **CVE-2020-11022 requires specific conditions:**
   - Untrusted HTML must be passed to jQuery DOM manipulation methods
   - Our code review confirms we never pass user input to these methods
   - All user input is sanitized through DOMPurify before rendering

2. **Evidence:**
   - Code audit results: [Link to internal report]
   - Grep results showing no vulnerable patterns: [Attachment]

3. **Upgrade timeline:**
   - jQuery upgrade is planned for Q1/2026 as part of frontend refactoring
   - Earlier upgrade would require significant regression testing

### Requested Action
Re-classify as Low/Informational, with note that upgrade is planned.

### Supporting Documentation
- [Link to code review]
- [Link to DOMPurify configuration]
- [Link to roadmap showing jQuery upgrade]

Deadlines: Realistisch planen

Die typische Management-Erwartung: „Alle Criticals in einer Woche." Die Realität: Das Team ist im Sprint, hat andere Deadlines, und der Fix ist komplexer als gedacht.

Realistische Timeframes

Priorität	Typische Deadline	Begründung
P0	24-72 Stunden	Aktiv ausgenutzt oder trivial exploitbar, Internet-exponiert
P1	1-2 Wochen	Critical/High mit hohem Business-Impact
P2	30 Tage	High/Medium, begrenzte Ausnutzbarkeit
P3	90 Tage	Medium/Low, Defense-in-Depth
P4	Next Release	Low/Informational, Best Practice

Wenn Deadlines nicht halten

Deadlines werden gerissen. Das ist normal. Was nicht normal sein sollte:

• Stille Deadline-Verletzungen ohne Kommunikation
• Keine Eskalation bei Blockern
• „Wir hatten keine Zeit" ohne vorherige Warnung

Etablieren Sie einen Eskalationspfad:

Deadline in Gefahr?
       ↓
Owner informiert Security (min. 3 Tage vorher)
       ↓
Gemeinsame Bewertung: Ist Verzögerung akzeptabel?
       ↓
  Ja → Neue Deadline + Begründung dokumentieren
  Nein → Eskalation an Management für Ressourcen/Priorisierung

Re-Test: Nicht vergessen

Ein Finding ist erst geschlossen, wenn der Fix verifiziert ist. Nicht wenn der Code gemerged wurde. Nicht wenn das Ticket auf „Done" steht.

Re-Test-Optionen

• Auditor Re-Test: Der ursprüngliche Auditor prüft den Fix (oft im Audit-Vertrag enthalten)
• Interner Re-Test: Ihr Security-Team verifiziert (schneller, aber weniger unabhängig)
• Automatisierter Re-Test: CI/CD-Integration von Security-Scans (für bekannte Patterns)

Re-Test dokumentieren

## Re-Test Report: Finding #17 (SQL Injection)

**Original Finding:** SQL Injection in Login-Formular
**Fix:** Prepared Statements implementiert (PR #4521)
**Re-Test Date:** 2025-11-12
**Tester:** [Name]

### Test Methodology
1. Original Payload aus Report getestet
2. Variationen mit SQLMap
3. Manual Testing mit Burp Suite

### Results
- Original Payload: ✅ Blocked
- SQLMap: ✅ No injection points found
- Manual Testing: ✅ Input properly sanitized

### Evidence
[Screenshots/Logs attached]

### Conclusion
Finding #17: VERIFIED FIXED

### Notes
- Error messages are now generic (no SQL errors exposed)
- Logging captures injection attempts

Continuous Improvement: Nicht nur fixen, lernen

Ein Audit sollte nicht nur Probleme aufdecken, sondern auch Muster. Nach dem Remediation-Zyklus:

Root Cause Analysis

Fragen Sie bei jedem Critical/High:

• Wie ist das entstanden? (Zeitdruck? Wissenslücke? Fehlende Review-Prozesse?)
• Warum wurde es nicht früher gefunden? (Fehlende Tests? Kein SAST? Code Review übersehen?)
• Wie verhindern wir Wiederholung? (Training? Tooling? Prozessänderung?)

Muster erkennen

# Audit-Analyse Q4/2025

## Finding-Kategorien
- SQL Injection: 3 (alle im Legacy-Modul X)
- XSS: 7 (verteilt über Frontend)
- Missing Auth: 2 (API-Endpoints)
- Misconfig: 5 (Server-Hardening)

## Muster erkannt
1. Legacy-Modul X hat keine Input-Validierung → Refactoring nötig
2. Frontend-Team kennt Output-Encoding nicht → Training planen
3. Neue API-Endpoints vergessen Auth-Check → Code-Review-Checklist erweitern

## Maßnahmen
1. SAST-Rule für SQL Injection in CI/CD (verhindert neue Fälle)
2. Frontend-Security-Workshop buchen
3. API-Review-Template um Auth-Check erweitern

Kommunikation: Stakeholder mitnehmen

Security-Findings sind nicht nur ein Dev-Thema. Management will wissen: Wie schlimm ist es? Wird es besser?

Executive Summary Template

## Security Audit Remediation Status
Report: Pentest Q4/2025
Stand: 2025-11-15

### Übersicht
| Severity | Total | Fixed | In Progress | Open | Risk Accepted |
|----------|-------|-------|-------------|------|---------------|
| Critical | 3     | 2     | 1           | 0    | 0             |
| High     | 12    | 8     | 3           | 1    | 0             |
| Medium   | 18    | 10    | 5           | 2    | 1             |
| Low      | 14    | 5     | 2           | 4    | 3             |

### Critical/High Status Detail
1. SQL Injection (P0) - ✅ Fixed, verified 2025-11-10
2. XXE Vulnerability (P0) - ✅ Fixed, retest pending
3. Auth Bypass (P0) - 🔄 In Progress, ETA 2025-11-18
4. [weitere...]

### Blockers
- Finding #23 wartet auf Vendor-Patch (ETA unbekannt)
- Finding #31 benötigt Architektur-Entscheidung (Meeting 2025-11-20)

### Next Steps
- Re-Test für alle P0/P1 Findings: 2025-11-22
- Abschluss-Report: 2025-11-25

Kommunikationsrhythmus

• Täglich: P0-Updates an CISO (wenn P0 offen)
• Wöchentlich: Status-Update an Stakeholder
• Nach Re-Test: Abschluss-Report mit Lessons Learned

Tooling: Was wirklich hilft

Vulnerability Management

• DefectDojo (Open Source) – Finding-Aggregation, Deduplizierung, Tracking
• Nucleus – Enterprise-Grade, gute Integrationen
• Jira + Automation – Wenn alle sowieso in Jira arbeiten

Automatisierung für Re-Tests

• Nuclei – Custom Templates für spezifische Findings
• OWASP ZAP – Automatisierte Re-Scans
• CI/CD-Integration – SAST/DAST bei jedem Commit

# Beispiel: Nuclei Template für Re-Test

id: sqli-login-retest
info:
  name: SQL Injection Login Form Retest
  author: internal-security
  severity: critical
  reference:
    - pentest-q4-2025-finding-17

requests:
  - method: POST
    path:
      - "{{BaseURL}}/api/v1/login"
    body: 'username=admin%27%20OR%201%3D1--&password=test'
    matchers:
      - type: word
        words:
          - "SQL syntax"
          - "mysql_fetch"
          - "ORA-"
        negative: true  # Should NOT match if fixed

Fazit

Ein Audit-Report ist kein Abschluss – er ist der Anfang der eigentlichen Arbeit. Der Unterschied zwischen Organisationen, die sicherer werden, und solchen, die dieselben Findings Jahr für Jahr bekommen:

• Ownership: Jedes Finding hat einen Namen, nicht nur ein Team
• Priorisierung: Business-Kontext schlägt CVSS-Scores
• Tracking: Sichtbar, mit Eskalation, nicht im Backlog versteckt
• Verifikation: Re-Test ist nicht optional
• Lernen: Root Cause Analysis, nicht nur Symptombehandlung

Das Ziel ist nicht, den Audit zu bestehen. Das Ziel ist, sicherer zu werden. Der Audit ist nur das Messinstrument.

---