Streit um Bug-Bounty-Auszahlungen entsteht, wenn ein Programm eine Prämie verweigert, kürzt oder verzögert, ohne die Entscheidung an eine Regel zu knüpfen, die der Forscher vorab hätte nachlesen können. Die häufigsten Auslöser: ein träger Fix ohne laufende Uhr, eine "Außerhalb des Geltungsbereichs"-Einstufung, die erst nach dem Patch fällt, eine Auszahlung unterhalb der beworbenen Matrix und nachträgliche Änderungen der Programmbedingungen. Die Lösung heißt nicht, mehr zu zahlen. Sie heißt: die Uhr und die Matrix vorab veröffentlichen, die Zeit bis zum Fix daran messen und jede Entscheidung zum Freigeben, Kürzen oder Ablehnen in einem prüfbaren Hauptbuch festhalten. Im Juni 2026 machte AMD aus einem kooperativen Forscher einen öffentlichen Kritiker, indem es alle vier Punkte auf einmal falsch machte. Dies ist das Drehbuch, um das nicht zu wiederholen. ## 124 Tage, dann "außerhalb des Geltungsbereichs": der Bounty-Streit bei AMD Im Februar 2026 meldete der Forscher Paul LaRosa (Handle "MrBruh") eine kritische Schwachstelle im Auto-Updater-Tooling von AMD. Der Updater holte seine Update-Liste über HTTPS, lud die eigentlichen ausführbaren Dateien aber über reines HTTP ohne echte Signaturprüfung herunter. Ein Angreifer im selben Netzwerk konnte einen Man-in-the-Middle-Angriff durchführen und Schadcode auf den Rechner des Opfers schieben. AMD brauchte **124 Tage**, bis ein Fix ausgeliefert war. Dann **verweigerte es die Prämie von 10.000 $** mit der Begründung, Man-in-the-Middle-Angriffe gegen "optionale Tools" lägen außerhalb des Geltungsbereichs. Und das, obwohl AMD eine CVE vergab (CVE-2026-40677, CVSS-4.0-Basiswert 7,7, HOCH) und LaRosa im eigenen Sicherheitsbulletin öffentlich nannte. Der schließlich ausgelieferte Patch fügte lediglich eine CRC32-Prüfung hinzu — eine Integritätsprüfsumme, keine kryptografische Signatur. Mehrere Medien berichteten zudem, AMD habe seine Programmbedingungen so überarbeitet, dass vor einer Offenlegung eine schriftliche Zustimmung erforderlich sei, und diese Änderung dann nachträglich auf LaRosas Fall angewendet. Nicht der Bug war die Geschichte. Die Geschichte ist, dass eine träge Uhr plus eine undurchsichtige, nachgeschobene Auszahlungsentscheidung einen Forscher, der eine echte Schwachstelle leise gemeldet hatte, in jemanden mit Megafon und Groll verwandelten. Jeder Teil dieses Ergebnisses war eine Prozessentscheidung, und jeder Teil war vermeidbar. > Eine Anmerkung dazu, was dieser Artikel nicht behauptet: AMD war rechtlich nicht zur Zahlung verpflichtet, und niemand kann eine bestimmte Meldung in den Geltungsbereich zwingen. Die ehrliche, engere Aussage lautet: Der *Prozess* hat versagt. Eine stumme Uhr, eine nicht dokumentierte Geltungsbereichs-Einstufung und eine nicht im Hauptbuch erfasste Entscheidung haben aus einer verweigerten Prämie einen Reputationsvorfall gemacht. ## Warum es zum Streit um Bug-Bounty-Auszahlungen kommt Beim Streit um Bug-Bounty-Auszahlungen geht es selten allein um den Geldbetrag. Er entsteht aus der Lücke zwischen dem, was ein Programm beworben hat, und dem, was es tatsächlich getan hat. Forscher tolerieren eine niedrige Obergrenze; sie tolerieren keine verschobenen Torpfosten. Fünf Vertrauenskiller verursachen die meisten Streitfälle: - **Keine laufende Uhr.** Der Fix zieht sich über Monate, weil nichts herunterzählt. Der Forscher sitzt im Schweigen und unterstellt böse Absicht. - **"Außerhalb des Geltungsbereichs", entschieden nach Auslieferung des Fixes.** Die Berechtigung wird rückwirkend beurteilt, sobald das Unternehmen den Patch bereits in der Hand hat. - **Auszahlung unterhalb der beworbenen Matrix.** Ein Programm verspricht "ab 1.000 $ für Mittel" und zahlt ohne Erklärung 200 $ — die empfundene Ungerechtigkeit ist die Lücke, nicht die Zahl. - **Nachträgliche Regeländerungen.** Die Bedingungen verschieben sich mitten in einer Meldung, und die neuen Bedingungen werden rückwirkend auf eine Meldung angewendet, die unter den alten eingereicht wurde. - **Undurchsichtige, nicht erfasste Entscheidungen.** Niemand kann rekonstruieren, wer was wann und gegen welche Regel entschieden hat. Sicherheitsveteranen warnen seit Jahren davor. Wie Kritiker wie Katie Moussouris, Jonathan Leitschuh, Robert Graham und Tavis Ormandy in der Berichterstattung über die Bug-Bounty-Branche dargelegt haben, untergraben NDAs und erkauftes Schweigen das Offenlegungsmodell; Transparenz ist es, was ein Programm wirksam macht. Das Muster ist in jedem Streitfall dasselbe: Die Entscheidung war an nichts geknüpft, was der Forscher vorab hätte nachlesen können. ### Keine laufende Uhr bedeutet, der Fix versandet einfach Eine Schwachstelle ohne Behebungsfrist ist eine Schwachstelle, für die sich niemand zuständig fühlt. Laut Forschung zu Behebungs-SLAs von Secure.com brauchen die meisten Organisationen **60 bis 150 Tage**, um kritische Schwachstellen zu patchen. Angreifer hingegen nutzen kritische Lücken bereits **5 Tage** nach öffentlicher Offenlegung aus, und rund **60 % der Sicherheitsvorfälle 2024** ließen sich auf eine bekannte, ungepatchte Schwachstelle zurückführen. AMDs 124 Tage lagen mitten in der Gefahrenzone — und weil keine Uhr veröffentlicht war, war niemand dafür verantwortlich. ### "Außerhalb des Geltungsbereichs", entschieden nach Auslieferung des Fixes Der Geltungsbereich ist ein Versprechen, das Sie geben, bevor die Meldung eintrifft — kein Urteil, zu dem Sie gelangen, nachdem Sie den Patch haben. Wenn ein Programm eine Meldung annimmt, eine CVE vergibt, den Forscher nennt und dann dasselbe Problem für außerhalb des Geltungsbereichs erklärt, liest sich die Geltungsbereichs-Einstufung als Manöver zur Zahlungsvermeidung — weil sie funktional genau das ist. Entscheiden Sie die Berechtigung anhand eines vorab veröffentlichten Geltungsbereichs-Dokuments, oder berufen Sie sich gar nicht erst auf den Geltungsbereich. ### Auszahlung unterhalb der beworbenen Matrix Ein separater, viel diskutierter Streitfall betraf einen Forscher, dem **50.000 $** für einen kritischen Bug angeboten wurden — gegenüber dem ausgewiesenen Maximum des Programms von **500.000 $**, ohne detaillierte Erklärung für die Kürzung und mit langer Zahlungsverzögerung. Der Betrag mag vertretbar gewesen sein. Das Schweigen war es nicht. Eine Kürzung ohne dokumentierten Grund gegen eine öffentliche Matrix wirkt immer wie ein Lowball-Angebot, selbst wenn sie es nicht ist. ### Nachträgliche Regeländerungen Ihre Programmbedingungen zu ändern, ist in Ordnung. Die neuen Bedingungen auf Meldungen anzuwenden, die unter den alten eingereicht wurden, ist es nicht. Sobald Sie eine Einreichung annehmen, gelten die zum Zeitpunkt der Einreichung gültigen Regeln. Alles andere ist eine Mogelpackung — und die Forschergemeinschaft behandelt es auch so. ## Wie schnell ist "schnell genug"? Behebungs-SLAs nach Schweregrad Ein Behebungs-SLA ist eine veröffentlichte, schweregradabhängige Frist für die Auslieferung eines Fixes, gemessen ab dem Moment, in dem Sie die Meldung bestätigen. Es ist das, was "124 Tage" objektiv unhaltbar macht statt zu einer Frage der Meinung. Die breit zitierten Branchenvorgaben sind eng: | Schweregrad | Übliche SLA-Vorgabe | GitLab-Handbuch-Variante | |---|---|---| | Kritisch | 24 bis 72 Stunden | 24 h Mitigation | | Hoch | 30 Tage | 30 Tage | | Mittel | 60 Tage | 90 Tage | | Niedrig | 90 Tage | 180 Tage | Quellen: Secure.com Behebungs-SLA-Leitfaden; GitLab-Handbuch zum Schwachstellenmanagement. Gemessen an jeder dieser Benchmarks liegt ein 124-tägiger Fix für ein kritisches Problem der RCE-Klasse um ein Vielfaches über der Vorgabe. Wo genau die Schwellen zwischen den Stufen liegen, bestimmen Sie. Entscheidend ist, dass Sie sie festlegen, sie schlimmster-Fall-zuerst auf Ihrer Richtlinienseite veröffentlichen und auf jede bestätigte Meldung eine Uhr setzen — damit "überfällig" ein Status ist, den das System anzeigt, und nicht eine Beschwerde, die der Forscher einreichen muss.

