DI ataskaitų lavina sustabdė „Google“ atvirojo kodo premijas

Pagal oficialias OSS VRP taisykles nuo 2026 m. spalio 1 d. „Google“ nebepriima naujų produkto pažeidžiamumų pranešimų per savo atvirojo kodo spragų atlygio programą ir žada apie šios programos dalies pertvarką pranešti 2027 m. pirmąjį ketvirtį. Tiekimo grandinės pažeidimų pranešimai tebėra priimami, o anksčiau pateikti produkto spragų pranešimai šio pakeitimo nepaveikti. Kada naujų produkto spragų priėmimas galėtų būti atnaujintas, nenurodyta.

„Google“ sustabdymą paaiškino žodžiais „a significant rise in automated submissions, the vast majority of which are not valid“, kuriuos cituoja ITPro. Bendrovė nepaskelbė šių ataskaitų skaičiaus ir neįvardijo, kokia spalio mėnesį gautų automatinių pranešimų dalis buvo sukurta naudojant DI. Tyrėjui pokytis reiškia aiškią ribą: net gerai pagrįstos naujos produkto spragos dabar nebegalima pateikti kaip OSS VRP produkto pažeidžiamumo.

Kodėl sustabdytas būtent produkto spragų priėmimas

2026 m. kovo 19 d. „Google“ OSS VRP pakeitimų įraše buvo aprašytas DI sugeneruotų pranešimų augimas: dalyje jų išgalvota, kaip spraga galėtų būti išnaudota, kitose nurodomas tikras kodo trūkumas, tačiau neparodomas pasiekiamas vykdymo kelias arba reikšmingas poveikis saugumui. Tuomet programa sugriežtino kai kurių produkto spragų įrodymų reikalavimus. Dabartinis sustabdymas yra platesnis: naujo šios kategorijos pranešimo OSS VRP nebepriima nepriklausomai nuo tyrėjo naudotų įrankių.

Produkto pažeidžiamumas čia reiškia „Google“ atvirojo kodo projekto projektavimo ar įgyvendinimo trūkumą, kuris iš esmės paveikia naudotojų duomenų konfidencialumą arba vientisumą programinėje įrangoje, naudojančioje tą projektą. Taisyklėse kaip pavyzdžiai minimos atminties pažaidos failų formatų analizatoriuose, netinkamas HTML valymas ir prieiga prie failų už leistino katalogo ribų. Vien įtartina kodo eilutė neparodo, ar trūkumą galima pasiekti naudojant naujausią projekto versiją ir kokį saugumo poveikį jis turi.

Kur nukreipti skirtingų rūšių radinius

Sprendimą lemia tai, ką radinys leidžia paveikti: programos veikimą, projekto išeities kodą, platinamą paketą ar atskirą „Google“ produktą. Šios ribos svarbios ir premijai, nes produkto spragos pranešimas bei saugumo pataisa yra skirtingi pateikimai. Lietuvos tyrėjui taikoma ta pati programų aprėptis kaip ir kitur.

• Nauja produkto spraga. Jei klaida glūdi atvirojo kodo projekto logikoje ir paveikia juo sukurtą programinę įrangą, naujas OSS VRP produkto pažeidžiamumo pranešimas šiuo metu nepriimamas. Radinio nereikėtų vadinti tiekimo grandinės pažeidimu vien tam, kad jis patektų į atvirą kategoriją. Atsakingo atskleidimo galimybė priklauso nuo konkretaus projekto saugumo politikos, tačiau ji savaime nesuteikia teisės į OSS VRP premiją.
• Tiekimo grandinės pažeidimas. Ši OSS VRP kategorija lieka atvira, kai trūkumas leidžia paveikti „Google“ projekto išeities kodą, kūrimo procesą ar naudotojams platinamą artefaktą. Taisyklėse minimos pažeidžiamos „GitHub Actions“ konfigūracijos, paketų publikavimo prisijungimo duomenys ir pasirašymo raktai. Reikia parodyti, kaip pašalinis veikėjas pasiektų pakeitimą; pakeitimas, kuris įsigaliotų tik prižiūrėtojui patvirtinus užpuoliko užklausą, vertinamas kaip vidinė rizika.
• „Google Cloud“ produkto spraga. Kai kurių su „Google Cloud“ produktais susijusių saugyklų produkto pažeidžiamumų pranešimai gali būti priimami per atskirą „Cloud VRP“. Tyrėjui reikia susieti saugykloje rastą trūkumą su paveiktu debesijos produktu ir patikrinti tos programos aprėptį. Vien tai, kad saugykla priklauso „Google“ ar naudoja debesijos paslaugas, priėmimo negarantuoja.
• Saugumo pataisa. „Patch Rewards Program“ yra kelias už tinkamų „Google“ atvirojo kodo projektų saugumo gerinimą pateikiant pataisą. Spragos hipotezė arba vien ataskaita nėra pataisa. Šios programos sąlygos ir tinkamų projektų aprėptis turi būti vertinamos atskirai nuo sustabdytos OSS VRP produkto spragų kategorijos.

