Google bezeichnete den Stopp als vorübergehend. Meldungen über Kompromittierungen der Lieferkette werden weiterhin angenommen, und vor dem 1. Oktober eingereichte Berichte sind nicht betroffen.

Die Regeln des Programms, das Open Source Software Vulnerability Reward Program (OSS VRP), tragen inzwischen einen entsprechenden Hinweis. Darin verpflichtet sich Google zu einer Aktualisierung im ersten Quartal 2027, während dieser Teil des Programms überarbeitet wird. Weder der Beitrag auf X noch der Hinweis nennt ein Datum, ab dem Meldungen zu Produktschwachstellen wieder angenommen werden. Offen bleibt auch, ob Google solche Meldungen weiterhin ohne Prämie entgegennimmt.

Als Produktschwachstelle gilt laut den Programmregeln ein Entwurfs- oder Implementierungsfehler in Googles quelloffener Software. Er muss die Vertraulichkeit oder Integrität von Nutzerdaten in Software, die mit diesem Code gebaut wurde, erheblich beeinträchtigen. Als Beispiele werden Speicherfehler in Parsern für Dateiformate und Path Traversal genannt.

Das Programm teilt Projekte anhand ihrer Sensibilität in vier Stufen ein. Nur für die beiden obersten — „flagship" und „important" — waren überhaupt Prämien für Produktschwachstellen ausgewiesen. Dieselbe Änderung, die den Hinweis einfügte, entfernte diese Beträge: 500 bis 7.500 US-Dollar für Flaggschiff-Projekte sowie 101 bis 3.133,7 US-Dollar für die Stufe „important". Veröffentlicht wurde sie am 30. September in Googles öffentlicher GitHub-Kopie der Regeln, einen Tag vor dem Beitrag auf X. Die vierte Stufe für Projekte mit niedriger Priorität hatte ohnehin keine ausgewiesenen Prämien.

Googles Liste der nach Stufen sortierten Repositorien, zuletzt Mitte September aktualisiert, nennt 26 Flaggschiff-Repositorien und 47 der Stufe „important". Zur obersten Stufe zählen Go, Angular, Flutter, Bazel und Protocol Buffers.

Ihre ausgewiesenen Prämien behalten Kompromittierungen der Lieferkette — also Fehler, über die sich der Quellcode eines Projekts oder dessen veröffentlichte Pakete manipulieren ließen. Das gilt ebenso für andere Sicherheitsprobleme, etwa abgeflossene Zugangsdaten mit Schreibrechten.

Wohin Meldungen jetzt gehen können

Googles Hinweis nennt drei Wege für Sicherheitsforscher:

  • Cloud VRP: Meldungen zu Produktschwachstellen können für einige Google-Cloud-Repositorien, die Google-Cloud-Produkte betreffen, weiterhin angenommen werden; der Hinweis benennt diese Repositorien jedoch nicht. Nach den Regeln des Cloud VRP wird ein Fehler in einem von Google Cloud gepflegten Open-Source-Repository, der Cloud-Produkte betrifft, höchstens als IT3b eingestuft. Das ist die Stufe für Zukäufe und Produkte niedrigerer Priorität; die Obergrenze gilt, sofern Googles Produktliste nichts anderes vorsieht.
  • Patch Rewards: Das Patch Rewards Program zahlt 100 bis 15.000 US-Dollar für Sicherheitspatches an den abgedeckten Projekten — nicht für Schwachstellenmeldungen. Die Maintainer eines Projekts müssen einen Patch annehmen und danach einen Monat lang im Amt bleiben, bevor er eingereicht werden kann. Ein Patch, der nur eine einzelne Schwachstelle behebt, wird im Einzelfall geprüft.
  • Weitere Prämienprogramme: Google bittet Forscher zu prüfen, ob ein Fehler etwas betrifft, das von einem anderen Prämienprogramm abgedeckt ist, und ihn dort einzureichen. Die OSS-VRP-Regeln empfehlen zudem, Fehler in Projekten mit engem Bezug zu Google Cloud oder KI-Produkten an das Cloud VRP oder das AI VRP zu melden.

Einzelne Projekte verweisen auf eigene Kanäle. Go nimmt Sicherheitsmeldungen per E-Mail an sein eigenes Sicherheitsteam entgegen. Eine Sicherheitsrichtlinie in Googles GitHub-Organisation leitet Melder an Googles Meldeadresse g.co/vulnz weiter. Angulars Sicherheitsrichtlinie nennt mit Stand 6. Oktober Angular weiterhin als Teil des OSS VRP, verweist Schwachstellenmeldungen an Googles Bug-Hunters-Seite und nennt keinen weiteren Kanal.

Frühere Einschränkungen gegen schwache Meldungen

Google hatte das OSS VRP im August 2022 gestartet. Im März 2026 begann das Unternehmen, für Meldungen in einigen Stufen strengere Nachweise zu verlangen, um Einsendungen geringer Qualität auszufiltern. Ein bereits in das Projekt übernommener Patch gilt als anerkannte Nachweisform. Damals war das Programmteam über die geringe Qualität mancher KI-generierter Einsendungen besorgt, die vielfach erfundene Angaben dazu enthielten, wie sich eine Schwachstelle auslösen lasse.

Unabhängig davon ergänzte das Go-Projekt Anfang September seine Sicherheitsrichtlinie um einen Abschnitt zu Meldungen, die von großen Sprachmodellen (LLMs) erzeugt wurden. Melder werden gebeten, solche Berichte nicht ohne vorherige Prüfung und Filterung einzusenden. Die Richtlinie hält fest, LLMs seien gut darin, echte Sicherheitsfehler zu finden — und ebenso gut darin, nicht existierende zu melden. Wer große Mengen ungefilterter LLM-Ausgaben weiterleitet, wird für seine Funde nicht als Finder genannt.