Bug-Bounty-Prämienstufen, denen Forscher wirklich vertrauen

Damit Forscher Ihren Bug-Bounty-Prämienstufen vertrauen, brauchen Sie vier Dinge: Ordnen Sie Schweregrade einem Scoring-Modell zu (CVSS oder einem kontextspezifischen Modell), verankern Sie jede Stufe mit Benchmark-Daten als Min-Max-Spanne statt mit einer einzigen Zahl, veröffentlichen und fixieren Sie Tabelle und Geltungsbereich, damit sich nach einer Meldung nichts mehr klammheimlich ändert, und reservieren Sie Geld für echte Wirkung, während Sie Arbeit mit geringer Wirkung in einer separaten Spur würdigen. Was Vertrauen zerstört, ist nicht zu wenig zu zahlen. Es ist die Neubewertung abgeschlossener Arbeit, nachdem ein Forscher bereits gemeldet, der Fehler behoben und die Anerkennung nach den alten Zahlen vergeben wurde.

Diese Unterscheidung ist die ganze Geschichte des ersten Halbjahres 2026. Im Mai legte HackerOne die Axt an das Internet Bug Bounty (IBB), kürzte die Prämien über sämtliche Schweregrade hinweg – und ein Großteil der Empörung entzündete sich am Zeitpunkt, nicht an der Höhe. Wenn Sie ein Programm zur Schwachstellenoffenlegung (VDP) oder ein junges Bug-Bounty betreiben und zusehen, wie sich KI-generierte Meldungen in Ihrem Posteingang stapeln, plagen Sie zwei Ängste zugleich: im Müll zu versinken und Zahlen festzulegen, die Sie später kürzen müssen, womit Sie Ihren Ruf in der Forscher-Community ruinieren. Beide Ängste sind berechtigt. Nur eine davon löst sich durch das Kürzen von Prämien.

HackerOne kürzte Bug-Bounty-Prämien um bis zu 89 % – für Arbeit, die Forscher längst erledigt hatten

Im Mai 2026 senkte HackerOne die Prämienstufen des Internet Bug Bounty quer durch die Bank um rund 76 % bis 89 % und pausierte das Programm anschließend, während es weitere Anpassungen prüfte. Das IBB ist der gemeinsame Topf, aus dem Schwachstellen in zentralen Open-Source-Abhängigkeiten bezahlt werden; seit 2012 wurden daraus mehr als 1,5 Mio. $ ausgeschüttet, mit einer 80/20-Aufteilung zwischen Entdeckung und Behebungsunterstützung (Quelle: InfoWorld / CSO).

Die Zahlen

Das waren keine Korrekturen am Rand. Hier die Stufentabelle alt gegen neu mit Stand vom 18. Mai 2026:

Quelle: The Register, 21. Mai 2026. Ein Fund mit mittlerem Schweregrad, der einst fast zweitausend Dollar wert war, bringt jetzt unter dreihundert. HackerOne stellt es so dar, dass das IBB „ein einzigartiges, dynamisches Programm ist, bei dem sich die Prämienhöhen automatisch an die Beiträge der aktiv teilnehmenden Sponsoren anpassen“. Zur Rolle der KI erklärte das Unternehmen: „KI-gestützte Forschung weitet die Schwachstellenentdeckung über das gesamte Ökosystem aus und erhöht sowohl Abdeckung als auch Tempo. Das Gleichgewicht zwischen Funden und Behebungskapazität im Open-Source-Bereich hat sich grundlegend verschoben.“

Warum es um Vertrauen geht, nicht ums Budget

Ein Programm darf pleitegehen. Ein Programm darf entscheiden, dass eine Stufe zu hoch angesetzt war. Worauf die Forscher reagierten, war, dass die Änderung auf bereits abgeschlossene Arbeit angewandt wurde. Der Sicherheitsforscher Jakub Ciolek brachte es so auf den Punkt: „Das Vertrauensproblem hier ist, dass die Änderung faktisch lange nach Abschluss der Arbeit angewandt wurde, die längst erledigt, deren Fehler behoben und die unter einer anderen Erwartung bereits öffentlich gewürdigt worden war“ (Quelle: The Register).

