Google onderbreekt beloningen voor OSS-productbugs na piek in ongeldige geautomatiseerde rapporten

Google is gestopt met het accepteren van productkwetsbaarheidsrapporten via zijn bugbounty-programma voor zijn open-sourcesoftware.

De wijziging, die sinds 1 oktober van kracht is, betekent dat onderzoekers daar niet langer tegen beloning beveiligingsfouten in de code van projecten als Go, Angular en Protocol Buffers kunnen indienen. Rapporten over compromitteringen in de toeleveringsketen worden nog steeds geaccepteerd, en rapporten die vóór 1 oktober zijn ingediend, worden niet beïnvloed.

Google noemde de stop tijdelijk in een bericht op X op 1 oktober en zei dat dit te wijten was aan “een aanzienlijke stijging van het aantal geautomatiseerde inzendingen, waarvan de overgrote meerderheid niet geldig is.”

De post vermeldde geen cijfers. Er werd niet vermeld of de inzendingen met AI-tools waren geproduceerd.

De regels van het programma, het Open Source Software Vulnerability Reward Program (OSS VRP) genoemd, bevatten nu een aankondiging van de stop. Het verplicht Google tot een update in het eerste kwartaal van 2027, terwijl het dit deel van het programma herwerkt.

Noch het bericht, noch de kennisgeving vermeldt een datum voor het opnieuw accepteren van rapporten over productkwetsbaarheden.

Volgens de regels is een productkwetsbaarheid een ontwerp- of implementatiefout in de open source-software van Google. Het moet een aanzienlijke invloed hebben op de vertrouwelijkheid of integriteit van gebruikersgegevens in software die met die code is gebouwd. Voorbeelden hiervan zijn geheugenbeschadiging in parsers van bestandsindelingen en het doorlopen van paden.

Het programma sorteert projecten in vier niveaus op basis van hun gevoeligheid. Alleen de top twee, vlaggenschip en belangrijk genoemd, hadden beloningen voor productkwetsbaarheden.

Door dezelfde wijziging waarmee de kennisgeving werd toegevoegd, werden de vermelde bedragen verwijderd: $500 tot $7.500 voor vlaggenschipprojecten en $101 tot $3.133,7 voor belangrijke projecten. Het werd op 30 september, een dag vóór de X-post, gepubliceerd in Google’s openbare GitHub-kopie van de regels.

Google’s lijst met gelaagde repository’s, voor het laatst bijgewerkt medio september, noemt 26 vlaggenschiprepository’s en 47 belangrijke. Het vlaggenschipniveau omvat Go, Angular, Flutter, Bazel en Protocol Buffers.

Compromissen in de toeleveringsketen, dit zijn fouten waardoor iemand met de broncode van een project of met gepubliceerde pakketten kan knoeien, behouden hun vermelde beloningen. Dat geldt ook voor andere beveiligingsproblemen, zoals gelekte inloggegevens die schrijftoegang verlenen.

Categorie

Vlaggenschip

Belangrijk

Standaard

Compromissen in de toeleveringsketen

$ 3.133,7 tot $ 31.337

$ 1.337 tot $ 13.337

$ 500 tot $ 3.133,7

Kwetsbaarheden van producten

Geen (was $ 500 tot $ 7.500)

Geen (was $ 101 tot $ 3.133,7)

Geen

Andere beveiligingsproblemen

$ 1.000

$ 500

Geen

Het vierde niveau, voor projecten met een lage prioriteit, kent geen vermelde beloningen.

Waar rapporten nu naartoe kunnen

In de mededeling van Google worden drie routes voor onderzoekers genoemd:

  • Cloud-VRP: Rapporten over productkwetsbaarheden kunnen nog steeds worden geaccepteerd voor sommige Google Cloud-opslagplaatsen die van invloed zijn op Google Cloud-producten, maar de melding vermeldt deze niet. Volgens de Cloud VRP-regels wordt een fout in een open source-repository die wordt onderhouden door Google Cloud en die invloed heeft op Cloud-producten, beoordeeld op maximaal IT3b. Dat is het niveau voor acquisities en producten met een lagere prioriteit, en de limiet is van toepassing tenzij de productlijst van Google anders aangeeft.
  • Patchbeloningen: Het Patch Rewards-programma betaalt $100 tot $15.000 voor beveiligingspatches voor de projecten die eronder vallen, niet voor rapporten over kwetsbaarheden. De beheerders van het project moeten een patch accepteren en een maand ter plaatse blijven voordat deze kan worden ingediend. Een patch die slechts één kwetsbaarheid verhelpt, wordt van geval tot geval beoordeeld.
  • Andere beloningsprogramma’s: Google vraagt ​​onderzoekers om te controleren of een fout iets treft dat onder een van zijn andere beloningsprogramma’s valt, en om dit daar in te dienen. De OSS VRP-regels moedigen ook aan om fouten in projecten die nauw verbonden zijn met Google Cloud of AI-producten te rapporteren aan de Cloud VRP of de AI VRP.

In de kennisgeving wordt niet vermeld of Google nog steeds meldingen van productkwetsbaarheid zal accepteren zonder beloning.

Sommige projectbeleidslijnen verwijzen naar andere kanalen. Go stuurt beveiligingsrapporten per e-mail naar zijn eigen beveiligingsteam. Een beveiligingsbeleid in de GitHub-organisatie van Google stuurt verslaggevers naar het meldingsadres van Google voor kwetsbaarheden, g.co/vulnz.

Het beveiligingsbeleid van Angular zegt vanaf 6 oktober dat Angular deel uitmaakt van de OSS VRP, kwetsbaarheidsrapporten naar de Bug Hunters-site van Google verzendt en geen ander kanaal noemt.

Eerdere beperkingen op rapporten van lage kwaliteit

Google lanceerde de OSS VRP in augustus 2022. In maart 2026 begon het sterker bewijs te eisen voor rapporten in sommige niveaus om rapporten van lage kwaliteit eruit te filteren. Een patch die al in het project is opgenomen, is een geaccepteerde vorm van bewijs.

InfoWorld meldde destijds dat het team van het programma zich zorgen maakte over de lage kwaliteit van sommige door AI gegenereerde inzendingen, waarvan er vele verzonnen details bevatten over hoe een kwetsbaarheid kon worden geactiveerd.

Daarnaast heeft het Go-project begin september een sectie over rapporten gegenereerd door grote taalmodellen (LLM’s) aan zijn beveiligingsbeleid toegevoegd. Het vraagt ​​verslaggevers om dergelijke rapporten niet te verzenden zonder ze eerst te bekijken en te filteren.

Volgens het beleid zijn LLM’s goed in het vinden van echte beveiligingsbugs en net zo goed in het melden van bugs die niet bestaan. Verslaggevers die grote hoeveelheden ongefilterde LLM-uitvoer doorsturen, worden niet gecrediteerd voor hun bevindingen.

Thijs Van der Does