Warum Security-Audits scheitern, obwohl alles dokumentiert ist

Der 200-seitige Audit-Bericht liegt vor. 47 Findings, sauber kategorisiert nach CVSS-Score. Drei Monate später: 43 davon sind immer noch offen. Nicht weil sie unlösbar wären – sondern weil der Bericht in einem SharePoint-Ordner versauert, den niemand mehr öffnet. Ich sehe das in fast jedem Unternehmen, das mich nach einem gescheiterten Audit hinzuzieht.

Das Muster: Audit als Checkbox

Die meisten Security-Audits folgen dem gleichen Ablauf:

1. Compliance oder Kunde verlangt Audit
2. Externer Dienstleister wird beauftragt
3. Pentester finden Schwachstellen (sie finden immer welche)
4. Bericht wird übergeben
5. Management nickt ab
6. Entwickler bekommen eine Liste mit 50+ Findings
7. Niemand hat Zeit, weil das Sprint-Backlog voll ist
8. Nächstes Jahr: Repeat

Das ist kein Audit. Das ist Security-Theater.

Im Ernstfall haftet nicht der Auditor – sondern das Unternehmen.

Die 5 Gründe, warum Audits scheitern

1. Kein Owner für Findings

Ein Finding ohne Owner ist ein Finding, das nie gefixt wird. So einfach ist das.

In klassischen Audit-Berichten steht: „SQL Injection in /api/search – Risiko: Hoch". Was fehlt:

• Wer ist verantwortlich?
• Bis wann muss es gefixt sein?
• Was passiert, wenn die Deadline verstreicht?

Ohne Antworten auf diese Fragen ist das Finding eine Notiz, keine Aufgabe.

2. Der Bericht ist für die falschen Leser

Ein typischer Audit-Bericht enthält:

• Executive Summary (2 Seiten, liest das Management)
• Technische Details (150 Seiten, liest niemand)
• Appendix mit Screenshots (50 Seiten, beweist, dass gearbeitet wurde)

Was fehlt: Eine Übersetzung in Arbeitspakete für die Teams, die es fixen müssen.

Audit-Bericht sagt	Entwickler braucht
„Reflected XSS in Parameter q"	Ticket mit Repro-Steps, betroffener Datei, Kontext
„Missing Security Headers"	Nginx-Config-Snippet, das funktioniert
„Insecure Deserialization"	Welche Library? Welche Version fixt es?
„Weak Password Policy"	Business-Entscheidung, nicht Dev-Task

Wenn der Entwickler den Bericht lesen muss wie einen Roman, um zu verstehen, was zu tun ist – dann ist der Bericht das Problem.

3. Zu viele Findings, keine Priorisierung

50 Findings klingt nach gründlicher Arbeit. In Wahrheit ist es oft das Gegenteil: Der Auditor hat alles aufgeschrieben, was der Scanner ausgespuckt hat, ohne zu filtern.

Das Ergebnis: Paralyse. Wenn alles wichtig ist, ist nichts wichtig.

4. Audit als Event, nicht als Prozess

Ein jährlicher Audit ist wie ein jährlicher Gesundheitscheck: Besser als nichts, aber kein Ersatz für tägliche Hygiene.

Security-Audits funktionieren, wenn sie Teil eines kontinuierlichen Prozesses sind:

• Vor dem Audit: Threat Modeling, Security-Requirements in User Stories
• Während der Entwicklung: SAST/DAST in der Pipeline, Code-Reviews mit Security-Fokus
• Nach dem Audit: Findings als Tickets, Tracking bis zum Fix, Retest
• Kontinuierlich: Vulnerability Management, Dependency Updates

Ohne diesen Rahmen ist der Audit ein Snapshot eines Problems, das sich täglich verändert.

5. Falsches Timing

Der klassische Fehler: Audit zwei Wochen vor Go-Live. Alles ist fertig, der Release-Druck ist maximal – und dann kommt der Bericht mit 30 kritischen Findings.

