Google obmedzil bug bounty pre open source po záplave automatizovaných hlásení

Google od 1. októbra 2026 prestal vo svojom programe Open Source Software Vulnerability Reward Program prijímať hlásenia zaradené ako produktové zraniteľnosti. Firma uvádza, že túto časť programu prepracuje a ďalšiu aktualizáciu poskytne v prvom štvrťroku 2027. Podľa verejného vyjadrenia citovaného médiami rozhodnutie nasledovalo po výraznom náraste automatizovaných podaní, z ktorých veľká väčšina nebola platná. Zmena ukazuje praktický problém rýchlo dostupných generatívnych nástrojov: dokážu zlacniť legitímnu bezpečnostnú analýzu, ale rovnako ľahko vytvárajú veľké množstvo presvedčivo znejúcich hlásení bez overiteľného dôkazu o zneužiteľnosti.

Nejde však o úplné zrušenie všetkých odmien za chyby v otvorenom softvéri Googlu. Aktuálne pravidlá OSS VRP naďalej opisujú prijímanie zraniteľností, ktoré môžu ohroziť integritu zdrojového kódu, zostavovania alebo distribúcie balíkov. V rozsahu zostávajú napríklad možnosti neoprávnene meniť hlavné vetvy repozitárov, kompromitovať zostavovacie prostredie, získať prihlasovacie údaje na publikovanie balíkov či ovplyvniť podpisové kľúče. Pozastavená je konkrétna kategória produktových zraniteľností, nie celý mechanizmus ochrany dodávateľského reťazca. Titulky hovoriace o zmrazení celého programu preto potrebujú túto dôležitú výhradu.

Keď lacné generovanie presunie náklady na overovateľa

Tradičné bug bounty funguje len vtedy, keď výskumník odovzdá dostatok dôkazov, aby správca projektu mohol problém reprodukovať, posúdiť jeho dosah a bezpečne opraviť. Jazykový model dokáže rýchlo prečítať zdrojový kód, označiť podozrivý vzor a vytvoriť formálne vyzerajúci report. Samotná podobnosť so známou triedou chyby však nedokazuje, že sa zraniteľná cesta dá v reálnom produkte dosiahnuť. Model môže prehliadnuť validáciu na inej vrstve, zameniť verziu knižnice, predpokladať neexistujúcu konfiguráciu alebo vymyslieť správanie závislosti.

Ekonomika takéhoto spamu je asymetrická. Vygenerovanie desiatok hypotéz stojí odosielateľa málo času a výpočtov, zatiaľ čo každú z nich musí niekto na strane projektu otvoriť, pochopiť a často manuálne vyvrátiť. Aj nekvalitný report môže obsahovať úryvok kódu, technický slovník a vierohodný scenár útoku, takže ho nemožno bezpečne odmietnuť iba podľa štýlu. Ak sa počet podaní zvýši rýchlejšie než kapacita triážneho tímu, výsledkom nie je viac opravených chýb, ale dlhší rad, únava správcov a pomalšia reakcia na skutočné zraniteľnosti.

Pravidlá Googlu už preto kladú dôraz na demonštráciu reálneho vplyvu. Pri chybách dodávateľského reťazca nestačí ukázať, že škodlivý kód by sa spustil po vedomom schválení externého pull requestu. Výskumník musí preukázať cestu, ktorá obíde požadované schválenie, napríklad nesprávnou konfiguráciou alebo chybou typu time-of-check to time-of-use. Pri zraniteľnostiach v závislostiach má byť problém najprv oznámený ich vlastníkovi a hlásenie Googlu musí ukázať, že sa dá vyvolať aj v konkrétnom projekte Googlu. Ide presne o druh dôkazov, ktorý oddeľuje nález od automaticky vytvorenej domnienky.

Zúženie programu nie je zákaz AI vo výskume

Dostupné podklady neukazujú, že by Google plošne zakázal používanie umelej inteligencie pri hľadaní chýb. Rozhodujúca je kvalita a reprodukovateľnosť výstupu, nie nástroj, ktorým výskumník prišiel k hypotéze. AI môže pomôcť pri prehľadávaní rozsiahleho repozitára, sledovaní toku dát, tvorbe testov alebo porovnávaní opravených a zraniteľných verzií. Pred odoslaním však musí človek alebo spoľahlivý validačný systém potvrdiť dosiahnuteľnosť chybného kódu, zostaviť minimálny reprodukčný príklad a vysvetliť konkrétny bezpečnostný dosah.

