Google bug bounty pauzė: DI šlamštas užkemša saugumo kanalus

Google bug bounty istorija šią savaitę primena nemalonų dalyką: DI gali padėti saugumui, bet gali ir užkimšti vamzdžius.

Google Bug Hunters dar pavasarį rašė apie OSS VRP taisyklių griežtinimą dėl žemos kokybės ir haliucinuotų DI ataskaitų. Dabar Techmeme ir technologijų leidiniai fiksuoja dar griežtesnį žingsnį: produkto spragų teikimas OSS VRP programoje sustabdytas iki atnaujinimo 2027 metų pradžioje.

Saugumo komandai tai nėra teorinis triukšmas. Kiekvieną prastą ataskaitą kažkas turi perskaityti.

KAI GREITIS TAMPA TRIUKŠMU

DI leidžia greitai parašyti ataskaitą, sugeneruoti techninį paaiškinimą ir apsimesti užtikrintumu. Bėda ta, kad užtikrintas tekstas dar nereiškia tikros spragos.

Jei bug bounty programa gauna šimtus prastų pranešimų, tikri signalai pradeda skęsti. Saugumo žmogus tada nebe ieško rizikos. Jis valo šiukšles.

Čia kaip su elektroniniu paštu. Kai į dėžutę krenta per daug šlamšto, net svarbus laiškas pradeda atrodyti kaip dar vienas triukšmas.

PAMOKA SAUGUMO KOMANDOMS

Įmonėms reikia aiškiai apibrėžti, ką priima iš DI pagalba parengtų ataskaitų. Ne uždrausti įrankį, o reikalauti įrodymo: atkūrimo žingsnių, poveikio, pavyzdžio ir aiškaus ribojimo, kas patikrinta realiai.

DI gali padėti tyrėjui tvarkyti tekstą ar struktūruoti atradimą. Bet jei jis pakeičia patį tyrimą, gaunasi gražus dokumentas be turinio.

Saugume tokie dokumentai kainuoja laiką. O laikas ten dažnai yra tikras pinigas.

KĄ DARYTI VERSLUI

Jei turite vidinį incidentų ar klaidų raportavimą, verta įvesti paprastą filtrą: ką žmogus patikrino pats, kas sugeneruota su DI, kokie įrodymai pridėti.

Toks klausimas nebaudžia už DI naudojimą. Jis tik grąžina atsakomybę ten, kur ji turi būti: pas žmogų, kuris pateikia išvadą.

Nes saugumo kultūra prasideda ne nuo gražios ataskaitos. Ji prasideda nuo sakinio: „patikrinau, veikia taip“.

FAQ

Kas nutiko Google OSS VRP programai?

Google griežtina ir laikinai pertvarko dalį atvirojo kodo spragų atlygio programos, nes ją apkrovė nekokybiškos ir DI sugeneruotos ataskaitos.

Kodėl DI sugeneruotos ataskaitos pavojingos?

Jos gali atrodyti įtikinamai, bet neturėti realiai patikrintos spragos, todėl saugumo komandos gaišta laiką.

Kaip įmonėms tvarkytis su DI saugumo raportais?

Reikalauti atkūrimo žingsnių, įrodymų, poveikio aprašymo ir aiškaus pažymėjimo, kur DI buvo naudojamas.

Šaltinis: Google Bug Hunters.

Šią savaitę peržiūrėkite savo incidentų formą. Vienas laukelis „kas patikrinta praktiškai?“ gali sutaupyti daug triukšmo.