Google zastavil odmeny za chyby: automatické hlásenia zahltili kontrolu

Google podľa BleepingComputer od 1. októbra 2026 neprijíma nové hlásenia produktových zraniteľností do Open Source Software Vulnerability Rewards Program (OSS VRP); firma tento krok spojila s výrazným nárastom automatizovaných podaní, z ktorých je podľa jej slov „the vast majority of which are not valid“. Hlásenia o ohrození dodávateľského reťazca a prípady odoslané pred pozastavením zostávajú v programe.

Uzavretý je príjem nových produktových nálezov v jednej kategórii, nie každá cesta k bezpečnostnej odmene. Ako uvádza TechCrunch, Google prisľúbil aktualizáciu v prvom štvrťroku 2027; tento termín zatiaľ neznamená opätovné otvorenie podaní. Výskumník s novým nálezom preto potrebuje rozlíšiť, či ide o produktovú zraniteľnosť, zásah do dodávateľského reťazca, dopad na Google Cloud alebo pripravenú opravu.

Hranica pozastavenia: chyba produktu v otvorenom kóde

Produktová zraniteľnosť sa týka návrhu alebo implementácie softvéru: zraniteľný parser, obídená bezpečnostná kontrola či chyba umožňujúca neoprávnený prístup sa prejaví pri používaní výsledného produktu. Pre nový nález tohto typu už OSS VRP neslúži ako kanál na získanie odmeny. Rozhodujúce je zaradenie chyby, nie to, či ju výskumník objavil ručne, fuzzingom alebo pomocou AI.

Pravidlá Google Bug Hunters vymedzujú produktové chyby ako problémy, ktoré podstatne zasahujú dôvernosť alebo integritu používateľských dát v softvéri postavenom na otvorenom kóde Googlu. Zahŕňajú napríklad chyby pri spracovaní súborov a sieťových protokolov, zlyhanie sanitizácie alebo prechod mimo povoleného adresára. Rovnaké pravidlá opisujú aj požiadavky na dôkaz a osobitnú kategóriu ohrozenia dodávateľského reťazca.

Automatizované podanie sa nerovná automaticky vymyslenému nálezu. Problém vzniká, keď opis tvrdí zneužiteľnosť bez overenia, že útočník dosiahne chybný kód a že následok má bezpečnostný význam. Kontrolór musí aj pri neplatnom podaní preveriť verziu, vstupy a scenár útoku; pri vysokom počte takých podaní sa kapacita na posudzovanie skutočných chýb míňa na vyvracanie nepodložených tvrdení. Tento náklad na kontrolu dopadá aj na výskumníkov s reprodukovateľným nálezom, ktorí teraz nemôžu využiť pozastavenú kategóriu.

Hlásenia o dodávateľskom reťazci zostávajú otvorené

V OSS VRP možno ďalej nahlásiť chybu, ktorá umožňuje zasiahnuť do zdrojového kódu Googlu, zostavenia alebo balíka distribuovaného používateľom. Príkladom je únik kľúča na zverejňovanie balíkov, možnosť upraviť hlavnú vetvu repozitára alebo zraniteľná konfigurácia automatizovaného zostavovania. Taký nález sa od produktovej chyby líši predmetom útoku: ohrozená je integrita softvéru ešte pred tým, než sa dostane k používateľovi.

Pri tomto kanáli nestačí ukázať na podozrivé nastavenie. Výskumník má vysvetliť, ako by sa útočník bez oprávnenia správcu dostal k úprave zdrojov alebo vydávaného balíka. Ak by škodlivá zmena prešla až po riadnom schválení správcom, ide o iný typ rizika; také hlásenie nemá rovnakú váhu ako preukázané obídenie kontroly. Konkrétny postup a hranica oprávnení sú preto podstatnejšie než všeobecné označenie „supply chain“.

Staršie produktové podania zostávajú v pôvodnom procese. Otvorený prípad sa kvôli zmene pravidiel pre nové hlásenia nemusí posielať znova cez iný program. Rovnako nemožno novú produktovú chybu premenovať na ohrozenie dodávateľského reťazca len preto, že sa nachádza v repozitári s automatizovaným zostavovaním; musí existovať reálna cesta k zmene kódu alebo vydaného balíka.

Cloud VRP a odmeny za opravy majú iný predmet

Cloud VRP môže prijať niektoré chyby v otvorených repozitároch Google Cloud, pokiaľ majú dopad na produkt Google Cloud. Samotná prítomnosť kódu v cloude alebo použitie cloudovej služby nestačí. Hlásenie musí pomenovať dotknutý produkt a ukázať, ako sa problém prejaví v jeho bezpečnosti; potom patrí do pravidiel Cloud VRP, nie do pozastavenej kategórie OSS VRP.

Patch Rewards Program odmeňuje bezpečnostné zlepšenia v projektoch, ktoré spadajú do jeho rozsahu. Jeho predmetom je oprava spolu s vysvetlením jej bezpečnostného prínosu. Neslúži ako náhradný formulár pre opis doteraz neodstránenej chyby. Výskumník s pripravenou úpravou kódu tak môže mať cestu k odmene, zatiaľ čo samotný nový nález produktovej zraniteľnosti zostáva v OSS VRP pozastavený.

Osobitný prípad predstavuje chyba v cudzej knižnici, ktorú projekt Googlu používa. Prvé oznámenie patrí správcovi zraniteľného balíka; pre súvislosť s projektom Googlu treba navyše predviesť, že chyba je v ňom skutočne dosiahnuteľná. Bez tohto prepojenia opisuje hlásenie riziko cudzieho projektu, nie doložený dopad na softvér Googlu.

Čo má obsahovať overiteľné hlásenie

Otvorené kanály naďalej stoja na dôkaze, ktorý možno zopakovať. Potrebná je presná adresa repozitára, dotknutá verzia alebo revízia, spustiteľný postup a skutočne pozorovaný výsledok. Samostatne treba opísať podmienky útoku a bezpečnostný dopad, aby tvrdenie o zraniteľnosti nestálo len na interpretácii automatického nástroja.

• Uveďte vstup, prostredie a kroky, pri ktorých sa prejav opakuje na aktuálnom zostavení.
• Priložte zostaviteľný dôkaz chyby a výpis pádu, ak existuje; oddeľte pozorovanie od odhadu možného následku.
• Ukážte, kto môže chybný kód alebo konfiguráciu vyvolať a aké oprávnenia na to potrebuje.
• Pri dodávateľskom reťazci doložte cestu k zmene zdroja, zostavenia alebo distribuovaného balíka.

Taký opis umožňuje bezpečnostnému tímu overiť nález bez domýšľania chýbajúcich krokov. Pri tvrdení vygenerovanom modelom je rozdiel zvlášť viditeľný: presvedčivý text môže pomenovať chybu, ktorá v danom kóde nie je dosiahnuteľná. O reprodukovateľnosti rozhoduje správanie programu a účinok na konkrétny produkt, nie istota formulácie v hlásení.

Ďalším zverejneným krokom má byť aktualizácia pravidiel pre pozastavenú kategóriu. Kým Google neurčí jej nový režim, nové podania zostávajú obmedzené rozsahom otvorených programov a preukázaným dopadom nálezu.

Prečítajte si aj:

• SuperFaktúra či iDoklad: rovnaký štart, iné limity automatizácie
• DeepL či Google Translate: pri slovenčine rozhoduje typ chyby, nie značka
• Kontrola uniknutého hesla: celé heslo nemusí opustiť prehliadač