Ein Forscher erhielt eine Auszahlung von 297 $ gegenüber einer weit höheren ursprünglichen Erwartung. Ciolek selbst wartete noch auf die Zahlung für Argo-CD-Schwachstellen, die er im Herbst 2025 gemeldet hatte, als die neuen Stufen kamen. Seine Diagnose der Gesamtlage ist die These dieses ganzen Artikels: „Die gesenkte Auszahlung ist ein Symptom. Die Ökonomie des Schwachstellen-Meldens verändert sich sehr schnell.“ Die Lehre lautet nicht hört auf zu zahlen. Sie lautet ändert die Regeln nach vorn, nicht rückwirkend.

Der eigentliche Druck: KI hat nicht die Fehlerqualität gesenkt, sondern die Meldungsmenge erhöht

Die ehrliche Lesart von 2026 lautet: Der Druck durch KI-Spam ist real und belegt, doch das dauerhafte Problem ist die Menge, nicht die KI an sich. Programme gehen nicht unter, weil KI schlechte Bugs schreibt. Sie gehen unter, weil KI viele Meldungen schreibt – und eine plausible, aber erfundene zu widerlegen, kostet einen erfahrenen Entwickler echte Zeit.

Das Hin und Her bei curl: Programm einstampfen, dann zurückholen

curl ist der sauberste dokumentierte Fall, und er schneidet in beide Richtungen. Maintainer Daniel Stenberg legte das Programm zum Februar 2026 still und begründete: „Die derzeitige Flut an Einreichungen belastet das curl-Sicherheitsteam stark, und dies ist ein Versuch, das Rauschen zu reduzieren“ (Quelle: The Register, 21. Jan. 2026). Jahrelang hatten KI-gestützte Einreichungen bei curl in der Spam-Ära praktisch nichts Echtes zutage gefördert.

Dann kippte der Trend. Im März 2026 kehrte curl zu HackerOne zurück, weil die Qualität der KI-Meldungen so weit gestiegen war, dass „so gut wie alle“ der nun brauchbaren Meldungen KI-gestützt waren – obwohl sich das reine Volumen im Jahresvergleich etwa verdoppelt hatte (Quelle: The New Stack). Die Erkenntnis: KI ist nicht für immer der Feind der Meldungsqualität. Die dauerhafte Veränderung ist das Volumen. Ihre Prämienstruktur muss einen vollen Posteingang aushalten, ohne genau die Forscher zu bestrafen, die echte Bugs liefern.

GitHubs leiserer Zug: Swag statt Geld für Bugs mit geringer Wirkung

Am 15. Mai 2026 kündigte GitHub an, dass gültige Funde mit geringer Wirkung Anerkennung statt einer Auszahlung erhalten: „Einreichungen, die keine erhebliche Sicherheitswirkung belegen, aber zu einer Code- oder Dokumentationskorrektur führen, werden mit GitHub-Swag statt mit einer Prämienauszahlung gewürdigt.“ Die Begründung war unmissverständlich: „Uns ist es lieber, wenn Forscher ihre Zeit in tiefere Forschung mit hoher Wirkung investieren und entsprechend vergütet werden, als wenn sie auf Masse bei risikoarmen Funden optimieren“ (Quelle: GitHub Blog).

Das ist derselbe wirtschaftliche Instinkt wie bei der IBB-Kürzung: Geld für Wirkung reservieren, den Anreiz zur Masse dämpfen. Doch es kam ganz anders an – und der Unterschied ist die ganze Sache.

Wie „gut“ aussieht: der Unterschied zwischen GitHub und dem IBB

Der konstruktive und der umstrittene Schritt ähneln sich mechanisch. Beide reduzieren, was Arbeit mit geringer Wirkung einbringt. Die Trennlinie sind Zeitpunkt und Vorankündigung.

GitHub änderte die Regeln mit Wirkung für die Zukunft und veröffentlichte die Begründung, bevor irgendjemand unter den neuen Bedingungen einreichte. Wer heute meldet, weiß, dass ein Fund auf dem Niveau einer Dokumentationskorrektur Swag bringt, nicht Geld – und lässt sich mit diesem Wissen darauf ein. Die IBB-Kürzung traf Arbeit, die bereits gemeldet und gewürdigt worden war, nach den alten Zahlen. Dieselbe Richtung, das entgegengesetzte Vertrauensergebnis.

