GitHub zieht die Bug-Bounty-Schraube an: KI-Slop wird teurer

GitHub dreht an seinem Bug-Bounty-System

GitHub verschärft sein Bug-Bounty-Programm nicht in dem simplen Sinn, dass KI plötzlich unerwünscht wäre. Der wichtigere Punkt ist ökonomischer: Das Unternehmen sortiert die Belohnungslogik neu und will belastbare, reproduzierbare Forschung stärker honorieren als bloße Einreichungsmasse. In seinem Umbau beschreibt GitHub ausdrücklich einen Fokus auf die Qualität von Findings und Beziehungen statt auf die reine Zahl von Reports. Dazu gehören auch statische Auszahlungen je Schweregrad und ein VIP-Zugang, der an nachgewiesene, konsistente Qualität geknüpft ist. Für Researcher heißt das: Wer nur schnell viel einreicht, bekommt ein schlechteres Spiel als jemand, der wenige, aber saubere Findings liefert.

Für B2B-Leser ist das mehr als eine Plattformnotiz. GitHub zeigt damit offen, woran viele Security-Programme gerade leiden: Die Zahl der Einreichungen steigt, aber der Anteil wirklich verwertbarer Berichte steigt nicht im gleichen Maß. Sobald KI hilft, Hypothesen, Text und Varianten sehr billig zu produzieren, wird Triage zum Flaschenhals. Genau dort greift GitHub jetzt ein.

KI bleibt erlaubt, aber nicht mehr blind belohnt

Die vielleicht wichtigste Klarstellung aus GitHubs eigener Begründung lautet: Ein KI-unterstützter Fund kann weiterhin ein sehr guter Fund sein. Entscheidend ist nicht das Werkzeug, sondern ob der Mensch dahinter den Befund validiert hat. GitHub schreibt sinngemäß, dass ein AI-assisted Finding mit verifiziertem, reproduziertem Ergebnis und funktionierendem Proof of Concept eine gute Einreichung ist. Ein unvalidierter Output ohne Reproduktion oder nachgewiesenen Impact ist es nicht.

Damit verschiebt sich die Messlatte nicht auf "menschlich statt KI", sondern auf "Substanz statt Füllmaterial". GitHub betont außerdem, dass gute Reports kurz, strukturiert und direkt sein sollen: eine knappe Zusammenfassung, klare Reproduktionsschritte mit Belegen und ein verständliches Impact-Statement. Lange theoretische Erzählungen oder erstellt Fülltext verlangsamen laut GitHub die Triage, weil der eigentliche Befund darin untergeht.

Für Security-Teams ist das eine nützliche Denkfigur: KI ist in diesem Markt nicht das Problem an sich. Das Problem entsteht, wenn aus schneller Hypothesenbildung sofort abrechnungsfähige Wahrheit gemacht wird. Genau an dieser Stelle passt auch unser Blick auf KI macht uns selbstsicherer – und oft gefährlich falsch: Gute Formulierungen ersetzen keine technische Verifikation.

Warum das mehr ist als ein GitHub-Detail

GitHub begründet die Änderung auch operativ. Wer heute bereits gute Forschung einreicht, soll von weniger Queue-Noise und schnelleren Antworten profitieren. Das ist ein wichtiges Signal, weil es die Kosten schlechter Reports offenlegt: Nicht nur GitHub zahlt möglicherweise weniger für schwache Meldungen, sondern das gesamte Programm verliert Zeit für die wirklich relevanten Fälle.

Darin steckt ein breiterer Markttrend. Plattformen wie HackerOne und Bugcrowd arbeiten ebenfalls mit Standards für Verhalten, Qualität und verwertbare Einreichungen. Die Quellen belegen nicht, dass alle Anbieter identische KI-Regeln eingeführt hätten. Sie zeigen aber klar genug, dass der Markt den gleichen Schmerz spürt: Mehr Tools erzeugen mehr Material, aber nicht automatisch mehr Sicherheitswert. In diesem Sinn ist GitHubs Schritt eher Vorbote als Ausreißer.