Taisyklėse dar palikta „Other security issues“ kategorija, skirta su projekto saugumu susijusiems radiniams, kurie neatitinka techninio pažeidžiamumo apibrėžimo, pavyzdžiui, nutekėjusiems rašymo teises suteikiantiems prisijungimo duomenims. Projektams, glaudžiai susijusiems su „Google“ DI produktais, nurodomas ir „AI VRP“ kelias. Abiem atvejais kategoriją lemia realiai paveiktas turtas ir konkrečios programos taisyklės.

Kokie įrodymai atskiria radinį nuo automatinio triukšmo

Vis dar priimamos kategorijos ataskaitoje turi būti pakankamai duomenų radiniui pakartoti: paveiktos saugyklos adresas, programinės įrangos versija, tikslūs atkūrimo veiksmai, su naujausia versija veikiantis demonstracinis pavyzdys ir aiškiai aprašytas saugumo poveikis. Jei radinys sukelia programos gedimą, taisyklės prašo pridėti gedimo išrašą, kai jis prieinamas. Tokie duomenys leidžia vertintojui tikrinti konkretų veikimo kelią, o ne spėti, ką turėjo omenyje automatiškai parašytas paaiškinimas.

Tiekimo grandinės radiniui ypač svarbios užpuoliko pradinės teisės ir kelias iki kodo ar platinamo paketo pakeitimo. Tarkime, nesaugi kūrimo konfigūracija savaime dar neįrodo, kad pašalinis asmuo gali pakeisti leidžiamą artefaktą. Ataskaitoje turėtų būti parodyta, kuris nepatikimas įvesties taškas pasiekia kūrimo eigą, kokias teises jis suteikia ir kokį rezultatą būtų galima pakeisti. Jei veiksmui būtinas prižiūrėtojo patvirtinimas, tą sąlygą reikia įvardyti.

DI sugeneruota hipotezė gali būti tyrimo pradžia, bet pranešime turi būti žmogaus patikrinti faktai. Reikia įsitikinti, kad minima funkcija egzistuoja aktualioje versijoje, pažeidžiamas kodas pasiekiamas nurodytomis sąlygomis, o numatomas poveikis atitinka projekto saugumo modelį. Tai svarbu ir nukreipiant radinį į kitą programą: tvarkingai parašytas tekstas nepakeičia atkuriamo pažeidžiamumo.

Ką pakeitimas reiškia tyrėjams

Sąžiningai naujas produkto spragas tikrinę tyrėjai prarado įprastą OSS VRP pateikimo kelią kartu su automatinėmis, nepagrįstomis ataskaitomis. Kokybiškesni įrodymai šios kategorijos neatveria, tačiau jie tebėra būtini tiekimo grandinės radiniams ir pranešimams, kurie pagal savo poveikį patenka į kitas atlygio programas. Anksčiau pateiktų bylų statusas dėl pakeitimo nesikeičia.

Kitas konkretus etapas yra žadėtas pranešimas apie OSS VRP produkto spragų dalies pertvarką. Iki jo tyrėjui tenka skirti atvirą tiekimo grandinės kategoriją nuo uždarytos produkto spragų kategorijos ir pagal paveiktą produktą vertinti kitus galimus pateikimo kelius.

Taip pat skaitykite:

• Atšaukėte „Google“ programos prieigą: jos nukopijuoti duomenys lieka
• „DeepL“ ar „Google Translate“: taisyklinga lietuvių kalba dar nėra tiksli
• Pašalinote rezultatą iš „Google“: pats puslapis internete vis tiek lieka