01Die drei Zielgruppen
Ein guter Pentest-Report spricht gleichzeitig drei verschiedene Zielgruppen an. Jede braucht andere Informationen, andere Sprache und anderen Detailgrad. Der groesste Fehler ist, einen Report zu schreiben der nur fuer eine Gruppe funktioniert.
⚙️
Technische Stakeholder
70–90% des Reports
Entwickler, Sysadmins, DevOps. Sie muessen die Schwachstellen verstehen, reproduzieren und beheben. Brauchen: Root Cause, exakte Schritte, Code-Beispiele, Payloads, Patches.
🛡️
Security Stakeholder
10–20% des Reports
SOC, CISO, Security Engineers. Koordinieren die Remediation, priorisieren Risiken, erkennen Angriffsketten. Brauchen: Findings & Recommendations, Attack Chains, Themen-Cluster.
💼
Business Stakeholder
5–10% des Reports
Management, CEO, Projektleiter. Sie genehmigen Budget fuer Remediation. Brauchen: Business Impact in Klartext, keine Fachbegriffe, klare Handlungsempfehlung.
💡
Merksatz: Security muss Business ermoeglichen, nicht dagegen arbeiten. Der Report ist das Werkzeug das beide Seiten zusammenbringt. Wenn das Management den Report nicht versteht, werden Budgets fuer Fixes nicht bewilligt.
02Die drei Haupt-Sektionen
Jeder professionelle Pentest-Report besteht aus drei Pflicht-Sektionen. Ihre Reihenfolge ist nicht zufaellig: vom grossen Ueberblick bis zum technischen Detail.
| Sektion |
Zielgruppe |
Inhalt & Zweck |
| 📊 Summary |
Business & Security |
High-Level-Uebersicht: Was wurde getestet, was gefunden, warum es wichtig ist — in Businesssprache. Kein Fachkauderwelsch, keine CVE-Nummern. |
| 🔍 Vulnerability Write-Ups |
Technische Stakeholder |
Das technische Herzstuck. Jede Schwachstelle bekommt einen eigenen Eintrag mit Reproduktionsschritten, Evidence und konkreten Fix-Anweisungen. |
| 📎 Appendices |
Security Stakeholder |
Audit-Trail, Scope-Abdeckung, hinterlassene Artefakte, Methodik-Details. Grundlage fuer Folge-Assessments und Remediation-Tracking. |
⚠️
Reihenfolge beim Schreiben: Schreibe die Summary immer zuletzt. Ohne die Write-Ups fertig zu haben, kannst du das Gesamtbild nicht akkurat zusammenfassen. Summary ist die Destillation aller anderen Sektionen.
03Summary Section
Die Summary ist die erste Sektion die jeder liest und oft die einzige die das Management komplett durcharbeitet. Sie muss vier Fragen ohne technisches Vorwissen beantworten:
01
Was wurde getestet?
Systeme, Scope, Art des Assessments (Black/Grey/White Box), Zeitraum, eingesetzte Methodik.
02
Was wurde gefunden?
Kategorien der Schwachstellen, Gesamtanzahl nach Schweregrad. Kein technisches Detail hier.
03
Was bedeutet das fuer das Business?
Realer Impact wenn die Issues nicht behoben werden. Beispiel: Datenverlust, Compliance-Verletzung, Reputationsschaden, finanzieller Schaden.
04
Was soll als naechstes passieren?
High-Level Remediation Direction: Sind es Quick-Wins oder braucht es grosse Investitionen? Priorisierung der naechsten Schritte.
📄 Executive Summary vs. Findings & Recommendations
Bei groesseren Engagements oder wenn Business- und Security-Stakeholder klar getrennt sind, wird die Summary in zwei Teile aufgeteilt:
👔
Executive Summary
Fuer CEO, Management, Auftraggeber. Nur Business-Sprache. Kein CVSS, keine CVE-IDs, keine technischen Details. Fokus: Business Risk und ROI der Remediation.
🧠
Findings & Recommendations
Fuer CISO, Security Team. Zeigt Angriffsketten (Attack Chains): Wie kombinieren sich Low-Risk-Findings zu High-Impact-Szenarien? Systemische Probleme und Priorisierung.
✅
Attack Chain Beispiel: Ein Low-Finding (Information Disclosure) + ein Medium-Finding (IDOR) koennen in Kombination einen Critical-Impact haben. Die Findings & Recommendations-Sektion ist der Ort wo du das hervorhebst — nicht die Einzel-Write-Ups.
04Vulnerability Write-Ups
Die groesste und wichtigste Sektion des Reports. Jede gefundene Schwachstelle bekommt einen eigenen, strukturierten Write-Up. Diese Sektion wird hauptsaechlich von den Entwicklern und Admins gelesen die den Fix implementieren muessen.
🎯
Goldene Regel: Jede Remediation-Empfehlung muss die Root Cause der Schwachstelle adressieren, nicht nur die Symptome mitigieren. Beispiel: Input-Sanitization allein loest kein SQL-Injection-Problem. Parameterized Queries sind die korrekte Loesung.
🧱 Pflicht-Struktur jedes Write-Ups
📌
Title
Kurz, praezise, beschreibend. Beinhaltet die Schwachstellen-Art und den Fundort.
Beispiel: "Unauthenticated SQL Injection in /login via username Parameter"
⚠️
Risk Rating
Schwachstellen immer isoliert bewerten — als ob keine anderen Schwachstellen existieren. Verwende CVSS oder die Risk-Matrix des Kunden. Nie den kombinierten Impact hier einfliessen lassen.
Systeme: CVSS v3.1, CVSS v4.0, OWASP Risk Rating Methodology
📝
Summary
Kurze Erklaerung der Schwachstelle und ihres Impacts in Klarsprache. Auch fuer Nicht-Techniker verstaendlich.
📚
Background
Kontext und Erklaerung der Schwachstellen-Klasse. Denke daran: Der Entwickler der den Fix implementiert ist kein Security-Experte. Erklaere die Root Cause verstaendlich.
Wichtig bei komplexen Schwachstellen wie Race Conditions, Deserialization, XXE — wo der Fixer den Mechanismus verstehen muss.
🔍
Technical Details & Evidence
Wo und wie die Schwachstelle gefunden wurde. Beinhaltet: HTTP-Requests und Responses, verwendete Payloads, Screenshots, Code-Snippets, Burp Suite Output, Tool-Output.
Sei spezifisch: Exakter Endpoint, Parameter, Workflow-Schritt, benoetigte Credentials/Rolle.
💥
Impact
Was koennte ein realer Angreifer mit dieser Schwachstelle tun — spezifisch auf das getestete System bezogen. Nicht generisch! Kontextualisiere auf die Umgebung.
Beispiel: Statt "Cookie Theft" → pruefe ob die App ueberhaupt Cookies nutzt oder Tokens. Impact muss zur konkreten Implementierung passen.
🔧
Remediation Advice
Konkrete, umsetzbare Schritte die die Root Cause beheben. Tech-Stack-spezifisch wenn bekannt. Erste Empfehlung muss die Schwachstelle vollstaendig eliminieren, nicht nur mitigieren.
Zeige Code-Beispiele in der Sprache des Projekts. Defence-in-Depth-Massnahmen als Zusatz kennzeichnen, nicht als alleinige Loesung.
🔗
References (optional)
Links zu Vendor-Dokumentation, OWASP-Guides, CVE-Eintragen, relevanten Standards die den Fix unterstuetzen.
🧵 Der Golden Thread
✨ Was ist der Golden Thread?
Ein professioneller Write-Up hat einen roten Faden der sich durch alle Sektionen zieht: Der Leser versteht nach dem Lesen ohne explizite Abschnittstitel was die Schwachstelle ist, wo sie liegt, warum sie gefaehrlich ist und was zu tun ist. Bei erfahrenen Reportern wird dieser Fluss so natuerlich dass die starren Abschnitts-Ueberschriften wegfallen koennen. Allerdings: Wenn der Report in Vulnerability-Management-Software importiert wird, sind diskrete Felder oft trotzdem vorzuziehen. Immer an die Beduerfnisse des Kunden anpassen.
🖥️ Beispiel: SQL Injection Write-Up Struktur
POST /login HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
username=' OR 1=1--&password=anyvalue
# Response:
HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: sessionid=abc123; HttpOnly
// FALSCH: User-Input direkt in Query
string query = "SELECT * FROM Users WHERE Username = '" + input + "'";
// RICHTIG: Parameterized Query
string query = "SELECT * FROM Users WHERE Username = @username";
SqlCommand cmd = new SqlCommand(query, connection);
cmd.Parameters.AddWithValue("@username", inputUsername);
// Input ist jetzt von Command strikt getrennt
📌
Kontext-Regel: Der Report darf sich nie wie ein Lehrbuch-Template anfuehlen. Beantworte immer: Wo genau? Welche Voraussetzungen? Wie betrifft es diesen Kunden spezifisch (Hospital, E-Commerce, Bank)?
05Risikobewertung
Jede Schwachstelle erhaelt ein Risk Rating. Dieses Rating muss in Isolation vergeben werden — als ob keine anderen Schwachstellen im System existieren. Kombinierte Angriffsketten werden in der Findings & Recommendations Sektion adressiert, nicht hier.
📊 Standard-Schweregrade
Critical
High
Medium
Low
Informational
| Schweregrad | Kriterien | Typische Beispiele |
|---|
| Critical |
Direkte RCE, vollstaendige System-Kompromittierung ohne Authentifizierung moeglich. |
Unauthenticated RCE, SQL Injection mit DB-Admin-Rechten, Pre-Auth Deserialization. |
| High |
Signifikanter Impact auf Vertraulichkeit, Integritaet oder Verfuegbarkeit. Oft mit geringem Aufwand ausnutzbar. |
Auth Bypass, Stored XSS in Admin-Panel, SSRF mit internem Netzwerk-Zugriff, IDOR auf sensible Daten. |
| Medium |
Moderater Impact, erfordert haeufig Benutzer-Interaktion oder besondere Umstaende. |
Reflected XSS, CSRF auf kritischen Aktionen, Open Redirect, Race Condition mit eingeschraenktem Impact. |
| Low |
Geringer direkter Impact. Oft hilfreiche Information fuer weitergehende Angriffe. |
Verbose Error Messages, Missing Security Headers, Information Disclosure (nicht-sensitiv). |
| Informational |
Kein direktes Sicherheitsrisiko. Best-Practice-Empfehlungen oder Security-Hygiene. |
Fehlende HSTS, schwache TLS-Konfiguration, veraltete Software-Versionen ohne bekannte Exploits. |
⚠️
CVSS Hinweis: CVSS-Scores sind ein guter Ausgangspunkt, aber sie beruecksichtigen nicht immer den spezifischen Kontext des Kunden. Ein Low-CVSS-Finding kann in einer kritischen Infrastruktur High-Impact haben. Nutze CVSS als Basis und passe an den Kontext an.
06Appendices
Die Appendices sind der Audit-Trail des Engagements. Sie richten sich hauptsaechlich an Security Stakeholder die langfristig mit dem Report arbeiten — fuer Remediation-Tracking, Folge-Assessments und Compliance-Nachweise.
📎
Denke an die Appendices als Beweismittel: Sie zeigen deine Arbeit, begruenden deine Findings und ermoeglichen informierte Nachfolge-Schritte, auch wenn der initiale Pentest Jahre zurueckliegt.
📍 Appendix A: Assessment Scope
Zeigt wie nah das Assessment am urspruenglich definierten Scope aus dem Rules of Engagement (RoE) Dokument war. Veraenderungen und Luecken werden transparent dokumentiert.
✓
Definierter vs. erreichter Scope
Was war im Scope? Was konnte getestet werden? Was musste ausgelassen werden und warum (technische Blockade, Zeitlimit, RoE-Einschraenkung)?
✓
Coverage-Prozentsatz
Wenn nur 80% des Scopes abgedeckt wurden, braucht der Kunde einen klaren Hinweis dass die restlichen 20% in einem Folge-Assessment geprueft werden muessen.
✓
Scope-Aenderungen
Alle waehrend des Engagements vorgenommenen Scope-Erweiterungen oder -Einschraenkungen werden hier mit Datum und Begruendung dokumentiert.
🧹 Appendix B: Assessment Artefacts
Listet alle waehrend des Tests hinterlassenen Artefakte auf. Dies ist kritisch: Nicht beraeumte Test-Artefakte koennen Jahre spaeter als echte Security-Incidents behandelt werden.
🚨
Real-World Beispiel: Ein Pentester laedt eine Webshell hoch um eine Unrestricted File Upload Schwachstelle zu beweisen, raeumt sie aber nicht auf. Zwei Jahre spaeter findet ein Security-Analyst die Datei und loest einen vollstaendigen Incident-Response-Prozess aus. Das kostet Zeit, Geld und Vertrauen.
🗄️
Liste aller hinterlassenen Dateien
Webshells, Test-Accounts, Exploit-Skripte, temporaere Dateien, erstellte Registry-Keys, Cron-Jobs etc. Mit genauem Pfad und Dateinamen.
🧹
Cleanup-Anweisungen
Fuer jedes Artefakt: Wie genau soll es entfernt werden? Welche Artefakte sind potenziell gefaehrlich und muessen priorisiert entfernt werden?
📝
Weitere optionale Appendices
Eingesetzte Methodik (PTES, OWASP WSTG etc.), Tool-Liste, Timeline des Engagements, verwendete Signaturen/Regeln, Netzwerk-Logs fuer forensische Nachvollziehbarkeit.
07Workflow & Profi-Tipps
Die optimale Reihenfolge fuer die Report-Erstellung und Best Practices aus der Praxis.
1
Waehrend des Engagements
Notes & Evidence sammeln
Alle Requests, Responses, Screenshots, Payloads und Tool-Outputs sofort sichern. Nicht darauf verlassen dass du dich nach dem Engagement erinnerst. Ein gutes Note-Taking-System (Obsidian, CherryTree, Notion) ist Pflicht.
2
Nach dem Testing
Vulnerability Write-Ups erstellen
Beginne mit den technischen Write-Ups. Das ist der groesste Zeitaufwand. Jede Schwachstelle vollstaendig dokumentieren bevor zur naechsten gewechselt wird.
3
Nach den Write-Ups
Appendices zusammenstellen
Scope-Abdeckung finalisieren, Artefakt-Liste erstellen, Methodik-Details erganzen. Sicherstellen dass der Cleanup vollstaendig dokumentiert ist.
4
Zuletzt schreiben
Summary & Executive Summary
Erst wenn alle Write-Ups und Appendices fertig sind, kannst du das Gesamtbild akkurat zusammenfassen. Identifiziere Attack Chains fuer die Findings & Recommendations.
5
Vor Abgabe
Quality Review
Eigene Daten aus dem Report entfernen, auf Copy-Paste-Fehler aus anderen Reports pruefen, alle Links testen, Screenshots auf Lesbarkeit pruefen. Lass idealerweise eine zweite Person gegenlesen.
🏆
Profi-Tipp: Ein Report der sich nicht wie eine Textbuch-Kopie oder ein anderer Kunden-Report anfuehlt ist das Ziel. Kontextualisiere jede Schwachstelle auf das spezifische System. Ein Krankenhaus-Pentest-Report klingt anders als ein E-Commerce-Report — auch wenn dieselben Schwachstellen gefunden wurden.
08Komplette Checkliste
Verwende diese Checkliste vor der Abgabe jedes Pentest-Reports.
📊 Summary
▸Overview: Was wurde getestet, Systemtyp, Assessment-Ziele, Scope-Coverage beschrieben
▸Results: Gefundene Schwachstellen-Kategorien und Schweregrade zusammengefasst
▸Impact: Realer Business-Impact in Klarsprache ohne Fachjargon
▸Remediation Direction: Naechste Schritte fuer das Management klar formuliert
▸Attack Chains: Kombinierte Schwachstellen-Ketten in Findings & Recommendations dokumentiert
🔍 Vulnerability Write-Ups
▸Title: Beschreibt Schwachstellen-Art und Fundort spezifisch
▸Risk Rating: In Isolation vergeben, CVSS oder Kunden-Matrix verwendet
▸Background: Root Cause erklaert, auch fuer Nicht-Security-Experten verstaendlich
▸Evidence: Requests, Responses, Payloads, Screenshots vorhanden
▸Impact: Auf das spezifische System kontextualisiert, nicht generisch
▸Remediation: Adressiert Root Cause, tech-stack-spezifisch, erste Empfehlung loest das Problem vollstaendig
▸Golden Thread: Leser kann ohne explizite Abschnitts-Ueberschriften dem Write-Up folgen
📎 Appendices
▸Scope Coverage: Erreichter vs. definierter Scope dokumentiert mit Begruendung fuer Luecken
▸Artefakt-Liste: Alle hinterlassenen Dateien, Accounts, Scripts mit Pfad gelistet
▸Cleanup-Anweisungen: Fuer jedes gefaehrliche Artefakt konkrete Entfernungs-Schritte
▸Methodik: Verwendete Frameworks und Standards dokumentiert
✓ Qualitaets-Check
▸Kein Copy-Paste aus anderen Reports oder Templates ohne Anpassung
▸Alle Screenshots lesbar und annotiert
▸Kein Kunden-Daten aus vorherigen Engagements im Report
▸Summary wurde zuletzt geschrieben
▸Report wurde von einer zweiten Person reviewt (Four-Eyes-Prinzip)
▸Remediation-Empfehlungen adressieren Root Cause, nicht nur Symptome