Bug Bounty Programme aufbauen: Vom internen Prozess zur öffentlichen Plattform

Ein Bug Bounty Programm ist keine Marketing-Maßnahme - es ist ein strukturierter Prozess um externe Sicherheitsforscher zu incentivieren, Schwachstellen verantwortungsvoll zu melden. Unternehmen wie Google (Project Zero), Microsoft, Apple und Meta zahlen jährlich Millionen an Bounties. Der Gegenwert: kontinuierliche, motivierte Sicherheitstests durch tausende Spezialisten die keiner internen Bias unterliegen.

Bug Bounty vs. VDP vs. Pentest

Es gibt drei grundlegende Ansätze, die sich in Reife und Zweck unterscheiden:

VDP (Vulnerability Disclosure Program): Kein Geld, nur “Safe Harbor” - also rechtliche Absicherung für Forscher. Der Aufwand ist minimal: eine Seite security.txt nach RFC 9116 plus eine Kontaktadresse genügen als Signal, dass das Unternehmen bereit ist, Schwachstellen entgegenzunehmen. Wichtig: NIS2 schreibt einen strukturierten Disclosure-Prozess vor, weshalb ein VDP für viele Unternehmen Pflicht wird.

Private Bug Bounty: Eingeladene Forscher (10-50 ausgewählte Hacker) arbeiten in einer kontrollierten Umgebung mit klar definiertem Scope. Bezahlung erfolgt pro gefundener Schwachstelle nach CVSS/Impact. Ideal für Unternehmen, die noch kein internes Security-Team aufgebaut haben. Eine Laufzeit von 3-6 Monaten vor einem öffentlichen Launch ist empfehlenswert.

Öffentliches Bug Bounty: Offen für alle registrierten Forscher und damit mit höchster Reichweite - tausende Augen auf den Code. Dafür auch der höchste Aufwand: Triage rund um die Uhr, mehr Duplikate, mehr Noise. Sinnvoll erst, wenn VDP und Private Bug Bounty ausgereift sind. Voraussetzung ist ein dedizierter Security-Engineer für die Triage.

Im Vergleich zum Penetrationstest: Ein Pentest läuft über einen definierten Zeitraum mit dedizierten Testern und breitem Scope; Bug Bounty läuft kontinuierlich mit vielen Forschern und engem Scope. Die Synergie beider Ansätze ist ideal - CTEM nutzt Pentests für die Tiefe und Bug Bounty für die Breite.

Scope-Definition

Die Scope-Definition ist die kritischste Entscheidung eines Bug Bounty Programms.

In Scope sollten grundsätzlich produktive Web-Applikationen, öffentliche APIs, mobile Apps (iOS/Android, aktuelle Version im Store) sowie Authentifizierungssysteme (Login, MFA, OAuth-Flow) sein - also überall dort, wo Kundendaten liegen.

Explizit Out of Scope sind typischerweise:

Third-Party-Dienste (Salesforce, HubSpot, AWS-Infrastruktur)
Social Engineering (Phishing gegen Mitarbeiter)
Physischer Zugang (Bürogebäude, Rechenzentrum)
DoS/DDoS-Tests (auch wenn eine Schwachstelle vorhanden ist)
Automatisierte Massenscans (kein SQLMap gegen alle Endpunkte)
Spam / E-Mail-Flooding
Staging- und Dev-Umgebungen (sofern nicht explizit in Scope)

Bei der Scope-Definition gibt es drei Typen: Wildcard (*.firma.de - alle Subdomains, für den Start riskant), spezifische Angaben (app.firma.de, api.firma.de) sowie explizite Asset-Listen mit IPs, Domains und App-Bundle-IDs.

Die security.txt nach RFC 9116 ist für VDP Pflicht und wird unter .well-known/security.txt sowie /security.txt abgelegt:

Contact: mailto:security@firma.de
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://firma.de/pgp-key.txt
Preferred-Languages: de, en
Policy: https://firma.de/security/bugbounty
Scope: https://firma.de/security/scope

Rechtliche Safe-Harbor-Klausel - muss im Programm stehen:

