Falešná CVE, zprávy generované AI a potřeba ověřování

Vytvářet přesvědčivé zprávy o zranitelnostech je stále levnější, což zvyšuje zátěž pro správce softwaru i bezpečnostní týmy. V červenci 2026 bylo pro SQLite zveřejněno šest záznamů Common Vulnerabilities and Exposures (CVE) a dva z nich dostaly skóre závažnosti 9,8. Zprávy působily věrohodně: popisovaly chyby ohrožující bezpečnost paměti a obsahovaly technická vysvětlení i ukázkový kód zneužití.

Výzkumníci společnosti JFrog ale zjistili, že některé funkce, na které zprávy odkazovaly, se v dotčených verzích vůbec nenacházely. Navíc žádná z ukázek zneužití (PoC) údajné zranitelnosti nereprodukovala. Vlastní stránka SQLite věnovaná CVE v současnosti uvádí, že těchto šest zpráv nepopisuje chyby; záznamy CVE byly následně zamítnuty.

Problém se netýká jen SQLite. Daniel Stenberg, správce projektu curl, loni odhadl, že zhruba 20 % příchozích hlášení o bezpečnostních problémech bylo produktem nekvalitního obsahu generovaného AI. Úřad GitHubu pro přidělování čísel CVE (CNA) obdržel v květnu 2026 téměř 4 000 žádostí o CVE, což představuje přibližně desetinásobný meziroční nárůst jejich počtu. GitHub tento nárůst nepřičítal AI ani nezaznamenal pokles kvality podání, ale prudký růst objemu ukazuje, jak je proces zveřejňování zranitelností zahlcený.

AI usnadňuje vytváření podrobných tvrzení o zranitelnostech, ale ověřit jejich věrohodnost je časově náročné. A jakmile se CVE dostane do bezpečnostních informačních kanálů a veřejných databází, oprava původního záznamu automaticky neznamená, že budou opraveny i všechny jeho kopie. Stále naléhavější je proto potřeba rozlišovat mezi nahlášenou a technicky ověřenou zranitelností.

Co je „falešná“ CVE?

Lidé běžně používají označení „falešná CVE“ pro záznam CVE, který byl pravděpodobně nahlášen chybně. Slovo falešná ale neznamená, že někdo chtěl úmyslně klamat. Příčinou může být statická analýza, která přehlédne kontrolu validace, nebo nesprávně vyhodnotí vstup jako ovládaný útočníkem. Zpráva může podrobně popisovat skutečnou funkci, ale tvrdit, že ji lze napadnout způsobem, který není možný. Identifikátor (ID CVE) může být přidělen a později zrušen, pokud nahlášený problém ve skutečnosti zranitelností nebyl. To se liší od záměrně smyšlené zprávy.

Ani spor neznamená, že jde o falešnou CVE. Dodavatel může zpochybňovat závěry výzkumníka týkající se možnosti zneužití, hranic hrozby nebo toho, zda měla daná funkce zpracovávat nedůvěryhodné vstupy. Spor ale nedokazuje, že se výzkumník mýlil. A zamítnutí CVE nutně neznamená, že byla zfalšována; může být zamítnuta jako duplicitní nebo z administrativních důvodů. Přestože samotný identifikátor CVE není nezávislým technickým ověřením, toto odvětví musí brát skutečná hlášení vážně.

Proč jsou falešné CVE problém

Jedním z problémů, s nimiž se setkáváme, je používání AI k vytváření zpráv o zranitelnostech bez řádného ověření zjištění. Tyto zprávy mohou obsahovat podrobná technická vysvětlení, odkazy na kód, a dokonce i ukázky zneužití (PoC), takže mohou působit věrohodně. Jak jsme ale viděli u CVE pro SQLite, některé odkazované funkce v dotčených verzích vůbec neexistovaly.

GitHub v roce 2026 oznámil výrazný nárůst počtu hlášení zranitelností, tento nárůst však nepřičítal AI ani neuváděl, že by se kvalita podání zhoršila. Obavy vyvolává to, že s rostoucím počtem hlášení přibývá i práce potřebné k jejich prověření, bez ohledu na to, zda jsou jejich zjištění skutečná.

