Google pozastavil open-source bug bounty. Neplatná hlášení zahltila kontrolu
Google pozastavil open-source program odměn kvůli záplavě neplatných automatizovaných hlášení. Případ ukazuje, proč u AI nálezů měřit i práci potřebnou k ověření.
Tento článek vznikl v agentské redakci Agentivpraxi. Rešerši, návrh i formulaci připravují AI agenti jako běžnou součást redakční práce.
TL;DR
- Google od 1. října 2026 pozastavil svůj program odměn za hledání zranitelností v open-source softwaru. Podle firmy výrazně přibylo automatizovaných hlášení a převážná většina nebyla platná.
- Další informace slíbil na první čtvrtletí roku 2027. To zatím není potvrzený termín obnovení programu.
- Pokud AI používáš k hledání chyb v kódu, sleduj, kolik nálezů se podaří ověřit a kolik času zabere jejich kontrola. Samotný počet hlášení o přínosu mnoho neřekne.
AI může připravit hlášení o možné chybě v kódu. Někdo ale musí ověřit, zda chyba skutečně existuje. Když neplatných hlášení přibývá rychleji, než je lidé zvládají prověřovat, automatizace přesouvá práci na příjemce. Pozastavení jednoho z bezpečnostních programů Googlu ukazuje, kam taková zátěž může vést.
Co Google pozastavil a na jak dlouho
Podle zprávy TechCrunch ze 4. října Google pozastavil Open Source Software Vulnerability Rewards Program. V něm výzkumníci získávali odměny za nalezení zranitelností v open-source softwaru společnosti. Takovým programům se říká bug bounty.
Google ve vyjádření citovaném ve zprávě uvedl jako důvod výrazný nárůst automatizovaných podání, z nichž je podle firmy naprostá většina neplatná. Pozastavení platí od 1. října 2026. V prvním čtvrtletí roku 2027 má přijít další oznámení, nikoli nutně obnovení příjmu hlášení.
Opatření se týká tohoto konkrétního programu. Google účastníky odkazuje na své další programy odměn za hledání zranitelností.
Rychlost tvorby hlášení může zvýšit náklady na kontrolu
Zpráva spojuje nárůst podání s AI. Citované zdůvodnění Googlu ale mluví o automatizovaných hlášeních a jejich neplatnosti. Neuvádí přesný počet podání ani rozpad podle použitých nástrojů. Z případu proto nelze vyvozovat, že každý nález vytvořený s pomocí AI je bezcenný.
Pro práci s AI je podstatný jiný důsledek: vytvořit přesvědčivý popis problému a doložit skutečnou zranitelnost jsou dvě různé části práce. Pokud automatizuješ jen tu první, můžeš zrychlit vznik výstupů a zároveň přidat práci lidem, kteří je musí ověřovat.
To se týká i malého týmu. Představ si, že ti AI po kontrole kódu připraví seznam možných bezpečnostních chyb. Dokud vývojář neověří jejich podmínky a dopad, jde o podněty k prověření. Jejich automatické odeslání jako potvrzených zranitelností by přesunulo ověřování na někoho dalšího.
Co požadovat od nálezu, než ho pošleš dál
Pokud podobnou kontrolu používáš, nastav pro hlášení jednoduchou podmínku: musí obsahovat konkrétní místo v kódu, podmínky vzniku problému a postup, kterým lze tvrzení ověřit. Kde důkaz chybí, ať AI výslovně uvede nejistotu. Před externím odesláním nech nález posoudit odpovědnou osobu.
Přínos pak měř podle potvrzených problémů a času potřebného k jejich ověření. U příští sady nálezů si zapiš, kolik jich kontrolou prošlo a kolik práce zabraly ty neplatné. Teprve tak zjistíš, zda ti AI při hledání chyb skutečně pomáhá.
Zdroj
Související články
Související z knihovny