KI-Müll überlastet IT-Securityteams – Warum das Bug Bounty Modell versagt.
Offene Bug Bounty Programme brechen unter der Last von KI-generiertem Rauschen, einer Überlastung bei der Triage und Lücken in der Abdeckung zusammen – was ist die Alternative?
Zusammenfassung (TL; DR):
- Offene Bug Bounty Programme stehen durch die Flut KI-generierter, plausibel klingender Falschmeldungen vor dem Kollaps und zwingen namhafte Projekte zum Abbruch.
- Der traditionelle Qualitätsfilter fachlicher Expertise ist weggefallen, was zu einer massiven Überlastung der internen Triage-Teams führt.
- Zudem bieten diese ungesteuerten Programme keine verlässliche Testabdeckung und bergen unkontrollierbare Compliance-Risiken für regulierte Branchen.
Bug Bounty hatte eine erfolgreiche Zeit
Bug Bounty Programme belohnen ethische Hacker, die Schwachstellen aufdecken und diese verantwortungsbewusst an den Entwickler der Anwendung melden, bevor Angreifer sie ausnutzen können. Durch die Einbindung einer vielfältigen, globalen Expertencommunity können Unternehmen ihre Angriffsfläche kontinuierlich überwachen und testen, schwer zu findende Schwachstellen aufdecken, Risiken reduzieren und das Vertrauen ihrer Kunden stärken. Bug-Bounty-Programme ermöglichen es somit Unternehmen, die Hacker-Community zu nutzen, um die Sicherheit ihrer Systeme im Laufe der Zeit zu verbessern.
Irgendwo auf dem Weg ist jedoch etwas schiefgelaufen, und die Branche hat sich bisher gescheut, dies offen auszusprechen. Die Realität ist, dass unkontrollierte, offene Bug Bounty-Programme ihre Betreiber in Rauschen ertränken und ganze Bereiche der Angriffsfläche unberührt lassen.
Ende für cURL
Im Januar 2026 stellte Daniel Stenberg das Bug Bounty Programm des cURL-Projekts ein. cURL ist eines der weltweit am häufigsten genutzten Open-Source-Tools. Stenberg schloss das Programm nicht widerwillig und führte auch keine Budget- oder Bandbreitenprobleme als Grund an. Er stellte es ein, weil das Programm zu einem System geworden war, durch das sein Team praktisch einem DDoS-Angriff ausgesetzt war. Bis 2025 identifizierten weniger als fünf Prozent der Einsendungen eine echte Schwachstelle. Allein in den ersten 21 Tagen des Jahres 2026 gingen zwanzig Meldungen ein. Keine einzige war stichhaltig.
„Die Bewältigung der endlosen Flut an unseriösen Meldungen fordert einen hohen psychischen Tribut“, schrieb er. „Zeit und Energie, die völlig verschwendet werden.“ Das ist die Beschreibung seines Bug-Bounty-Programms durch den Leiter eines der wichtigsten Open-Source-Projekte im Internet. Es handelt sich nicht um einen Einzelfall.
cURL ist nicht das einzige Bug Bounty Programm, das eingestellt wurde
Auch das Sicherheitsteam von Django erhielt von KI generierte Meldungen. CycloneDX wurde komplett eingestellt. Die Freiwilligen von Apache Log4j prüften 67 Meldungen innerhalb weniger Monate, wobei der Großteil allein in den letzten beiden Monaten einging – ein erschöpfendes Volumen für ein unbezahltes Team. Google hat KI-generierte Meldungen für seine Open-Source-Schwachstellenprämien eingestellt. GitHub verschärfte seine Anforderungen an die Einreichung, nachdem es eingesehen hatte, dass es echte Fundstellen nicht mehr von Störsignalen unterscheiden konnte, und stellte fest, dass das Problem nicht nur bei ihnen liegt: „Programme in der gesamten Branche kämpfen mit derselben Herausforderung, und einige wurden komplett eingestellt.“
KI „halluziniert“ auch, weil große Sprachmodelle (Large Language Models, LLMs) sich eher auf statistische Mustervorhersagen als auf faktenbasiertes Denken stützen, was sich negativ auf Bug-Bounty-Programme auswirkt, indem sie die Triage-Teams mit schlüssigen, aber erfundenen Sicherheitslückenberichten überschwemmen.
Der informelle Qualitätsfilter ist weg
Jahrelang erforderte das Einreichen eines glaubwürdigen Sicherheitsberichts echte Fachkenntnisse: das Verständnis der Codebasis, die Reproduktion des Problems und die fachliche Dokumentation. Diese Anforderung war ein informeller Qualitätsfilter. LLMs haben ihn zunichtegemacht. Die Kosten für die Erstellung von etwas, das wie ein professioneller Schwachstellenbericht aussieht, liegen mittlerweile bei nahezu null. Die Kosten für die Triage dieses Berichts hingegen nicht. Wenn überhaupt, sind sie gestiegen, da KI-generierte Einsendungen gut formatiert sind, plausibel klingen und deren Entlarvung länger dauert als bei offensichtlich mangelhaften Berichten. Der Anreiz besteht darin, den Kunden mit Schwachstellen zu überschütten. Die Last trägt der Empfänger.
Überlastung bei der Triage, blinde Flecken und lückenlose Sichtbarkeit
Die KI-Krise sorgt zwar für Schlagzeilen, doch sie hat sich auf bereits bestehende Probleme gelegt.
Die Triage war schon immer das schmutzige Geheimnis von Bug Bounty Programmen. Schon bevor große Sprachmodelle (LLMs) ins Spiel kamen, lehnten typische Programme 50 bis 70 Prozent der Einsendungen als Duplikate oder Fehlalarme ab. Diese Arbeit verschwindet nicht einfach, sondern fällt jemandem im Unternehmen zu, der jeden Bericht lesen, ihn technisch verstehen, versuchen muss, den Fehler zu reproduzieren, über den Schweregrad entscheiden und das Ergebnis an den Forscher zurückmelden muss. Bei großem Umfang ist das eine eigene Funktion im Bereich Security Engineering. Die meisten Teams sind dafür personell nicht ausgerüstet und hatten dies auch nie geplant.
Dann ist da noch die Bounty Wallet selbst. Die richtige Festlegung der Prämienhöhen ist schwieriger, als es klingt. Sind sie zu niedrig, wenden sich Forscher, die echte, anspruchsvolle Arbeit leisten, Programmen zu, die sie wertschätzen. Sind sie zu hoch, zieht man genau die Art von spekulativem Mengenjagen an, die mittlerweile mit KI-Tools als Waffe eingesetzt wird. Unternehmen tragen zudem den Aufwand für die Verwaltung von Auszahlungen, die Klärung von Streitfällen und die Pflege der Beziehungen zu einer Community, die ihre eigene Kultur, ihre eigenen Erwartungen und gelegentlich sehr öffentliche Frustrationen hat, wenn etwas schiefgeht.
Fehlende Sichtbarkeit
Das Problem, über das jedoch am wenigsten gesprochen wird, ist die Sichtbarkeit – oder vielmehr deren völliges Fehlen. In einem offenen Bug Bounty Programm gibt es keine verlässliche Möglichkeit zu erfahren, welche Teile des Prüfumfangs getestet und welche ignoriert werden. Forscher wenden sich dorthin, wo die Prämien am höchsten und die Schwachstellen am leichtesten zugänglich sind. Ganze Bereiche der Angriffsfläche – neuere APIs, interne Systeme, kürzlich bereitgestellte Funktionen – erhalten möglicherweise keinerlei Beachtung. Unternehmen werden es erst erfahren, wenn entweder ein Forscher sie darauf hinweist oder jemand anderes es tut.
Das Problem der Sichtbarkeit in regulierten Branchen
Für Unternehmen in regulierten Branchen entsteht dadurch eine ganz eigene Problemkategorie. Diese Unternehmen laden praktisch unbekannte Personen dazu ein, Produktionssysteme mit Methoden und Tools zu testen, die sie nicht überprüfen können, wobei die Einhaltung des Testumfangs weitgehend der Selbstkontrolle unterliegt. Es gibt zwar Regeln für die Zusammenarbeit, doch deren Durchsetzung ist begrenzt. Für Finanzdienstleister, das Gesundheitswesen oder staatliche Unternehmen mit spezifischen Compliance-Verpflichtungen ist das eine schwer zu vertretende Haltung.
Das Incentive-Modell ist nicht das Problem. Motivierte, hochqualifizierte Sicherheitsforscher finden nach wie vor Schwachstellen, die interne Teams und automatisierte Scanner übersehen – daran hat sich nichts geändert. Das Problem besteht darin, dieses Modell ohne Management, Aufsicht oder Qualitätskontrolle anzuwenden.
Lohnt sich die Investition in Bug Bounty-Programme?
Die Programme, die eingestellt werden, lehnen nicht die Idee ab, dass Incentive-basierte Sicherheitsforschung funktioniert. Sie lehnen vielmehr die spezifische Umsetzung ab, bei der Programme unkontrolliert, ungesichert und für jeden offen sind, dem die Umgebung Zugang gewährt hat.
Gleichzeitig lohnt es sich zu hinterfragen, was Unternehmen für diese Investition zurückbekommen, wenn sie intern ein Bug Bounty Programm betreiben und erhebliche Ressourcen für die Triage, die Verwaltung der Incentives, die Beziehungen zu den Forschern und die Programmverwaltung aufwenden. Wenn die Antwort eine Warteschlange voller Störsignale ist und das Programm kein verlässliches Bild der Testabdeckung liefert, funktioniert das Modell nicht.
Häufige Fragen (FAQ)
Häufige Fragen (FAQ)
Das Programm wurde wegen einer extremen Überlastung durch KI-generierte Falschmeldungen eingestellt, was dem Team wie ein „DDoS-Angriff“ auf ihre Arbeitszeit vorkam. Bis zu diesem Zeitpunkt enthielten weniger als fünf Prozent der Einsendungen eine echte Schwachstelle, während in den ersten drei Wochen des Jahres 2026 keine einzige der zwanzig Meldungen stichhaltig war.
Früher erforderten Berichte echtes Fachwissen, Code-Verständnis und manuelle Reproduktion, was als natürlicher Filter wirkte. LLMs senken die Kosten für die Erstellung plausibel klingender, perfekt formatierter Berichte auf nahezu null, während die Überprüfung (Triage) dieser erfundenen Sicherheitslücken für Unternehmen sogar noch zeitaufwendiger und teurer geworden ist.
Zum einen fehlt die Sichtbarkeit und Testabdeckung, da Forscher nur dort suchen, wo es das meiste Geld oder die leichteste Beute gibt (was kritische APIs oder interne Systeme ungetestet lässt). Zum anderen birgt es Compliance-Risiken, da regulierte Branchen (wie Finanzen oder Gesundheit) unüberprüfbare, anonyme Personen unkontrolliert auf ihren Live-Systemen testen lassen.
