Google stoppt Open-Source-Bug-Bountys – automatisierte Meldungen überlasten die Prüfung

8. Oktober 2026 um 15:00|Autor: QUASA-Redaktion|4 Min. Lesezeit| 1

Seit dem 1. Oktober 2026 nimmt Google im Open Source Software Vulnerability Reward Program (OSS VRP) keine neuen Produktlückenberichte mehr an. Die Pause betrifft diese Kategorie des Prämienprogramms für Googles Open-Source-Projekte: Meldungen zu möglichen Kompromittierungen der Software-Lieferkette und bereits eingereichte Fälle bleiben unberührt. Für Forschende ist damit die Sicherheitswirkung eines Fundes entscheidend, bevor sie einen Meldeweg wählen.

Als Grund nennt Google laut IT Pro „a significant rise in automated submissions“; die große Mehrheit dieser Berichte sei ungültig. Für Produktlücken mit konkreten Auswirkungen auf manche Google-Cloud-Produkte kommt gegebenenfalls das Cloud VRP infrage. Eine Wiederaufnahme des pausierten Kanals ist nicht terminiert; für das erste Quartal 2027 ist ein Update angekündigt.

Die Pause trennt Produktlücken von Lieferkettenrisiken

Eine Produktlücke betrifft eine Schwachstelle in der Software selbst, etwa einen erreichbaren Fehler in der Verarbeitung von Eingaben mit Folgen für Nutzerdaten. Ein Lieferkettenrisiko betrifft dagegen die Integrität des Quellcodes, des Build-Prozesses oder der an Nutzer verteilten Pakete. Derselbe Repository-Name kann bei beiden Berichtstypen auftauchen. Entscheidend ist, welchen Angriffspfad der Fund tatsächlich belegt.

Nach der Änderung ergibt sich für die wichtigsten Fälle folgende Zuordnung:

Neue Produktlücke in Google OSS: Eine neue Einreichung als Produktlücke beim OSS VRP ist derzeit ausgesetzt. Die bloße Umbenennung des Berichts in eine andere Kategorie ändert daran nichts.
Kompromittierung der Lieferkette: Dieser Berichtstyp bleibt im OSS VRP offen, wenn der Fund dessen Geltungsbereich erfüllt und eine Manipulation von Quellcode, Build-Artefakten oder verteilten Paketen ermöglichen würde.
Bereits eingereichte Produktlücke: Die Pause ändert den Status eines vorhandenen Berichts nicht. Der Stichtag betrifft neue Einreichungen.
Auswirkung auf Google Cloud: Für manche Repositories kann das Cloud VRP zuständig sein, sofern der Fund ein Google-Cloud-Produkt tatsächlich betrifft. Eine Zugehörigkeit zu Googles Open-Source-Organisation allein genügt dafür nicht.
Proaktive Sicherheitsverbesserung: Das Patch Rewards Program belohnt geeignete Verbesserungen an Open-Source-Projekten. Es ist ein Weg für einen Sicherheitsbeitrag und kein Ersatzkanal für einen ungeprüften Lückenbericht.

Diese Wege sind voneinander getrennt, weil sie unterschiedliche Belege verlangen. Bei einer Produktlücke muss die Wirkung im betroffenen Produkt nachvollziehbar sein; bei einer Lieferkettenmeldung geht es um die Möglichkeit, die Herkunft oder Integrität später genutzter Software zu verändern. Ein Patch wiederum wird nach seinem Beitrag zur Sicherheit beurteilt. Die Zuständigkeit eines Programms ist noch keine Zusage für Anerkennung oder Prämienzahlung.

Automatisierte Funde scheitern oft an der Wirkung

Die Belastung der Prüfung war schon vor der aktuellen Pause Thema. Google Bug Hunters beschrieben in einem am 19. März 2026 veröffentlichten und im April ergänzten Regelupdate einen starken Anstieg KI-generierter Berichte. Darunter seien Meldungen mit erfundenen Auslösebedingungen sowie technisch richtige Hinweise auf Programmierfehler, deren Codepfad unerreichbar sei oder die im Sicherheitsmodell des Projekts kaum Wirkung hätten. Eine überzeugend formulierte Fehlerbeschreibung ersetzt also weder die Reproduktion noch den Nachweis eines realistischen Angriffs.

Die damalige Reaktion war abgestuft: Für Speicherfehler in besonders wichtigen Projekten verlangte das Programm genaue Reproduktionsschritte mit einem bestehenden OSS-Fuzz-Ziel oder einen bereits integrierten Patch. Bei weniger priorisierten Projekten entfielen Prämien und Anerkennung für Produktlücken; solche Berichte sollten auch nicht mehr von der Sicherheitseinheit geprüft werden. Die jetzige Pause zieht für neue Produktmeldungen eine breitere Grenze. Berichte über eine gefährdete Lieferkette bleiben eine eigene Kategorie, weil eine mögliche Veränderung von Quellcode oder Build-Artefakten eine andere Art von Sicherheitswirkung hat.

Der Engpass liegt bei der Validierung: Ein automatisiertes Werkzeug kann viele plausible Kandidaten ausgeben, aber bei jedem müssen Erreichbarkeit, betroffene Version, Ausnutzbarkeit und tatsächliche Folgen geklärt werden. Die Zahl der Meldungen allein verrät daher wenig über die Zahl verwertbarer Schwachstellen. Für den aktuellen Einschnitt ist keine absolute Eingangsmenge oder genaue Quote veröffentlicht; die Begründung spricht von einem starken Anstieg und einer großen Mehrheit ungültiger automatisierter Einsendungen.

Was für Meldestellen und Forschende daraus folgt

Bei Lieferkettenfunden ist der nachweisbare Weg zur Manipulation entscheidend. Wer lediglich zeigen kann, dass eine schädliche Änderung nach regulärer Freigabe durch Maintainer wirksam würde, beschreibt damit noch keinen Angriff, der diese Freigabe umgeht. Aussagekräftiger sind Belege für unbefugte Änderungen an einem Repository, an der Build-Umgebung oder an veröffentlichten Artefakten. Solche Details bestimmen, ob die weiterhin offene Kategorie sachlich passt.

Für eine Produktlücke mit Cloud-Bezug muss die Wirkung auf das konkrete Cloud-Produkt nachvollziehbar sein. Das bloße Vorkommen von Googles offenem Code in einem Projekt macht das Cloud VRP nicht zuständig. Für andere Produkte gelten jeweils deren eigene Programme; ein Bericht kann nur dann dorthin wechseln, wenn er die dort verlangte Wirkung zeigt. Wer statt einer Meldung einen Sicherheitsfix beisteuert, bewegt sich im Patch-Rewards-Bereich.

Für Betreiber eigener Meldeprogramme ergibt sich daraus eine konkrete Folgerung: Eine Eingabemaske, die betroffene Version, erreichbaren Codepfad, reproduzierbare Schritte und Sicherheitswirkung verlangt, verschiebt einen Teil der Vorprüfung zum Einreicher. Automatisch erzeugte Hinweise lassen sich so nach Beleglage sortieren, bevor menschliche Prüfer den Kontext rekonstruieren müssen. Welche Bedingungen künftig für neue Produktmeldungen im OSS VRP gelten, soll das angekündigte Update im ersten Quartal 2027 zeigen.

Lesen Sie auch: