Thought Leadership
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.
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.
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.
Was die Sicherheitsforscher von Synack anders machen
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.
Synack wurde auf der Prämisse aufgebaut, beides bieten zu können: die Forschungsqualität, die aus echten Incentives resultiert, und die Struktur, Kontrolle und Rechenschaftspflicht, die ein seriöses Sicherheitsprogramm erfordert. Das Synack Red Team ist eine private Community, kein offener Marktplatz. Die Aufnahme erfordert nachgewiesene Fähigkeiten und einen aufwendigen Überprüfungsprozess von etwa sechs Monaten. Das bedeutet: Wenn ein Forscher einen Befund einreicht, dann deshalb, weil er tatsächlich etwas gefunden hat – und nicht, weil ein KI-Agent auf einen Untersuchungsbereich ausgerichtet und angewiesen wurde, plausibel klingende Ergebnisse zu generieren.
Triage der Befunde und schnellere Behebung
Jeder Befund wird von Synack einer Triage unterzogen, bevor er das Team erreicht. Was in der Warteschlange landet, wurde bereits als echte, ausnutzbare Schwachstelle bestätigt. Es wird überprüft, ob sie korrekt klassifiziert und mit einem Proof-of-Concept dokumentiert ist, und etwaige Duplikate werden entfernt. Auf diese Weise arbeiten interne Sicherheitsingenieure an der Behebung und müssen nicht stundenlang damit verbringen, halluzinierte Funktionsaufrufe zu widerlegen. Wenn Sicherheitsteams sich nicht durch irrelevante Informationen wühlen müssen, können sie sich auf das Wesentliche konzentrieren.
Die Sichtbarkeit ist etwas, das herkömmliche Bug-Bounty-Programme strukturell nicht bieten können. Synack zeigt die Arbeitsstunden der Forscher und den Testverkehr auf, aufgeschlüsselt nach jedem Teil des Untersuchungsumfangs. Ebenso verwaltet Synack das Programm gemeinsam mit dem Kunden. Wenn ein kritisches Asset nicht ausreichend Beachtung findet, lässt sich dies erkennen und darauf reagieren. Incentives lassen sich neu zuweisen, das Problem als Schwerpunkt kennzeichnen und die Gründe dafür ermitteln. Aktualisierungen zu geänderten Bereichen lassen sich innerhalb einer Anwendung bekannt geben, um die Forscher darauf zu lenken, wo Risiken entstehen könnten.
Da alle Tests über die PTaaS-Plattform von Synack laufen, haben Unternehmen den Überblick darüber, wer testet, welche Methoden angewendet werden und was in ihrer gesamten Umgebung geschieht. Für Unternehmen, die gegenüber Wirtschaftsprüfern oder Aufsichtsbehörden nachweisen müssen, dass sie die Kontrolle haben, ist das entscheidend. Für jeden, der für die Sicherheit von Produktionssystemen verantwortlich ist, sollte es ohnehin entscheidend sein. Außerdem ist es wichtig, die vollständige Kontrolle über das Stoppen und Starten von Tests zu haben. Ohne eine technische Kontrollmöglichkeit, die verhindert, dass Tester auf die Ziele zugreifen, ist dies nahezu unmöglich.
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.
Der Ansatz von Synack bewahrt das, was am Bug-Bounty-Programm wirklich wertvoll ist: exzellente, kreative Tests durch Menschen, die all das ersetzen, was den Betrieb mühsam macht. Dies bedeutet auch: ein einziges Ansprechpartnerteam, eine einzige Plattform, triagierte Befunde und vollständige Sichtbarkeit darüber, was bereits getestet wurde und was noch nicht.