Was passiert? Entweder wird trotzdem released („Wir fixen das im nächsten Sprint"), oder das Go-Live wird verschoben und alle sind frustriert.

Was stattdessen funktioniert

Findings als erstklassige Tickets

Jedes Finding wird ein Ticket im Backlog des zuständigen Teams. Nicht in einem separaten Security-Backlog, das niemand ansieht – im echten Backlog, wo die Arbeit passiert.

// Beispiel: JIRA-Ticket für Security-Finding

Titel: [SEC-HIGH] SQL Injection in /api/v2/search
Priorität: Blocker
Assignee: @backend-team-lead
Due Date: 2025-03-15

Beschreibung:
Der Parameter `q` wird ungefiltert in SQL-Query eingebaut.
Siehe Audit-Report Seite 42, Finding #7.

Repro:
curl -X GET "https://api.example.com/v2/search?q='; DROP TABLE users;--"

Fix:
- Prepared Statement verwenden
- Input-Validierung (alphanumerisch + Leerzeichen)

Akzeptanzkriterien:
- [ ] Fix implementiert
- [ ] Unit-Test für Injection-Versuch
- [ ] Retest durch Security-Team bestätigt

Explizite Risk Acceptance

Nicht jedes Finding muss gefixt werden. Manche Risiken sind akzeptabel – aber diese Entscheidung muss dokumentiert und von jemandem mit Befugnis getroffen werden.

// Risk Acceptance Template

Finding: Weak TLS Configuration (TLS 1.0/1.1 supported)
Risiko: Medium
Empfehlung: TLS 1.0/1.1 deaktivieren

Entscheidung: AKZEPTIERT
Begründung: Legacy-Client (SAP-Integration) unterstützt nur TLS 1.1.
             Migration auf TLS 1.2 erst in Q4 möglich.
Kompensationsmaßnahme: IP-Whitelist für Legacy-Client
Genehmigt von: CTO, 2025-03-01
Review-Datum: 2025-09-01

Ohne dokumentierte Risk Acceptance ist „wir fixen das später" keine Entscheidung – es ist Verdrängung.

Security Champions im Team

Ein zentrales Security-Team, das alle Findings bearbeitet, skaliert nicht. Was funktioniert: Security Champions in jedem Entwicklungsteam.

• Entwickler mit Security-Interesse und -Training
• Erste Anlaufstelle für Security-Fragen im Team
• Verantwortlich für Findings im eigenen Bereich
• Regelmäßiger Austausch mit zentralem Security-Team

Retest als Standard

Ein Finding ist erst geschlossen, wenn es retestet wurde. Klingt selbstverständlich – wird aber selten gemacht.

Warum? Weil Retest im Original-Audit meist nicht enthalten ist. Der Auditor liefert den Bericht und ist raus. Der Fix wird implementiert, aber ob er wirkt, prüft niemand.

Wie Sie einen Audit richtig beauftragen

Scope definieren

„Testen Sie alles" ist kein Scope. Je klarer der Scope, desto wertvoller die Ergebnisse:

• Welche Systeme? (URLs, IP-Ranges, Apps)
• Welche Angreiferprofile? (Extern, authentifiziert, Insider)
• Welche Methoden? (Automatisiert, manuell, Social Engineering)
• Was ist explizit ausgeschlossen?

Deliverables vereinbaren

Bestehen Sie auf mehr als einen PDF-Bericht:

• Executive Summary: Für Management und Stakeholder
• Technische Findings: Mit Repro-Steps und Fix-Empfehlungen
• Ticket-Export: CSV/JSON zum Import ins Ticketsystem
• Debrief-Session: Live-Walkthrough mit den Entwicklern
• Retest: Mindestens für kritische Findings

Timing planen

Phase	Audit-Typ	Ziel
Architektur	Threat Modeling, Design Review	Strukturelle Schwächen früh finden
Entwicklung	Code Review (stichprobenartig)	Security-Patterns etablieren
Pre-Release	Pentest (4-6 Wochen vor Go-Live)	Zeit für Fixes haben
Produktion	Regelmäßige Scans, Red Team	Kontinuierliche Überprüfung

Metriken, die zählen

„Wir hatten 47 Findings" ist keine Metrik. Das hier sind Metriken:

• Mean Time to Remediate (MTTR): Wie lange von Finding bis Fix?
• Finding Recurrence Rate: Wie viele Findings tauchen im nächsten Audit wieder auf?
• Fix Verification Rate: Wie viele Fixes wurden retestet?
• Accepted Risk Ratio: Wie viel Prozent der Findings sind bewusst akzeptiert?
• Age of Open Findings: Wie alt sind die ältesten offenen Findings?

Fazit

Ein Security-Audit ist kein Gütesiegel. Er ist ein Werkzeug – und wie jedes Werkzeug ist er nur so gut wie die Hand, die ihn führt.

Audits scheitern nicht an der Technik. Sie scheitern an:

• Fehlender Ownership: Findings ohne Verantwortliche bleiben offen
• Falschen Erwartungen: Ein Bericht allein ändert nichts
• Schlechtem Timing: Zu spät im Prozess für echte Fixes
• Fehlender Integration: Security als Event statt als Prozess

Die gute Nachricht: All das lässt sich ändern. Nicht durch mehr Budget für Audits, sondern durch bessere Prozesse drumherum.

Häufige Fragen

Wie oft sollten wir einen Security-Audit machen?

Mindestens jährlich für kritische Systeme, plus bei jeder größeren Änderung. Continuous Security Testing (SAST/DAST in der Pipeline) ergänzt, ersetzt aber nicht den manuellen Audit.

Was kostet ein guter Security-Audit?

Für eine mittelgroße Webanwendung: 10.000–30.000 EUR für einen gründlichen Pentest mit Bericht und Debrief. Billiger ist möglich, aber dann bekommen Sie oft nur automatisierte Scanner-Ergebnisse mit Logo drauf.

Pentest oder Code Review – was ist besser?

Beides. Pentests finden, was von außen angreifbar ist. Code Reviews finden strukturelle Probleme, die beim Pentest nicht sichtbar sind. Die Kombination ist am wertvollsten.

Was tun, wenn das Budget für Fixes fehlt?

Dann haben Sie ein Priorisierungsproblem, kein Budget-Problem. Kritische Findings müssen gefixt werden – das ist nicht verhandelbar. Alles andere ist Risk Acceptance mit offenen Augen.

---