Google setzt Produktmeldungen im Open-Source-Bug-Bounty-Programm aus

Google hat die Meldung von Produkt-Schwachstellen in seinem Open-Source-Bug-Bounty-Programm ausgesetzt, eine vorübergehende Maßnahme, die am 1. Oktober in Kraft trat. Das Unternehmen begründete die Änderung mit einem deutlichen Anstieg automatisierter Einreichungen, von denen die überwiegende Mehrheit ungültig ist. Forscher können nun keine Sicherheitslücken mehr im Code weit verbreiteter Open-Source-Projekte wie Go, Angular und Protocol Buffers an das Open Source Software Vulnerability Reward Program, bekannt als OSS VRP, melden und dafür eine Belohnung erhalten. Meldungen zu Supply-Chain-Kompromittierungen werden weiterhin angenommen, und Meldungen, die vor dem 1. Oktober eingereicht wurden, sind nicht betroffen.

Google bezeichnete die Aussetzung in einem Beitrag auf X am 1. Oktober als vorübergehend, nannte jedoch keine Zahlen und gab nicht an, ob die automatisierten Einreichungen mit KI-Tools erstellt wurden. Die öffentlichen Regeln des Programms enthalten nun einen Hinweis auf die Aussetzung. Google verpflichtet sich zu einem Update im ersten Quartal 2027, während dieser Teil des Programms überarbeitet wird, aber weder der Beitrag noch der Hinweis nennen ein Datum für die Wiederaufnahme der Annahme von Produkt-Schwachstellenmeldungen.

Gemäß den Regeln ist eine Produkt-Schwachstelle ein Design- oder Implementierungsfehler in Googles Open-Source-Software. Um sich zu qualifizieren, muss der Fehler die Vertraulichkeit oder Integrität von Nutzerdaten in Software, die mit diesem Code erstellt wurde, erheblich beeinträchtigen. Beispiele sind Speicherkorruption in Dateiformat-Parsern, eine Art von Fehler, bei dem ein Programm Daten an die falsche Stelle schreibt, und Path Traversal, das einem Angreifer den Zugriff auf Dateien außerhalb eines vorgesehenen Ordners ermöglicht. Google unterteilt seine Open-Source-Projekte basierend auf der Sensibilität in vier Stufen. Nur die beiden obersten Stufen, genannt Flagship und Important, hatten ausgewiesene Belohnungen für Produkt-Schwachstellen. Die Regeländerung, die den Aussetzungshinweis hinzufügte, entfernte auch diese Beträge: Flagship-Projekte boten zuvor zwischen 500 und 7.500 US-Dollar, und Important-Projekte boten zwischen 101 und 3.133,70 US-Dollar. Das Update wurde am 30. September, einen Tag vor dem X-Beitrag, in Googles öffentlicher GitHub-Kopie der Regeln veröffentlicht. Googles gestaffelte Repository-Liste, zuletzt Mitte September aktualisiert, nennt 26 Flagship-Repositories und 47 Important-Repositories. Die Flagship-Stufe umfasst Go, Angular, Flutter, Bazel und Protocol Buffers.

Supply-Chain-Kompromittierungen, also Schwachstellen, die es jemandem ermöglichen könnten, den Quellcode oder veröffentlichte Pakete eines Projekts zu manipulieren, behalten ihre ausgewiesenen Belohnungen. Sie reichen von 3.133,70 bis 31.337 US-Dollar für Flagship-Projekte, 1.337 bis 13.337 US-Dollar für Important-Projekte und 500 bis 3.133,70 US-Dollar für Standard-Projekte. Andere Sicherheitsprobleme, wie geleakte Zugangsdaten, die Schreibzugriff gewähren, zahlen weiterhin 1.000 US-Dollar für Flagship und 500 US-Dollar für Important. Die vierte Stufe, für Projekte mit niedriger Priorität, hat keine ausgewiesenen Belohnungen.

