Google begint bugbountyprogramma voor eigen opensourcesoftware

Google begint een nieuw bugbountyprogramma voor zijn eigen opensourcesoftware. Het bedrijf voegt projecten als programmeertaal Golang en Angular toe aan het bestaande, zelfbeheerde bugbountyprogramma. Ook externe software valt binnen de scope.

Google schrijft dat het al zijn openbare repo's onderbrengt als apart onderdeel van het Vulnerability Rewards Program. Dat is Googles eigen bugbountyprogramma. VRP is onderverdeeld in verschillende onderdelen, zoals een programma voor apps in de Play Store, maar ook een apart programma voor apps van derde partijen. Nu komt daar ook het Google OSS-programma bij. Het bedrijf noemt bij de scope geen specifieke lijst, maar het bedrijf zegt dat 'alle publieke repositories in GitHub-organisaties van Google en bepaalde repositories in andere platformen' binnen die scope vallen.

Wel noemt Google een aantal projecten waarvan de impact groter is dan bij anderen. Daarvoor geldt ook een veel hogere beloning. Het gaat om Bazel, Angular, Golang, Fuschia en structuurplatform Protocol Buffers. Die projecten vallen binnen de hoogste tier van beloningen. Die leveren tussen de 500 en 31.137 dollar op. Dat laatste geldt voor een bug waarmee andere producten in een ontwikkelketen kunnen worden aangevallen. Ook is er een tier voor standaardprojecten, waar de beloningen uiteenlopen van 101 tot 13.137 dollar. De laagste tier is bedoeld voor bugs in repo's die niet meer worden bijgehouden of erg klein zijn. Daarvoor deelt Google geen beloning uit.

Google wil met name dat onderzoekers zich richten op apps die de supplychain kunnen raken. Dat moeten bugs zijn waarmee de broncode van software kan worden aangepast in de main branch van een repo, of waarbij bijvoorbeeld cryptografische sleutels kunnen worden gestolen.

Opvallend is dat het nieuwe bugbountyprogramma de mogelijkheid biedt om kwetsbaarheden in dependencies van derde partijen aan te dragen. Daarbij zegt Google dat onderzoekers wel eerst de originele ontwikkelaars van die software moeten aanspreken.

Type bug	Belangrijke projecten	Standaard projecten	Projecten met lage prioriteit
Supplychainkwetsbaarheden	$ 3.133,7 - $ 31.337	$ 1.337 - $ 13.337
Productkwetsbaarheden	$ 500 - $ 7.500	$ 101 - $ 3.133,7	-
Andere kwetsbaarheden	$ 1.000	$ 500	-

Reacties (11)

[ari3]

Ik vind de beloningen nogal aan de lage kant gezien de benodigde expertise en tijdsbesteding. Stel je bent competent om dit te doen dan ga je veel tijd besteden aan bugs zoeken zonder zekerheid van vergoeding voor je tijd.

Het is daarmee een vorm van gratis werken. De mensen die bugs vinden worden (onder)betaald, maar de vele andere mensen die wel gespeurd hebben maar niets vonden (of niet als eerste vonden) krijgen niets. Dat is niet alleen zuur, maar ook immoreel omdat checken van code wel waarde heeft voor Google: het zegt namelijk dat de gecontrolleerde code waarschijnlijk veilig is.

Daarnaast, stel iemand vindt een bug, wat verhindert Google dan om te zeggen dat iemand anders of zijzelf het ook al gevonden hebben en de bounty niet uit te betalen? De beoordeling en toekenning van bounties is niet transparant.

[CAPSLOCK2000]

Ik zou het zelf meer zien als een motivatie om bugs die je toevallig tegenkomt netjes te melden.

Zelf meld ik bugs/gaten die ik vind/oplos vooral om mezelf te helpen, zodat ik er geen last meer van heb, en als dank/bijdrage aan de auteur/community die de software heeft geproduceerd. Mijn motivatie is echter vrij beperkt en daar ben ik vast niet de enige in. Een kleine beloning in het vooruitzicht zou best helpen om net wat meer moeite te doen. Of dat nu 100 of 200 euro is maakt mij niet heel veel uit, het gaat meer om de waardering dan dat ik er rijk van zou willen worden.

Ik denk dat ik de 'kans' op een beloning belangrijker vind dan de hoogte. Liever een grote kans op een kleine belonging voor een kleine moeite dan een kleine kans op een grote belonging waar ik wel eerst veel moeite voor moet doen.
De impact van security bugs is vaak maar moeilijk in te schatten dus is het beter om ook dingen te melden die klein lijken. Andersom is veel vervelender, dat je alleen grote meldingen krijgt die meestal niks blijken te zijn. Dat is vooral heel veel teleurstelling voor mensen die dachten goed bezig te zijn.