Das ist keine neue Lehre. Bereits 2020 kündigte Bountysource per stiller Änderung der Nutzungsbedingungen an, nicht eingeforderte Prämien „einzubehalten“, machte das nach dem Aufschrei rückgängig und musste mitansehen, wie Projekte wie elementary OS Beiträge mit dem Titel „Goodbye, Bountysource“ veröffentlichten. Rückwirkende Änderungen an einer Prämienvereinbarung sind der Inbegriff des Vertrauensbruchs. Die Krypto-Bug-Bounty-Plattform Immunefi hat das Gegenprinzip in einem Beitrag mit dem Titel „The Bug Bounty Program Is Law“ auf den Punkt gebracht: Die veröffentlichte Programmseite ist bindend, und ein Projekt kann eine bereits danach eingereichte Meldung nicht rückwirkend neu verhandeln.

Die Erwartung bei der Einreichung muss der Erwartung bei der Auszahlung entsprechen. Alles andere ist verhandelbar. Das eine nicht.

Im Kern geht es im folgenden Rahmenwerk also gar nicht um Zahlen. Es geht darum, Ihre veröffentlichten Bedingungen strukturell so zu gestalten, dass sie einen Forscher im Nachhinein gar nicht hintergehen können.

So legen Sie Bug-Bounty-Prämienstufen fest, die dem KI-Spam standhalten

Legen Sie Stufen in vier Schritten fest: Verankern Sie sie in Daten, veröffentlichen und fixieren Sie sie, machen Sie jede Auszahlung nachprüfbar, und belohnen Sie Aufwand mit Anerkennung statt mit einer heimlichen Kürzung. Nichts davon erfordert ein Budget in HackerOne-Größe. Es erfordert Disziplin – und genau die trennt ein Programm, dem Forscher vertrauen, von der nächsten Negativschlagzeile.

Schritt 1: Stufen in Daten verankern, nicht im Bauchgefühl

Beginnen Sie damit, Schweregrade einem Scoring-Modell zuzuordnen, damit „kritisch“ jedes Mal dasselbe bedeutet. CVSS ist die übliche Wahl; ein kontextspezifisches Modell funktioniert, wenn Ihre Assets nicht sauber zu CVSS passen. Bepreisen Sie dann jede Stufe anhand realer Verteilungsdaten statt anhand einer geratenen runden Zahl.

Zwei Anker zählen:

• Externe Benchmarks, besonders zu Beginn. Microsofts veröffentlichte Prämientabellen reichen von 500 $ bis 30.000 $ für Anwendungen und On-Prem sowie von 1.250 $ bis 19.500 $ für M365, mit einer Rekordsumme von 17 Mio. $, die 2024 bis 2025 ausgezahlt wurde (Quelle: MSRC). Bei HackerOne liegt die durchschnittliche jährliche Auszahlung pro aktivem Programm bei rund 42.000 $, und die Plattform zahlte im zurückliegenden Jahr insgesamt 81 Mio. $ aus, ein Plus von 13 % (Quelle: BleepingComputer). Eine verbreitete Faustregel der Branche besagt, dass Organisationen bereit sind, mehr als 7.000 $ für eine kritische Schwachstelle zu zahlen – einen allgemeingültigen Standard gibt es nicht.
• Ihre eigene Historie, sobald Sie eine haben. Median, Mittelwert, Minimum und Maximum dessen, was Sie pro Schweregrad und pro Schwachstellentyp tatsächlich gezahlt haben, zeigen Ihnen, wo die echte Verteilung liegt – so bepreisen Sie die nächste Stufe anhand von Belegen, statt quer durch die Bank zu kürzen.

Verwenden Sie Stufen mit Spannen (ein Min und ein Max pro Schweregrad), nicht eine einzige brüchige Zahl. Spannen erlauben es Ihnen, einen außergewöhnlichen kritischen Fund am oberen und einen grenzwertigen am unteren Rand des Bandes zu belohnen, ohne die Tabelle neu zu schreiben. Das ist die Praxis, die sowohl Intigriti als auch die Bug Bounty Community of Interest empfehlen – und genau das fehlt pauschalen Kürzungen wie der des IBB.

Schritt 2: Bedingungen und Geltungsbereich veröffentlichen und fixieren

Schreiben Sie die Prämienmatrix, die Assets innerhalb und außerhalb des Geltungsbereichs, die ausgeschlossenen Schwachstellentypen, Ihre SLA-Zusagen und Ihre Safe-Harbor-Formulierung in eine einzige veröffentlichte Richtlinie. Versionieren Sie sie dann und behandeln Sie die Version, der ein Forscher bei der Einreichung zugestimmt hat, für diese Meldung als bindend.

