Ein Bug-Bounty-Programm belohnt externe Sicherheitsforscher dafür, Schwachstellen verantwortungsvoll zu melden – fortlaufend und erfolgsbasiert statt in einem festen Prüfzeitraum.
Ein Bug-Bounty-Programm ist eine dauerhafte Einladung an externe Sicherheitsforscher, Schwachstellen in definierten Systemen zu suchen und verantwortungsvoll zu melden. Für gültige, reproduzierbare Befunde zahlt die Organisation eine Prämie, deren Höhe sich nach dem Schweregrad richtet. Anders als ein Penetrationstest, der in einem festen Zeitfenster von einem beauftragten Team durchgeführt wird, läuft ein Bug-Bounty-Programm fortlaufend und steht grundsätzlich vielen Forschern offen – erfolgsbasiert bezahlt wird nur, wer tatsächlich etwas findet.
Programme werden entweder öffentlich oder privat (nur auf Einladung) betrieben, häufig über spezialisierte Plattformen, die Meldungen bündeln, Dubletten filtern und die Auszahlung abwickeln.
Aufbau eines Programms
- Scope: Welche Domänen, Anwendungen und Systeme sind eingeschlossen und welche ausdrücklich ausgenommen. Ein präziser Scope verhindert Tests an unbeteiligten Systemen.
- Regeln: Erlaubte und verbotene Vorgehensweisen, etwa das Verbot von Denial-of-Service oder von Tests mit echten Kundendaten – vergleichbar mit den Rules of Engagement eines Tests.
- Prämienstaffel: Beträge nach Schweregrad, meist orientiert an CVSS, von kleinen Beträgen für niedrige Befunde bis zu hohen Summen für kritische.
- Safe Harbor: Eine Zusicherung, dass die Organisation gegen Forscher, die sich an die Regeln halten, nicht rechtlich vorgeht – in Deutschland relevant wegen des Hackerparagrafen (§ 202a ff. StGB).
- Triage: Eingehende Meldungen werden auf Gültigkeit, Schweregrad und Dubletten geprüft, bevor eine Prämie ausgezahlt wird.
Grundlage jeder Meldung ist ein belastbarer Proof of Concept, der die Ausnutzbarkeit nachvollziehbar belegt.
Bedeutung für Unternehmen
Ein Bug-Bounty-Programm ergänzt Penetrationstests und Scans, ersetzt sie aber nicht. Seine Stärke ist die fortlaufende Prüfung mit vielen Perspektiven: Es findet Schwachstellen, die zwischen zwei Prüfterminen entstehen, und deckt kreative Angriffswege auf, auf die ein einzelnes Team nicht kommt. Seine Schwäche ist die Steuerbarkeit – es prüft nicht systematisch die gesamte Angriffsfläche, sondern das, was Forscher attraktiv finden, und es liefert keine Aussage über Erkennung und Reaktion. Diese Frage beantwortet nur ein Red Teaming.
Ein typischer Fehler ist, ein Programm zu starten, ohne die interne Kapazität für Triage und Behebung zu haben. Wer gemeldete Schwachstellen nicht zeitnah behebt, bezahlt für Erkenntnisse, die ungenutzt bleiben, und verliert die Glaubwürdigkeit bei den Forschern. Ein zweiter Fehler ist ein zu enger oder unklarer Scope, der mehr Streit über Zuständigkeit als verwertbare Befunde erzeugt.
Praxis-Hinweise
- Starten Sie privat und auf Einladung, bevor Sie ein Programm öffnen; so lernen Sie Ihre Triage-Kapazität realistisch kennen.
- Formulieren Sie eine klare Safe-Harbor-Erklärung – ohne sie schrecken Sie in Deutschland seriöse Forscher ab.
- Richten Sie zusätzlich einen einfachen Meldeweg (security.txt, Kontaktadresse) ein, damit auch Hinweise außerhalb des Programms Sie erreichen.
- Behandeln Sie das Programm als Ergänzung: Für systematische Tiefe nutzen Sie Pentests, für Erkennung und Reaktion Red Teaming.