Riesiges Rauschen bei Schwachstellenmeldungen : Wenn Bug-Bounty-Modelle wegen KI-Müll versagen
Offene Bug-Bounty-Programme brechen zunehmend unter der Last von KI-generiertem Rauschen, einer Überlastung bei der Triage und Lücken in der Abdeckung zusammen, warnt unsere Autorin.
Bug Bounty hatte eine erfolgreiche Zeit – solche Programme belohnen ethisch agierende 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 lassen sich Angriffsflächen kontinuierlich überwachen und testen, schwer zu findende Schwachstellen aufdecken und Risiken reduzieren. Bug-Bounty-Programme ermöglichen es 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, das offen auszusprechen: Die heutige Realität ist, dass unkontrollierte, offene Bug-Bounty-Programme ihre Betreiber in Rauschen ertränken und gleichzeitig Teile der Angriffsfläche unberührt lassen.
Zunehmende Probleme bei Bug-Bounty-Programmen
Im Januar 2026 hat Daniel Stenberg das Bug-Bounty-Programm des cURL-Projekts eingestellt – cURL ist eines der weltweit am häufigsten genutzten Open-Source-Tools. Stenberg führte dabei keine Budget- oder Bandbreitenprobleme als Grund an. Das Programm wurde eingestellt, weil es zu einem System geworden war, durch das sein Team praktisch einem Distributed-Denial-of-Service-(DDoS)-Angriff ausgesetzt war: 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 und sprach von „Zeit und Energie, die völlig verschwendet werden.“
Es handelt sich nicht um einen Einzelfall: 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 seine Open-Source-Schwachstellenprämien für KI-generierte Meldungen eingestellt. GitHub verschärfte seine Anforderungen an die Einreichung, nachdem man 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“, 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.
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 ihre Entlarvung länger dauert als bei offensichtlich mangelhaften Berichten. Offenbar besteht ein Anreiz darin, Organisationen mit Schwachstellen zu überschütten – die Last trägt der Empfänger.
Herausforderungen bei Prämien-Programmen gab es immer
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 LLMs ins Spiel kamen, lehnten typische Programme 50 bis 70 Prozent der Einsendungen als Duplikate oder Fehlalarme ab. Auch das bedeutet jedoch Arbeit: jeder Bericht ist zu lesen, technisch zu verstehen – man muss versuchen, den Fehler zu reproduzieren, über den Schweregrad entscheiden und das Ergebnis zurückmelden. 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 stäkerr wertschätzen. Sind sie zu hoch, zieht man genau die Art von spekulativen Fehlerjagden 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, und damit die Kommunikationsfähigkeiten von Organisationen fordert.
Das Problem, über das jedoch am wenigsten gesprochen wird, ist die Sichtbarkeit – oder vielmehr ihr 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 ein Vorfall das tut.
Für Unternehmen in regulierten Branchen entsteht noch eine ganz eigene Problemkategorie. Sie 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.
Wege aus der KI-Krise bei der Schwachstellensuche
Das Incentive-Modell ist dabei nicht an sich 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.
Gangbare Alternativen können auf einer Prämisse aufbauen, die möglichst beides bieten kann: Forschungsqualität, die aus echten Incentives resultiert, und gleichzeitig Struktur, Kontrolle und Rechenschaftspflicht, die ein seriöses Sicherheitsprogramm erfordert. Das lässt sich beispielsweise über geschlossene Communitys erreichen, statt einen offenen Marktplatz zu nutzen. Die Aufnahme in eine solche Community erfordert dann nachgewiesene Fähigkeiten und einen Überprüfungsprozess. Wenn ein Forscher in einem solchen Umfeld einen Befund einreicht, dann weil er tatsächlich etwas gefunden hat – und nicht, weil einfach ein KI-Agent auf einen Untersuchungsbereich ausgerichtet und angewiesen wurde, plausibel klingende Ergebnisse zu generieren.
Idealerweise werden Einreichungen einer Triage unterzogen, bevor sie Betroffene erreichen. Was in deren Warteschlange landet, wurde dann bereits als echte, ausnutzbare Schwachstelle bestätigt – es ist überprüft, ob sie korrekt klassifiziert und mit einem Proof-of-Concept dokumentiert ist, etwaige Duplikate bereits bereinigt. Auf diese Weise können interne Sicherheitsingenieure an der Behebung arbeiten und müssen nicht zunächst Zeit damit verbringen, eventuell halluzinierte Probleme zu widerlegen.
Wenn Sicherheitsteams sich nicht erst durch irrelevante Informationen wühlen müssen, können sie sich auf das Wesentliche konzentrieren. Kommerzielle Angebote können an dieser Stelle Ressourcen sparen, auch wenn sie zunächst naturgemäß etwas kosten – und sie können eine Sichtbarkeit liefern, die klassische Bug-Bounty-Programme strukturell nicht ermöglichen. Wenn etwa alle Tests über eine bestimmte Plattform laufen, lässt sich dort ein Überblick darüber gewinnen, wer testet, welche Methoden angewendet werden und was in der gesamten Umgebung geschieht.
Lohnt sich die Investition in Bug-Bounty-Programme?
Die eingestellten Programme verneinen nicht, dass Incentive-basierte Sicherheitsforschung funktioniert. Sie haben vielmehr vor einer spezifischen Umsetzung kapituliert, bei der Programme unkontrolliert, ungesichert und für jeden offen sind, dem die Umgebung Zugang gewährt hat.
Hier lohnt es sich zu hinterfragen, was Unternehmen für die 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.
Was an Bug-Bounty-Programmen wirklich wertvoll ist sind exzellente, kreative Tests durch unbefangene, fähige Menschen – jetzige und zukünftige Programme werden sich daran messen lassen müssen, ob sie genug solchen Input liefern. Wo das nicht der Fall ist, sollte man über eine Neuverteilung von Ressourcen nachdenken.
Angela Heindl-Schober ist CMO bei Synack.