AWARE7 garantiert, dass wir keine rechtlichen Schritte gegen Forscher einleiten, die im Einklang mit diesem Programm handeln. Wir stimmen es ab, keine Zivilklage wegen unbeabsichtigter Verletzungen zu erheben und keine strafrechtliche Anzeige zu erstatten, sofern der Forscher keine Kundendaten kopiert oder verändert hat, den Angriff sofort nach Entdeckung beendet hat und die Schwachstelle unverzüglich gemeldet hat.

Belohnungsstruktur

Die Bounty-Tabelle orientiert sich am CVSS-Score und am tatsächlichen Business Impact:

Schwere	CVSS	Bounty	Beispiele
Kritisch	9.0-10.0	€3.000-15.000	RCE ohne Auth, SQLi mit DB-Zugriff, Auth Bypass, Account Takeover
Hoch	7.0-8.9	€1.000-3.000	Stored XSS, IDOR mit Fremddaten, SSRF, Preismanipulation
Mittel	4.0-6.9	€200-1.000	Reflected XSS, CSRF, sensible Fehlermeldungen, Open Redirect
Niedrig	0.1-3.9	€50-200	Fehlende Security-Header, Best-Practice-Abweichungen, Rate Limiting ohne Impact
Informational	-	Acknowledgment	Bekannte öffentliche Schwachstellen, Theorie ohne Beweis, Out-of-Scope

Zusätzliche Bounty-Modifikatoren:

+25 % für den Erstentdecker (First Blood)
+10 % für sehr gute Reports mit PoC und Empfehlungen
-25 % für Reports ohne Reproduktionsschritte
×0 für Out-of-Scope, Duplikate und bekannte Issues

Zum Marktvergleich (HackerOne-Durchschnitt 2025): Web Critical Ø €4.500 (Google: bis €200k), Web High Ø €1.800, Mobile Critical Ø €6.000 (Apple: bis €250k), Krypto-Bugs Ø €20.000+ (DeFi-Programme).

Triage-Prozess

Der Ablauf vom Report bis zur Bounty-Auszahlung folgt einem klaren Schema: Report eingeht → Triage → Validierung → Priorisierung → Fix → Bounty.

Triage-SLAs (Best Practice):

Schritt	Ziel
First Response	< 24 Stunden (Eingangsbestätigung)
Triage Complete	< 5 Werktage (Schwere und Gültigkeit bestätigt)
Fix Kritisch	90 Tage
Fix Hoch	120 Tage
Fix Mittel	180 Tage
Bounty-Auszahlung	< 30 Tage nach Fix

Für jeden Report wird folgende Checkliste abgearbeitet:

Duplikat prüfen (interne DB, HackerOne Dedup)
In Scope? (Subdomain, Featureset)
Reproduzieren (eigene Test-Umgebung, NICHT Produktion)
CVSS-Score berechnen
Business Impact bewerten (nicht nur technischer CVSS)
Internes Ticket erstellen (Jira, Linear)
Entwicklungsteam eskalieren
Forscher updaten (auch Zwischenstatus)

Typische Triage-Entscheidungen nach Report-Typ:

“Missing rate limiting on /api/login”: Prüfen, wie viele Requests bis zum Block und ob CAPTCHA vorhanden ist. Oft Informational, wenn andere Schutzmaßnahmen greifen.
“Stored XSS in Kommentarfeld”: Entscheidend ist, wer den Kommentar sieht. Wenn Admin-Sessions gekapert werden können: sofort kritisch behandeln.
“IDOR: /api/users/{id} zeigt andere User-Daten”: Welche Daten? PII? Können Aktionen ausgeführt werden? Meist Hoch bis Kritisch wegen Datenschutzrelevanz.

Beim Duplikat-Management gilt: Das erste valide Report erhält die Bounty. Duplikate erhalten ein Acknowledgment. Beim Info-Sharing niemals Details nennen - nur “Ähnliches Issue wurde bereits behoben”.

Plattform-Wahl

Plattform	Stärken	Empfehlung
HackerOne	Größte Community (1,5M+ Hacker), Enterprise-Features, Launch-Unterstützung	Enterprise mit Budget
Bugcrowd	Managed Bug Bounty (Triage durch Bugcrowd-Team), kuratierte Forscher	Wenn kein dediziertes Sicherheitsteam
Intigriti	DSGVO-freundlich, EU-basierte Forscher, 80k+ Forscher	Europäische Unternehmen mit DSGVO-Fokus
YesWeHack	HDS/ISO 27001/DSGVO-konform, ~40k Forscher	Kritische Infrastrukturen, französische Unternehmen
Selbst-gehostet	Vollständige Kontrolle, keine Plattform-Gebühren	Nur bei sehr großen Security-Teams sinnvoll