Actief zoeken naar bugs doe ik niet. Althans niet prive want het hoort wel bij mijn werk en het is het veruit moeilijkste dat ik doe. Als je daar een beetje goed in bent dan zal je geen moeite hebben om een baan te vinden waar je dat full-time kan doen voor een prachtig salaris. Daarom maak ik me niet zo'n zorgen over uitbuiting.

Als iemand uit eigen beweging op zoek gaat naar bugs zie ik dat als vrije keuze. Zelf ontvang ik ook wel eens meldingen en een flink deel daarvan is afkomstig van jonge mensen die ervaring of reputatie proberen op te bouwen. Er zijn er zelfs die het als huiswerk doen voor hun opleiding tot "ethical hacker" of zo iets*. Over gebruiken die de "hagel" methode waarbij ze heel veel kleine dingen tegelijk lanceren in de wetenschap dat maar een klein deel blijft plakken.

* Wat ooit leidde tot de pijnlijke conversatie: "Deze code is zo lek dat die als trainingsmateriaal wordt gebruikt door een Pakistaanse school voor hackers."

[ajsietsma]

Op zich is 30k net zo veel als voor Chrome. $500-7.500 is wel rijkelijk minder inderdaad.

Maar vorig jaar is er een record hoeveelheid van $8.7 miljoen uitgekeerd, dus hoewel de firma google het best zal kunnen lijden, kan ik me ergens wel voorstellen dat ze het enigszins willen beperken. Zeker omdat software van derden ook meegenomen wordt.

Daarnaast is het natuurlijk niet zo dat mensen dit soort dingen alleen maar uitvinden omdat ze actief naar exploits opzoek zijn. Wil best geloven dat mensen actief opzoek zijn naar supplychain exploits, maar kan me ook goed voorstellen dat mensen soms gewoon wat geks tegen komen terwijl ze aan iets anders aan het knutselen zijn.

[Bulkzooi]

Heeft iemand weleens het eerste patent van Google bekeken? Iets met filteren vermoed ik?

Maar ze kiezen express voor JavaScript; andere talen interesseert ze niks.

Daarvoor geldt ook een veel hogere beloning. Het gaat om Bazel, Angular, Golang, Fuschia en structuurplatform Protocol Buffers.

Bigtech Attitude on Steroïds, als je het mij vraagt.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 22:51]

[RoestVrijStaal]

Maar ze kiezen express voor JavaScript; andere talen interesseert ze niks.
[...]

Ooit wel eens gegoogled op Golang?

Het valt mij eerder op dat Dart niet in het prioriteiten-lijstje staat.

[Bulkzooi]

[...]
Ooit wel eens gegoogled op Golang?

Het valt mij eerder op dat Dart niet in het prioriteiten-lijstje staat.

Yep. Net als Rust start ik die workflows ook wel eens op. Maar da's aardig gevaarlijk dus je moet wel weten wat je doet.

Misschien had ik moet zeggen talen die niet onders Google's verantwoording vallen.

Misschien dat Google Dart gewoon ziet als bugged-by-design?

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 22:51]

[Bulkzooi]

Dit is niet opvallend.

Opvallend is dat het nieuwe bugbountyprogramma de mogelijkheid biedt om kwetsbaarheden in dependencies van derde partijen aan te dragen. Daarbij zegt Google dat onderzoekers wel eerst de originele ontwikkelaars van die software moeten aanspreken.

Dat heet verlegging en behoort bij de Unix-philosophie om alles uit te besteden.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 22:51]

[comecme]

Als je nou met je ene account zelf een bug intoduceert (het is immers open source), en die dan vervolgens als bug aanmeldt, dan is het makkelijk geld verdienen.

[RoestVrijStaal]

Dat zou mogelijk kunnen zijn, als de code slecht wordt gereviewed, of je maat maakt een PR en jij doet de review en merge ervan terwijl de rest op vakantie is. De kunst is om ervoor zorgen dat het nooit ontdekt gaat worden.

[RoestVrijStaal]

Google wil met name dat onderzoekers zich richten op apps die de supplychain kunnen raken. Dat moeten bugs zijn waarmee de broncode van software kan worden aangepast in de main branch van een repo, of waarbij bijvoorbeeld cryptografische sleutels kunnen worden gestolen.

Dus eigenlijk meer de tooling, libraries en frameworks om de codebase heen dan de codebase zelf. An sich ook logisch. Niemand staat te wachten op een "nieuwe" Log4Shell.

[aikebah]

[...]
Niemand staat te wachten op een "nieuwe" Log4Shell.

hmm.. beetje tweeslachtig.. nee ik ziet er niet echt op te wachten, maar ja graag, misschien dat de business dan ook een keer door krijgt dat investeren in technisch onderhoud van legacy code ook niet voor niets is... (wel graag in een oude vertrouwde legacy library dus, niet in de laatste bleeding edge hype lib waar iedereen op gesprongen is)