Das ist die strukturelle Antwort auf die Kritik am IBB. Wenn die Bedingungen zum Einreichungszeitpunkt veröffentlicht und fixiert sind, gibt es keinen Mechanismus, über den abgeschlossene Arbeit klammheimlich neu bewertet wird. Der Forscher lässt sich auf einen bekannten Deal ein. Wenn Sie den Deal ändern wollen, ändern Sie ihn für künftige Einreichungen und kündigen es an – nach dem Vorbild von GitHub.

Schritt 3: Jede Auszahlung nachprüfbar machen

Jede Prämie und jede Anpassung sollte ein ausdrückliches, protokolliertes und belegbares Ereignis mit Zeitstempel und Begründung sein. Ein nachprüfbares Finanzhauptbuch leistet zweierlei. Es beweist einem Forscher, dass der erhaltene Betrag zur zugesagten Stufe passt. Und in dem seltenen Fall, dass Sie eine Prämie wirklich anpassen, zeigt es, dass die Anpassung eine bewusste, festgehaltene Entscheidung war und keine undurchsichtige automatische Neuberechnung.

Die IBB-Formel von den „automatisch angepassten Prämienhöhen“ ist genau das, was ein Finanzhauptbuch verhindert. Automatisch und unsichtbar untergräbt Vertrauen. Bewusst und protokolliert bewahrt es – selbst wenn sich die Zahl ändert.

Schritt 4: Aufwand mit Anerkennung belohnen, nicht mit einer heimlichen Kürzung

Gültige Funde mit geringer Wirkung verdienen Anerkennung. Der richtige Weg, sie zu geben, ist eine separate, zusätzliche Anerkennungsspur: Reputations- oder Karma-Punkte, Swag, ein Hall-of-Fame-Eintrag. Der falsche Weg ist, eine Geldkürzung als „Anerkennung“ zu verkleiden – bei Arbeit, die hätte bezahlt werden sollen.

GitHubs Swag-für-geringe-Wirkung-Richtlinie ist die saubere Variante, weil sie im Voraus angekündigt wird und parallel zum Geld für Bugs mit hoher Wirkung läuft – nie als Ersatz für zugesagtes Geld bei bereits eingereichter Arbeit. Anerkennung ergänzt Ihre fixierten Geldstufen. Sie ist niemals eine Hintertür zur Neubewertung.

So setzen Sie das in Kit um

Das CSIRT-Toolset von Kit ist genau um diese vier Gewohnheiten herum gebaut, und das ist der springende Punkt: Die Disziplin wird vom Werkzeug erzwungen, nicht den guten Vorsätzen überlassen. Um ehrlich zu sein: Kit ist ein junges Produkt zur Programmverwaltung, kein Marktplatz mit dem Auszahlungsvolumen oder dem Benchmark-Datensatz von HackerOne. Der Unterschied liegt in der Struktur, die es vorgibt – und diese Struktur macht den Großteil dessen aus, worauf Vertrauen am Ende beruht.

• Benchmark-verankerte Stufen. Aggregieren Sie Ihre eigenen vergangenen Prämien (Median, Mittelwert, Min, Max, jüngste Beispiele), gefiltert nach Schweregrad und Schwachstellentyp, damit Sie jede Stufe anhand realer Verteilungsdaten bepreisen und einem Forscher den Median für seine Bug-Klasse zeigen können. Neue Programme starten mit externen Benchmarks wie Microsofts veröffentlichten Bändern, bis sie eine eigene Historie haben.
• Veröffentlichte Stufen mit Spannen. Konfigurieren Sie die Prämienmatrix als Min und Max pro Schweregrad über die Stufen Informativ, Niedrig, Mittel, Hoch, Kritisch und eine Super-kritisch-Stufe, und veröffentlichen Sie sie zusammen mit Geltungsbereich, SLA und Safe-Harbor-Bedingungen als versionierte Richtlinie, der Forscher bei der Einreichung zustimmen.
• Ein nachprüfbares Finanzhauptbuch. Jede Freigabe, jede Anpassung und jede Auszahlung ist ein typisiertes, protokolliertes Finanzereignis, filterbar nach Meldung und Datum – so passt die Auszahlung zur Zusage, und jede Anpassung ist eine festgehaltene Entscheidung, keine stille Neuberechnung.
• Eine separate Karma-Spur. Nicht-monetäre Anerkennung läuft parallel zu den fixierten Geldstufen mit festen, transparenten Vorgaben, damit ein gültiger Fund mit geringer Wirkung gewürdigt wird, ohne dass jemand eine Geldkürzung als Dankeschön tarnt.