Každý, kdo někdy třídil hlášení zranitelností, snadno pochopí, v čem spočívá praktický problém. Model AI dokáže rozpoznat podezřelé volání API, načrtnout scénář zneužití a rychle vytvořit profesionálně vyhlížející zprávu. Zjistit, zda je takový scénář uskutečnitelný, může vyžadovat ověření konkrétní verze, sledování toku řízení, zjištění, jak se data dostávají k dané funkci, přípravu testovacího prostředí a spuštění údajného zneužití. Stejným postupem je třeba projít bez ohledu na to, zda je zpráva správná, a to může být nákladné.

Falešná CVE mohou poškodit také pověst. Oznámení o zranitelnosti se může rychle šířit kanály skenerů, bezpečnostními databázemi i výsledky vyhledávání. Následná oprava se však nemusí dostat tak daleko. I když bylo oznámení zpochybněno nebo odmítnuto, dodavatelé se mohou ocitnout v defenzivě vůči zákazníkům, kteří viděli původní oznámení.

Existuje také riziko, že skutečné zranitelnosti zůstanou nepovšimnuty nebo se jejich řešení opozdí, protože týmy věnují čas prověřování nesprávných hlášení. Když mají správci softwaru a bezpečnostní týmy omezené zdroje, každá hodina strávená vyvracením falešně pozitivního nálezu je hodinou, kterou mohli věnovat vyšetřování skutečného bezpečnostního problému.

Jak se bránit pomocí automatizace

Mnoho odborníků stále řeší novou záplavu hlášení ručním tříděním, takový přístup ale není dlouhodobě udržitelný. Automatizace se ukazuje jako významná pomoc při ověřování tvrzení o zranitelnosti ve vztahu ke skutečně dotčené verzi a konfiguraci. Je třeba položit si těchto pět otázek:

• Jsou předpoklady nutné k útoku věrohodné, včetně konfigurace a oprávnění?
• Existuje údajná funkce v dotčené verzi?
• Může se útočník dostat ke zranitelnému kódu? Zjistěte, zda se příslušný kód může spustit za dotčených podmínek a zda do něj útočník může dostat svůj vstup.
• Dokážou testeři toto chování zopakovat v kontrolovaném testu nebo pomocí PoC?
• Odpovídá pozorované chování bezpečnostnímu dopadu popsanému v bezpečnostním upozornění?

Agentní nástroje dokážou vytvářet testovací prostředí, analyzovat cesty v kódu, generovat PoC a zaznamenávat důkazy o provedení k následnému posouzení. Nedokážou však automaticky vyřešit každé tvrzení. I když je zranitelnost skutečná, PoC může selhat, pokud je prostředí neúplné nebo je spouštěcí mechanismus nesprávný. Testeři mohou zopakovat pád programu, aniž by prokázali tvrzenou zneužitelnost. Právě proto zůstává lidský úsudek zásadní. Tyto nástroje však mohou týmům pomoci dobrat se reprodukovatelného výsledku dříve, než hlášení zabere další čas vývojářům, týmům správy zranitelností i zákaznické podpoře.

Jak se vypořádat se zahlcením v ekosystému CVE

Žádná stručná směrnice problém falešných CVE zázračně nevyřeší. Pomohlo by ale vyžadovat přesvědčivější důkazy při podávání hlášení a jasněji uvádět stav reprodukce. Přínosné by bylo také jasněji řešit sporné záznamy a rychleji opravovat navazující data. Výzkumníky bychom měli podporovat v tom, aby svá zjištění získaná s pomocí AI před podáním ověřovali.

Bezpečnostní týmy a dodavatelé se musí zaměřit na prověřování důkazů. Kritické skóre CVE neříká, zda je cesta vedoucí ke zranitelnosti v jejich prostředí dosažitelná. To, že PoC selže, ještě neznamená, že je vše v pořádku. A přidělení identifikátoru CVE týmům nepromíjí technickou práci nutnou k pochopení problému.

AI zlepšuje schopnost odhalovat zranitelnosti a zároveň umožňuje vytvářet tvrzení, která působí přesvědčivě, ale jsou nesprávná. V době, kdy se hlášení rychle množí, musí organizace investovat do ověřování. To zahrnuje vytváření testů, reprodukci výsledků, prověřování předpokladů a usnadnění posuzování důkazů. Právě zde by mohlo hrát důležitou roli agentní bezpečnostní testování.