Pre bezpečnostné tímy je to signál, že nestačí pridať generatívny model pred existujúci formulár. Potrebná je technická prijímacia brána: automatické zostavenie dotknutej verzie, spustiteľný proof of concept v izolovanom prostredí, kontrola duplicitných hlásení, presná identifikácia commitu a strojovo overiteľné očakávané správanie. Pri pamäťových chybách môže pomôcť reprodukcia cez existujúci fuzzovací cieľ; pri aplikačnej logike test, ktorý pred opravou zlyhá a po nej prejde. Takéto požiadavky nezaručia pravdivosť každého podnetu, ale presunú časť nákladov na toho, kto tvrdenie vytvára.

Dôsledky pocítia aj správcovia menších open-source projektov, ktorí nemajú triážny tím Googlu. Automatizované hlásenia môžu vyzerať ako bezplatný audit, no bez prísnejšieho vstupného filtra sa menia na ďalšiu prevádzkovú záťaž. Projekty môžu vyžadovať presné kroky reprodukcie, verziu prostredia, test zneužiteľnosti a vyhlásenie, ktoré časti reportu boli automaticky generované. Užitočné je oddeliť súkromný kanál pre potenciálne zraniteľnosti od bežného issue trackera, aby sa nepotvrdené tvrdenia nezverejňovali skôr, než ich správca preverí.

Čo sa mení pre výskumníkov

Výskumníci, ktorí sa venovali produktovým zraniteľnostiam v otvorených projektoch Googlu, musia teraz vybrať vhodnejší kanál. Pravidlá odkazujú na Google Cloud VRP pri niektorých cloudových repozitároch, na AI VRP pri projektoch úzko previazaných s produktmi umelej inteligencie a na program odmien za opravy. Podania doručené pred 1. októbrom zmena podľa Googlu neovplyvňuje. Prakticky to znamená, že rovnaká technická chyba môže byť prijateľná alebo neprijateľná podľa toho, či zasahuje nasadený produkt, integritu dodávateľského reťazca alebo iba samostatnú open-source knižnicu.

Nové rozdelenie môže zlepšiť smerovanie kvalitných hlásení, no zároveň zvyšuje nároky na orientáciu výskumníkov. Hranica medzi knižnicou, cloudovou službou a AI produktom nebýva ostrá. Otvorený repozitár môže byť zároveň súčasťou prevádzkovanej služby a jeho chyba môže mať iný dosah v každom prostredí. Google preto bude musieť pri avizovanej úprave programu jasne vysvetliť, ktoré prípady patria do jednotlivých kanálov a čo sa stane s podaním odoslaným na nesprávne miesto. Bez zrozumiteľného presmerovania môže prísnejší systém odradiť aj legitímnych výskumníkov.

Čo zatiaľ nevieme

Google nezverejnil počet automatizovaných podaní, podiel falošných pozitív ani množstvo práce, ktorú ich preverovanie spotrebovalo. Nie je preto možné nezávisle určiť rozsah problému alebo porovnať ho s predchádzajúcimi rokmi. Nevieme ani to, či pripravovaný model zavedie povinné reprodukčné testy, reputačné limity, poplatky proti spamu alebo automatickú validáciu. Tvrdenie, že väčšina automatizovaných hlásení bola neplatná, pochádza z vyjadrenia firmy a bez podrobnejších dát ho nemožno rozložiť podľa nástrojov či typov zraniteľností.

Isté je už teraz to, že generatívna AI mení úzke miesto bezpečnostného výskumu. Nedostatkom prestáva byť iba schopnosť vytvoriť hypotézu o chybe; čoraz cennejšie je lacno a dôveryhodne dokázať, že hypotéza platí. Programy odmien budú musieť odmeňovať reprodukovateľný dôkaz a opravu, nie objem technicky znejúceho textu. Pre vývojárov AI bezpečnostných nástrojov je to konkrétna produktová požiadavka: model nemá iba pomenovať potenciálnu zraniteľnosť, ale dodať overiteľnú stopu od vstupu cez chybnú cestu až po preukázaný vplyv.