Für Entwicklerorganisationen ist das besonders relevant, wenn sie selbst Sicherheitsmeldungen triagieren oder ein eigenes Programm betreiben. Dann stellt sich nicht mehr nur die Frage, ob externe Researcher viele Reports bringen, sondern ob die Bewertungslogik genügend Signal von Lärm trennt. Wer diesen Gedanken weiterziehen will, landet schnell bei derselben Systemfrage wie in Warum KI-Agenten am Harness scheitern — nicht am Modell: Der Wert entsteht selten allein im Modell, sondern in den Grenzen, Prüfungen und Rückkopplungen darum herum.

Woran man gute Reports jetzt erkennt

Die praktische Lehre aus GitHubs Umbau ist überraschend schlicht: Gute Reports sparen Zeit, schlechte Reports verbrennen sie. Das gilt für unabhängige Bug-Hunter genauso wie für interne DevSecOps-Teams. Wer Meldungen bewertet, sollte deshalb weniger auf die Menge möglicher Schwachstellen schauen als auf die Frage, ob ein Bericht technisch belastbar ist.

Besonders wichtig werden vier Prüfsteine. Erstens: Reproduzierbarkeit. Kann jemand anderes den Befund mit den angegebenen Schritten nachvollziehen? Zweitens: Proof of Concept. Gibt es einen funktionierenden Nachweis statt nur einer plausibel klingenden Vermutung? Drittens: Impact. Wird erklärt, was ein Angreifer real erreichen kann? Viertens: Verantwortungsgrenze. Liegt das Problem wirklich bei der Plattform oder basiert der Effekt auf riskantem Verhalten mit untrusted Content, das außerhalb des beabsichtigten Sicherheitsmodells liegt?

Gerade dieser letzte Punkt wird in der KI-Ära wichtiger. Viele Reports können technisch interessant und trotzdem für ein Bounty-Programm wenig wertvoll sein, wenn sie die eigentliche Sicherheitsgrenze falsch lesen. Wer im eigenen Unternehmen ähnliche Muster sieht, sollte nicht nur Triage-Kapazität erhöhen, sondern die Anforderungen an Einreichungen klarer formulieren. In verwandten Agenten- und Tool-Ketten zeigt sich derselbe Effekt, wie unser Stück Warum KI-Agenten nicht am Modell scheitern, sondern an ihren Verbindungen beschreibt: Ohne saubere Systemgrenzen wird jede Bewertung teuer.

Was noch unklar bleibt

GitHubs Signal ist eindeutig, aber nicht jede Detailfrage ist damit schon beantwortet. Aus den öffentlich zugänglichen Quellen lässt sich sauber ableiten, dass Qualität, Validierung und klarere Priorisierung wichtiger werden. Weniger eindeutig ist, wie stark sich einzelne Auszahlungsstufen in der täglichen Praxis für bestimmte Report-Arten verändern und wie schnell sich die neue Logik in allen Teilen des Programms auswirkt.

Wichtig ist deshalb die saubere Abgrenzung: Die Meldung sagt nicht, dass KI-basierte Recherche wertlos wäre. Sie sagt auch nicht, dass neue oder kleinere Researcher pauschal verlieren. GitHub schreibt im Gegenteil, dass gute Einreichungen neuer Researcher weiterhin willkommen sind. Der Unterschied ist nur, dass billige Report-Produktion ohne belastbare Prüfung schlechter durch das System kommen soll.

Für Unternehmen mit eigenem Vulnerability-Intake ist genau das die eigentliche Lehre. Wenn Ihre Triage heute unter textreichen, aber substanzarmen Meldungen leidet, ist die Antwort nicht nur mehr Personal. Oft ist die wirksamere Frage: Welche Mindestanforderungen an PoC, Reproduktion, Scope und Impact müssen Einreicher erfüllen, damit aus KI-Tempo nicht KI-Lärm wird?

Darum ist GitHubs Schritt am Ende weniger Anti-KI als Anti-Schludern. Der Markt beginnt, nicht das schnellste Schreiben zu belohnen, sondern die sauberste Verifikation.