Wie man ein Programm am Leben hält, wenn der Posteingang überläuft, haben wir ausführlich im VDP-Sichtungs-Playbook behandelt, und wie man eines von null aufbaut, in So richten Sie ein Programm zur Schwachstellenoffenlegung ein. Dieser Artikel ist die Ebene des Prämiendesigns, die auf beiden aufsetzt.

FAQ

Darf ein Bug-Bounty-Programm Prämien nach der Einreichung ändern?

Es kann, aber es sollte nicht. Der Aufschrei um das IBB im Mai 2026 wurde weniger durch die Höhe der Kürzung ausgelöst als durch die Tatsache, dass sie für Arbeit galt, die bereits gemeldet, behoben und nach den alten Stufen gewürdigt worden war. Das verteidigbare Muster, das GitHub vorgemacht hat, ist, Prämien nur mit Wirkung für die Zukunft zu ändern, mit veröffentlichter Ankündigung, damit Forscher sich wissentlich auf die neuen Bedingungen einlassen. Behandeln Sie Ihre veröffentlichte Programmseite als bindend für jede danach eingereichte Meldung.

Wie viel sollte ich für einen kritischen Bug-Bounty zahlen?

Es gibt keinen allgemeingültigen Standard; es ist eine Risikoabwägung. Als grobe Orientierung: Microsoft zahlt bis zu 30.000 $ für Spitzenfunde bei Anwendungen, das durchschnittliche HackerOne-Programm zahlt über alle Stufen rund 42.000 $ pro Jahr, und eine verbreitete Faustregel lässt Organisationen mehr als 7.000 $ für eine kritische Schwachstelle zahlen (Quellen: MSRC; BleepingComputer). Legen Sie eine Min-Max-Spanne pro Schweregrad fest, verankert an diesen Benchmarks und Ihrer eigenen Historie, statt einer einzigen festen Zahl.

Wie gehe ich mit KI-generierten Bug-Bounty-Meldungen um?

Kürzen Sie keine Prämien, um sie abzuschrecken; das bestraft die Forscher, die echte Bugs liefern. Das dauerhafte Problem ist die Menge, nicht die KI. curl hat bewiesen, dass die Qualität von KI-Meldungen binnen eines Jahres von wertlos zu „so gut wie alle brauchbar“ umschlagen kann. Bewältigen Sie die Menge mit Sichtung (Filtern, Rate Limiting, Reputations-Scoring, SLA-Schutz) und das Prämiendesign, indem Sie für Wirkung zahlen und Arbeit mit geringer Wirkung separat würdigen – so belohnt der Anreiz Qualität statt Einreichungszahl.

Das Fazit

Wenn KI Ihren Posteingang flutet, ist der Reflex, das Budget zu schützen, indem Sie kürzen, was Sie zahlen. Das IBB zeigt, wohin das führt, wenn die Kürzung abgeschlossene Arbeit trifft: ein Glaubwürdigkeitsloch, das kein Geldbetrag schnell wieder auffüllt. Die dauerhafte Antwort ist strukturell. Verankern Sie Ihre Stufen in realen Daten, veröffentlichen und fixieren Sie Bedingungen und Geltungsbereich, protokollieren Sie jede Auszahlung, damit Anpassungen bewusst und sichtbar sind, und belohnen Sie Aufwand mit Anerkennung, die neben dem Geld steht, statt es zu ersetzen. Tun Sie das, und Ihr VDP bleibt glaubwürdig, wenn die KI-Flut kommt, statt zur nächsten Negativschlagzeile zu werden.

Wenn Sie eine Prämienmatrix entwerfen, die Sie heute veröffentlichen und in sechs Monaten nicht bereuen wollen, starten Sie eine kostenlose Kit-Testphase und konfigurieren Sie von Anfang an ein benchmark-gestütztes, fixiertes und nachprüfbares Programm.