Warum Reporting den Unterschied macht
Pentester und Bug-Bounty-Hunter werden nicht für Funde bezahlt, sondern für geschlossene Schwachstellen. Der Report ist der Hebel zwischen "interessanter Fund" und "Fix in Produktion".
Im Job entscheidet die Qualitaet deiner Reports darueber, ob Entwicklerteams dich ernst nehmen und Auftraggeber dich erneut buchen.
Aufbau eines wirksamen Reports
Bewährte Struktur, die du auf fast jedes Engagement übertragen kannst:
- Executive Summary: Kontext, Scope, wichtigste Ergebnisse - eine Seite, für nicht-technische Leser.
- Methodik: kurz, damit Leser einordnen können, wie geprüft wurde.
- Findings: einzelne Schwachstellen, jeweils mit Severity, Reproduktion, Impact, Empfehlung.
- Anhang: Requests, Responses, Screenshots, Tool-Output.
Mini-Template für ein Finding
| Feld | Inhalt |
|---|---|
| Titel | Aussagekräftig, ohne Hype |
| Betroffenes Asset | URL, Endpunkt, Komponente |
| Severity | CVSS-Vector + kurze Geschäftseinschaetzung |
| Beschreibung | Was ist das Problem, technisch? |
| Reproduktion | Nummerierte Schritte, exakte Inputs |
| Impact | Was kann ein realistischer Angreifer erreichen? |
| Empfehlung | Kurz- und langfristige Mitigation |
| Belege | Requests, Responses, Screenshots |
Severity sauber begründen
CVSS liefert ein gemeinsames Vokabular über Attack Vector, Komplexität, benötigte Privilegien und Auswirkungen. Es bleibt aber generisch. Ergänze CVSS immer durch eine kurze Geschäftsbewertung: Welche Daten sind betroffen, welche Prozesse könnten ausfallen, welche regulatorischen Pflichten entstehen?
Im Bug-Bounty-Kontext orientieren sich Auszahlungen typischerweise an CVSS plus Programm-spezifischen Faktoren.
Typische Missverständnisse
- "Hauptsache, der Output ist drin" - rohe Tool-Ausgaben sind kein Report, sondern Material.
- "Je dramatischer, desto besser" - uebertriebene Behauptungen werden überprüft und kosten Glaubwürdigkeit.
- "Wenn das Team es nicht versteht, ist es deren Problem" - Verständlichkeit ist Teil deiner Arbeit.
- "Mitigation ist Sache der Entwickler" - eine kurze, technisch saubere Empfehlung zeigt Kompetenz.
Häufige Anfängerfehler
- Reproduktionsschritte sind nicht testbar - der Empfänger lehnt das Finding ab.
- Kein klarer Impact - "irgendwas geht" überzeugt niemanden.
- Identische Texte für ähnliche Findings, ohne kontextbezogene Anpassung.
- Falsche Severity, die später nach unten korrigiert wird - schlecht für Reputation.
Praxisbezug
Legale Übung: Löse eine Aufgabe auf der PortSwigger Web Security Academy und schreibe danach einen vollständigen Report mit allen Feldern aus dem Template oben. Überlege dabei, wie du den Inhalt auch jemandem ohne Security-Hintergrund erklären würdest.
Portfolio-Idee: Veröffentliche mehrere CTF- oder Lab-Reports in einem öffentlichen Repository. Sie zeigen Lernfortschritt und schriftliche Klarheit - beides sind harte Einstellungsargumente.
Legal-Hinweis
Reports dürfen Belege wie Requests, Responses und Screenshots enthalten, solange sie aus autorisierten Tests stammen. Reports zu nicht autorisierten Tests sind nicht nur ethisch problematisch, sondern auch rechtlich riskant - schon das Verfassen kann Bestandteil einer Straftat sein.
Nächste Lernschritte
FAQ
Warum ist Reporting so wichtig?
+
Eine Schwachstelle ist nur dann wertvoll, wenn sie reproduzierbar, verständlich und priorisiert beschrieben ist. Schlechte Reports werden ignoriert oder abgelehnt - egal wie spannend der Fund war.
Wie lang sollte ein Report sein?
+
So kurz wie möglich, so ausführlich wie nötig. Eine Executive Summary von einer Seite, technische Details so tief, dass das Team das Problem ohne Rückfrage reproduzieren und beheben kann.
Welche Felder gehören in jeden Befund?
+
Titel, betroffenes Asset, Severity (z. B. CVSS), Reproduktionsschritte, Impact, empfohlene Mitigation, Belege (Requests, Responses, Screenshots) und Verweise auf Standards (z. B. OWASP).
Wie schaetze ich Severity sinnvoll ein?
+
CVSS gibt ein gemeinsames Vokabular, ersetzt aber kein Geschäftsrisiko. Verbinde CVSS mit einer kurzen Einschaetzung des konkreten Geschäftsimpacts - das hilft Stakeholdern beim Priorisieren.
Wie vermeide ich uebertriebene Reports?
+
Beschreibe nur, was du belegen kannst. Keine Spekulationen über 'könnte zu Total-Kompromittierung führen', wenn der tatsaechliche Pfad nicht gezeigt wurde. Glaubwürdigkeit ist wichtiger als Drama.