Entscheidungsmatrix:

Startphase ohne BB-Team: Bugcrowd Managed
Startphase mit BB-Erfahrung: HackerOne Private
EU-Fokus und DSGVO-Anforderungen: Intigriti
Budget sehr begrenzt: VDP selbst mit security.txt
Enterprise mit Budget: HackerOne oder Bugcrowd Enterprise

Rechtliche Absicherung

In Deutschland stellt § 202a StGB (Ausspähen von Daten) eine Herausforderung dar: Forscher könnten sich strafbar machen, und eine Safe-Harbor-Klausel hebt das nicht automatisch auf - es gibt keine echte “Immunity”. Die Lösung liegt in einer klaren schriftlichen Einwilligung kombiniert mit enger Scope-Definition.

Empfohlene Formulierung für das Programm:

AWARE7 GmbH erteilt hiermit registrierten Bug-Bounty-Forschern die Erlaubnis, die unter scope.firma.de definierten Systeme zu testen. Diese Erlaubnis gilt ausschließlich für die genannten Systeme und die in den Programmregeln definierten Testmethoden. Alle anderen Aktivitäten sind nicht gestattet.

Zur DSGVO beim Bug Bounty: Forscher dürfen keine Echtdaten lesen, speichern oder exfiltrieren. Test-Accounts sollten angeboten werden, damit kein Kundendaten-Zugriff notwendig ist. Im Programm muss eine explizite Stopp-Pflicht bei Zugang zu echten Daten festgeschrieben sein. Wichtig: Bei DSGVO-Verstößen durch den Forscher greift der Safe Harbor nicht.

Das Report-Template muss folgende Pflichtbestandteile enthalten:

Betroffenes Asset (URL, App-Version)
Schwachstellentyp (OWASP/CWE-Kategorie)
Reproduktionsschritte (Schritt für Schritt)
Screenshot/Video als Beweis
Impact-Beschreibung (was kann ein Angreifer tun?)
Empfehlung zur Behebung (optional, aber Bonus)
Bestätigung: “Keine Kundendaten wurden abgerufen oder gespeichert”

Bug Bounty Metriken

Ein erfolgreiches Bug Bounty Programm wird anhand mehrerer KPI-Kategorien gemessen:

Forscher-Engagement:

Aktive Forscher pro Monat (Ziel: steigend)
Report-Eingang pro Monat
Signal/Noise-Ratio: valide Reports / Gesamt-Reports (Ziel: > 30 %)

Schwachstellen-Qualität:

Kritische Findings pro Quartal
CVSS-Durchschnitt aller Findings
Neue Schwachstellenklassen entdeckt (Diversität)

Reaktionszeit:

Mean Time to First Response (Ziel: < 24h)
Mean Time to Triage (Ziel: < 5 Tage)
Mean Time to Remediate nach Schwere

Finanzen:

Budget verbraucht / Budget geplant
Cost per Valid Report (Effizienz)
Kosten vs. alternative Pentest-Stunden

Forscher-Zufriedenheit:

HackerOne Signal Score / Programm-Reputation
Researcher-Satisfaction Rating
Repeat Researcher Rate (treue Forscher = höhere Qualität)

Als Benchmark: Google zahlte 2024 mehr als 12 Mio. USD aus, an über 700 Forscher, mit einer Höchstzahlung von 250.000 USD für einen Chrome-RCE. Das Google-Programm läuft seit 2010 und wächst kontinuierlich.

Ein Bug Bounty Programm ist kein Marketing-Tool - es ist ein nachhaltiger Sicherheitsmechanismus der kontinuierlich externe Perspektiven einbringt. AWARE7 unterstützt beim Aufbau von VDP und Bug Bounty Programmen: von der Scope-Definition über rechtliche Safe-Harbor-Klauseln bis zur Triage-Prozessgestaltung.

Bug Bounty Beratung anfragen | Penetrationstest als Alternative