Soll die Uhr von allein laufen? Das CSIRT-Modul von Kit hängt an jede Meldung ein schweregradabhängiges Behebungs-SLA und zeigt automatisch an, ob sie im Plan, gefährdet oder überschritten ist — so kann ein Fix nie im Stillen versanden.

Kostenlose Testphase starten

## Was eine Prämie tatsächlich zahlen sollte Eine Prämienmatrix ist eine veröffentlichte Tabelle mit Prämienspannen je Schweregrad, verankert an echten Marktdaten — damit Prämien berechnet und nicht wegverhandelt werden. Öffentliche Benchmarks liefern Ihnen die Ankerwerte: | Stufe | HackerOne-Mediane | Bugcrowd-Spannen | |---|---|---| | Kritisch / P1 | 3.000 $ bis 5.000 $ | 3.500 $ bis über 20.000 $ | | Hoch / P2 | 1.000 $ bis 2.500 $ | 1.500 $ bis 7.500 $ | | Mittel / P3 | 500 $ bis 1.000 $ | 500 $ bis 2.500 $ | | Niedrig / P4 | 100 $ bis 300 $ | 175 $ bis 600 $ | Quellen: bug-bounties.as93.net (HackerOne-Mediane); Bugcrowd-Auszahlungsleitfaden. Das sind Spannen, kein Evangelium. Googles Vulnerability Reward Program zahlt weit höher — kritische Funde landen zwischen 10.000 $ und 31.337 $ — und über die gesamte Plattform hinweg zahlte HackerOne Forschern in einem jüngeren Zwölf-Monats-Zeitraum rund **81 Millionen $** aus. Stellen Sie Ihre Matrix als Spannen dar, nennen Sie die Plattform, an der Sie sich orientiert haben, und widerstehen Sie der Versuchung, eine einzige kanonische "Durchschnittsprämie" zu nennen. Der Sinn der Matrix ist nicht, großzügig zu sein. Der Sinn ist, dass ein Forscher seine Prämie abschätzen kann, bevor er auf Absenden klickt — und dass Ihre spätere Prämie in einer Spanne landet, die er bereits gesehen hat. ## Wie Sie eine Meldung ablehnen, ohne den Forscher zu verlieren Sie werden Meldungen ablehnen. Außerhalb des Geltungsbereichs, Duplikat, rein informativ, akzeptiertes Risiko: alles legitim. Eine Ablehnung wird erst dann zum Streitfall, wenn sie eine Überraschung ist. Vier Praktiken bewahren ein "Nein" davor, zum öffentlichen Streit zu werden: 1. **Entscheiden Sie anhand einer vorab veröffentlichten Regel.** Verweisen Sie namentlich auf das Geltungsbereichs-Dokument oder die Matrixstufe, auf der die Entscheidung beruht. Wenn die Regel zum Zeitpunkt der Meldung nicht existierte, können Sie sie nicht heranziehen. 2. **Zeigen Sie die Daten.** Wenn Sie eine Prämie kürzen, zeigen Sie die Benchmark-Spanne, aus der die Zahl stammt. Ein dokumentierter Grund schlägt eine großzügige Zahl, die im Schweigen ausgezahlt wird. 3. **Lassen Sie die Anerkennung unangetastet.** Eine verweigerte Auszahlung muss keine gelöschte Anerkennung bedeuten. Ein Hall-of-Fame-Eintrag und Reputationspunkte kosten nichts und bewahren den guten Willen, selbst wenn das Geld strittig ist. 4. **Bieten Sie ein Einspruchsverfahren an.** Ein einseitiges "Nein" liest sich als Machtwort. Eine überprüfbare Entscheidung liest sich als fair, selbst wenn die Antwort sich nicht ändert. Falls Sie die Eingangsseite davon noch nicht aufgebaut haben, beginnen Sie mit unserem Leitfaden dazu, [wie Sie ein Vulnerability-Disclosure-Programm einrichten](/blog/how-to-set-up-vulnerability-disclosure-program). Und falls Sie sich eher um die Beziehung als um das Geld sorgen, behandelt der Begleitbeitrag dazu, [wann Forscher nach einer verpfuschten Offenlegung an die Öffentlichkeit gehen](/blog/when-researchers-go-public-botched-disclosure), die Vertrauensmechanik in der Tiefe. Dieser Artikel ist die Day-2-Fortsetzung: wie Sie einen Forscher nicht verlieren, wenn Geld und eine Frist gleichzeitig auf dem Spiel stehen. (Zum wachsenden Mengenproblem siehe [KI-Spam überschwemmt die Bug-Bounty-Sichtung](/blog/ai-slop-flooding-bug-bounty-triage).) ## Wie Kit Behebungs-SLAs und Auszahlungsfairness operationalisiert Die CSIRT-Sparte von Kit wurde nahezu Zeile für Zeile als Antwort auf das AMD-Versagen gebaut: die Uhr und die Matrix veröffentlichen, die Zeit bis zum Fix daran messen und jede Auszahlungsentscheidung so erfassen, dass sie vertretbar statt abstreitbar ist. So bildet sich jeder AMD-Fehltritt auf eine eingebaute Funktion ab. | Versagen im Fall AMD | Wie Kit damit umgeht | |---|---| | 124-Tage-Uhr lief stumm | Schweregradabhängige Behebungsziel-SLAs, schlimmster-Fall-zuerst veröffentlicht, mit Standardwerten von super-kritisch 24 h bis niedrig 30 d | | Niemand zeigte an "das ist überfällig" | Live-SLA-Status auf jeder Meldung: im Plan, gefährdet oder überschritten, plus eine Prüfung "Haben wir innerhalb der Vorgabe behoben?" | | Bestätigung versandete | Ein separates Bestätigungs-SLA (standardmäßig 72 h) treibt die Gefährdungs- und Überschreitungsrechnung an | | Auszahlung ad hoc entschieden, dann verweigert | Ein Prämien-Benchmark berechnet Median, Mittelwert, Minimum und Maximum der Auszahlungen je Schweregrad aus Ihrer eigenen Prämienhistorie — so sind Prämien datenverankert | | "Außerhalb des Geltungsbereichs" nachträglich gerufen | Eine vorab veröffentlichte Geltungsbereichs-Konfiguration und Prämienmatrix entscheiden die Berechtigung vorab, nicht rückwirkend | | Kein prüfbarer Datensatz der Entscheidung | Prämien fließen in ein integritätsgeprüftes Hauptbuch und Auszahlungsdatensätze ein, die den laufenden Saldo verifizieren und jeden Verstoß markieren | | Anerkennung an die Auszahlung gekoppelt | Karma-Ereignisse und eine Hall of Fame halten die Anerkennung des Forschers intakt, selbst wenn eine Auszahlung strittig oder abgelehnt ist | | Ablehnung als einseitiges "Nein" behandelt | Ein eingebauter Einspruchspfad macht eine abgelehnte oder gekürzte Prämie überprüfbar statt zum Machtwort | Die These ist eng und sie hält stand: AMD verlor den Forscher nicht, weil der Bug schwierig war. Es verlor ihn, weil keine Uhr lief und die Auszahlungsentscheidung im Dunkeln getroffen wurde — nachträglich, gegen eine Regel, die zum Zeitpunkt seiner Meldung nicht existierte. Ein Behebungs-SLA, das Sie veröffentlichen und nachverfolgen, plus eine Prämienmatrix, die an Ihren eigenen Auszahlungsdaten verankert und in einem Hauptbuch erfasst ist, machen aus "außerhalb des Geltungsbereichs, keine Zahlung" aus einem Verrat eine vorhersehbare, vertretbare Entscheidung. Ob Sie eine bestimmte Meldung bezahlen, bleibt weiterhin Ihre Entscheidung. Kit macht diese Entscheidung schnell, datenverankert und prüfbar. ## Das Fazit: Veröffentlichen Sie die Uhr und die Matrix, bevor Sie je Nein sagen Jeder Streit um Bug-Bounty-Auszahlungen lässt sich auf dieselbe Grundursache zurückführen: eine Entscheidung gegen eine Regel, die der Forscher nie zu sehen bekam. Veröffentlichen Sie Ihre schweregradgestaffelten Behebungs-SLAs. Verankern Sie Ihre Prämienmatrix an echten Benchmark-Daten und veröffentlichen Sie auch sie. Setzen Sie auf jede bestätigte Meldung eine Uhr, damit "überfällig" ein Systemzustand ist und nicht die Beschwerde eines Forschers. Erfassen Sie jede Freigabe, Kürzung und Ablehnung in einem Hauptbuch, das Sie prüfen können. Tun Sie das, und eine Ablehnung wird zu etwas, das ein Forscher erwartet hat, verifizieren kann und um das herum er weiter meldet — statt zu dem, was Sie auf die Titelseite von Tom's Hardware bringt. Wenn Sie ein VDP oder ein bezahltes Bounty-Programm betreiben und die Geld-und-Uhr-Seite immer noch in Tabellen und gutem Willen lebt, ist genau das die Lücke, die das CSIRT-Modul von Kit schließt. [Starten Sie eine kostenlose Testphase](/users/sign_up) und legen Sie Ihre SLAs und Ihre Prämienmatrix fest, bevor die nächste kritische Meldung eintrifft.