Die Kurzfassung
Google hat sein Open-Source-Bug-Bounty eingefroren, weil KI-generierte Schwachstellenmeldungen den Betrieb zu teuer gemacht haben – nicht, weil der Code sicherer geworden wäre. Seit dem 1. Oktober 2026 nimmt das OSS VRP keine neuen Meldungen zu Produktschwachstellen in von Google betreuten Projekten wie Go, Angular, Bazel und Protocol Buffers mehr an. Ein Update hat Google für das erste Quartal 2027 angekündigt.
Für Teams, die auf diesen Bibliotheken aufbauen, ist ein externes Sicherheitsnetz dünner geworden. Für Teams mit eigenem Meldeweg für Schwachstellen ist es eine Warnung: Dieselbe Flut wird auch bei Ihnen ankommen. Ein guter Zeitpunkt, um zu prüfen, ob Ihre Sicherheitstests und Audits nicht davon abhängen, dass Außenstehende die Lücken zuerst finden.
Was hat Google angekündigt?
Das Vulnerability-Rewards-Team von Google hat bekanntgegeben, dass das OSS VRP keine neuen Einreichungen mehr annimmt. In der Mitteilung heißt es, die Pause sei „auf einen erheblichen Anstieg automatisierter Einreichungen zurückzuführen, von denen die große Mehrheit nicht gültig ist“. TechCrunch, das am 4. Oktober als Erstes darüber berichtete, beschreibt Google-Ingenieure und Open-Source-Maintainer als überlastet von ungültigen Meldungen, teils mit halluzinierten Details.
Seit 2022 bezahlt das Programm externe Forschende für Fehler in von Google betreutem Open-Source-Code: die Sprache Go samt Toolchain, Angular, Bazel, Protocol Buffers, Fuchsia sowie zugehörige Repository- und Supply-Chain-Einstellungen. Ganz schließt Google die Tür nicht. Sicherheitsfixes können über das Patch Rewards Program weiterhin bis zu 15.000 US-Dollar einbringen, Fehler in Open-Source-Repositories von Google Cloud mit Auswirkung auf Cloud-Produkte gehen weiter an das Cloud VRP, und vor dem 1. Oktober eingereichte Meldungen werden wie bisher bearbeitet.
Warum brechen Bug-Bounty-Programme unter KI-Meldungen ein?
LLMs und automatisierte Bug-Hunting-Skripte haben die Kosten für eine plausibel klingende Schwachstellenmeldung nahezu auf null gesenkt, die Kosten ihrer Prüfung aber nicht. Jede Meldung braucht weiterhin jemanden, der den Code kennt, sie liest, zu reproduzieren versucht und begründet, warum es ein Fehler ist oder nicht. Sind die meisten Meldungen falsch, fließt diese Arbeit in Rauschen – und echte Funde warten länger.
Google ist nicht der Erste, der nicht mehr für Masse zahlen will. Das curl-Projekt hat sein HackerOne-Bounty im Januar 2026 nach einer Welle KI-generierter Meldungen beendet, und laut BleepingComputer hat Intel im September die finanziellen Prämien aus seinem Intigriti-Programm gestrichen. Das Muster ist eindeutig: Programme, die pro gültigem Fund zahlen, aber unbegrenzt Einreichungen annehmen, brechen zuerst.
Was das für Softwareteams in DACH bedeutet
Erstens: Ihre Abhängigkeiten verlieren eine Quelle externer Prüfung. Viele Backend-Dienste sind in Go geschrieben, viele Frontends nutzen Angular, und Protocol Buffers steckt in den meisten gRPC-Stacks. Google patcht diese Projekte weiterhin, aber für Monate schauen weniger bezahlte externe Forschende darauf. Behandeln Sie Security Advisories zu diesen Bibliotheken als etwas, das Sie aktiv beobachten und umsetzen – nicht als etwas, das schon jemand anderes gefunden hat.
Zweitens: Ihr eigener Meldeweg ist als Nächstes dran. Wer ein Vulnerability-Disclosure-Programm oder eine öffentliche security@-Adresse betreibt, kann mit denselben Werkzeugen, die Google überrollt haben, ein dreiköpfiges Security-Team noch viel schneller zuschütten. Eine Warteschlange voller selbstbewusster, aber falscher Meldungen kostet nicht nur Zeit – genau so geht eine echte, ausnutzbare Meldung unter.
Drittens: In der EU kann eine ignorierte Meldung zum Compliance-Problem werden. Der Cyber Resilience Act erwartet von Herstellern von Softwareprodukten eine Richtlinie zur koordinierten Offenlegung von Schwachstellen und die Bearbeitung eingehender Meldungen; seine Meldepflichten für aktiv ausgenutzte Schwachstellen gelten seit dem 11. September 2026. „Wir wurden mit KI-Spam überflutet“ erklärt keine übersehene Meldung. Triage-Kapazität gehört deshalb in dieselbe Planung wie Patch-Kapazität.
Was ist jetzt zu tun?
- Exposition erfassen. Listen Sie anhand Ihrer SBOM oder Dependency-Manifeste alle Dienste mit exakten Versionen auf, die Go-Module, Angular, mit Bazel gebaute Artefakte oder Protocol Buffers ausliefern.
- Advisories beobachten statt auf Bounties zu hoffen. Abonnieren Sie die Go-Schwachstellendatenbank, GitHub Security Advisories und OSV-Feeds für diese Abhängigkeiten und leiten Sie sie in das Alerting, das Ihr Bereitschaftsteam ohnehin liest.
- Die Hürde für Meldungen erhöhen. Verlangen Sie eine konkret betroffene Version, Reproduktionsschritte und einen Proof of Concept. Ein strukturiertes Formular filtert weit mehr Rauschen als eine freie E-Mail-Adresse.
- Automatisch vorprüfen. Lassen Sie einen ersten Durchlauf prüfen, ob die genannten Dateien, Funktionen und Versionen überhaupt existieren, bevor ein Engineer Zeit investiert. Halluzinierte Codepfade sind das häufigste Erkennungszeichen.
- Das Signal schützen. Richten Sie eine Überholspur für bekannte Forschende und Kunden ein, veröffentlichen Sie Scope und Kontakt in der security.txt und messen Sie den Anteil gültiger Meldungen, damit Sie merken, wenn die Warteschlange zu kippen beginnt.
Häufig gestellte Fragen
Was hat Google pausiert?
Google hat neue Einreichungen für sein Open Source Software Vulnerability Rewards Program (OSS VRP) pausiert, das Bug-Bounty für von Google betreute Open-Source-Projekte wie Go, Angular, Bazel, Protocol Buffers und Fuchsia. Die Pause gilt seit dem 1. Oktober 2026. Google begründet sie mit einem erheblichen Anstieg automatisierter Einreichungen, von denen die große Mehrheit nicht gültig war.
Wie lange dauert die Pause des OSS VRP?
Ein Enddatum gibt es nicht. Google überarbeitet das Programm und will im ersten Quartal 2027 ein Update geben. Meldungen, die vor dem 1. Oktober 2026 eingereicht wurden, sind laut BleepingComputer und Help Net Security nicht betroffen.
Können Forschende Fehler in Googles Open-Source-Projekten noch melden?
Ja, über andere Kanäle. Das Patch Rewards Program zahlt weiterhin bis zu 15.000 US-Dollar für wirkungsvolle Sicherheitsfixes, und Fehler in Open-Source-Repositories von Google Cloud mit Auswirkung auf Cloud-Produkte können an das Cloud VRP gehen. Schwachstellen lassen sich weiterhin an die Maintainer melden; pausiert ist nur der bezahlte Prämienweg für Produktschwachstellen.
Werden Go, Angular oder Protocol Buffers dadurch unsicherer?
Nicht unmittelbar. Google pflegt und patcht diese Projekte weiter, und die eigenen Security-Teams arbeiten weiter daran. Praktisch fällt ein bezahlter Anreiz für externe Forschende weg. Teams, die diese Bibliotheken einsetzen, sollten sich daher auf eigenes Dependency-Scanning und Advisory-Monitoring stützen, statt davon auszugehen, dass Bug-Bounty-Jäger Probleme zuerst finden.
Wie schützen wir unser eigenes Disclosure-Programm vor KI-Spam?
Verlangen Sie einen reproduzierbaren Proof of Concept gegen eine benannte Version, nutzen Sie ein strukturiertes Formular, veröffentlichen Sie einen klaren Scope in security.txt und Ihrer Richtlinie, und prüfen Sie Meldungen automatisch auf fehlende Reproduktionsschritte oder halluzinierte Codepfade, bevor ein Engineer sie liest. Halten Sie eine Überholspur für Meldende mit nachgewiesener Erfolgsbilanz frei und messen Sie, wie viele Meldungen sich als gültig erweisen.
Quellen
Google Bug Hunters — Open Source Software Vulnerability Reward Program rules
TechCrunch — Google froze its open source bug bounty program due to a ‘significant rise’ in AI submissions (Oct 4, 2026)
BleepingComputer — Google halts open-source bug bounty program amid AI spam surge
Help Net Security — AI slop submissions force Google to freeze its open-source bug bounty