Googles Hinweis nennt drei Wege für Forscher, die Produkt-Schwachstellenmeldungen eingereicht hätten. Produkt-Schwachstellenmeldungen können für einige Google Cloud-Repositories, die Google Cloud-Produkte betreffen, weiterhin angenommen werden, aber der Hinweis nennt sie nicht. Gemäß den Cloud-VRP-Regeln wird eine Schwachstelle in einem von Google Cloud gepflegten Open-Source-Repository, die Cloud-Produkte betrifft, höchstens als IT3b eingestuft, die Stufe für Akquisitionen und Produkte mit niedrigerer Priorität. Das Patch Rewards Program zahlt 100 bis 15.000 US-Dollar für Sicherheits-Patches für Projekte, die es abdeckt, nicht für Schwachstellenmeldungen; die Maintainer eines Projekts müssen einen Patch akzeptieren und er muss einen Monat lang bestehen bleiben, bevor er eingereicht werden kann. Google bittet Forscher außerdem zu prüfen, ob eine Schwachstelle etwas betrifft, das von einem anderen Belohnungsprogramm abgedeckt wird, wie dem Cloud VRP oder dem AI VRP, und sie dort einzureichen. Der Hinweis sagt nicht, ob Google Produkt-Schwachstellenmeldungen ohne Belohnung weiterhin annimmt.

Einige Projektrichtlinien verweisen auf andere Kanäle. Das Go-Projekt nimmt Sicherheitsmeldungen per E-Mail an sein eigenes Sicherheitsteam entgegen. Eine Sicherheitsrichtlinie in Googles GitHub-Organisation leitet Melder an Googles Adresse für Schwachstellenmeldungen weiter, g.co/vulnz. Die Sicherheitsrichtlinie von Angular besagt mit Stand vom 6. Oktober, dass Angular Teil des OSS VRP ist und Schwachstellenmeldungen an Googles Bug Hunters-Website sendet, ohne einen anderen Kanal zu nennen.

Google startete das OSS VRP im August 2022. Im März 2026 begann das Programm, für einige Stufen stärkere Nachweise für Meldungen zu verlangen, um minderwertige Einreichungen herauszufiltern; ein bereits in das Projekt gemergter Patch ist eine akzeptierte Form des Nachweises. InfoWorld berichtete damals, dass das Programmteam besorgt über minderwertige KI-generierte Einreichungen war, von denen viele erfundene Details darüber enthielten, wie eine Schwachstelle ausgelöst werden könnte. Unabhängig davon fügte das Go-Projekt Anfang September einen Abschnitt über Meldungen, die von großen Sprachmodellen (Large Language Models, LLMs) generiert wurden, zu seiner Sicherheitsrichtlinie hinzu. Es bittet Melder, solche Meldungen nicht ohne vorherige Überprüfung und Filterung zu senden. Die Richtlinie besagt, dass LLMs gut darin sind, echte Sicherheitsfehler zu finden, und ebenso gut darin, nicht existierende zu melden. Melder, die große Mengen ungefilterter LLM-Ausgaben weiterleiten, werden für ihre Funde nicht anerkannt.

Für Website-Betreiber, Entwickler und IT-Teams bedeutet die Aussetzung, dass ein Belohnungsstrom für Produktschwachstellen in weit verbreiteten Google-Open-Source-Projekten vorübergehend geschlossen ist, aber sie ändert nichts an der Notwendigkeit, Abhängigkeiten aktuell zu halten. Open-Source-Komponenten wie Angular, Go und Protocol Buffers untermauern viele Websites, Webanwendungen und Cloud-Dienste; Sicherheits-Patches kommen weiterhin über die normale Projektwartung. Die praktische Reaktion besteht darin, die offiziellen Sicherheitskanäle der von Ihnen verwendeten Projekte zu beobachten, Updates zeitnah anzuwenden und eigene Schwachstellen-Scans zu verwenden, anstatt auf einen bezahlten Bericht zu warten. Für Website-Betreiber, deren Websites auf Open-Source-Komponenten angewiesen sind, bedeutet eine Aussetzung der Belohnungsmeldungen nicht, dass routinemäßiges Patchen aufhört; AEU Hosting bietet verwaltetes WordPress-Hosting mit durchgängiger Sicherheit, das Website-Betreibern helfen kann, Sicherheitsupdates und Härtung an einem Ort zu bündeln. Wenn Sie eine vermutete Schwachstelle entdecken, melden Sie sie über den dokumentierten Kanal des Projekts und vermeiden Sie die Weiterleitung ungeprüfter automatisierter Ausgaben, was genau das ist, was Google als Überlastung des Programms bezeichnet.