JFrog analyzoval súbor hlásení, ktoré tvrdili, že odhaľujú bezpečnostné chyby v SQLite. Výskumníci porovnávali citované verzie, funkcie, riadky zdrojového kódu, údajné opravy aj proof-of-concept ukážky s oficiálnymi vydaniami a izolovanými testovacími prostrediami. Výsledok bol výrazný: 54 z 55 advisories od toho istého účtu bolo fabrikovaných.
Niektoré hlásenia pritom už získali formálne identifikátory alebo údaje o závažnosti v nadväzujúcich databázach. Jedna údajná zraniteľnosť dostala skóre CVSS 10.0, teda najvyššie možné hodnotenie kritickosti. Takéto číslo sa bežne používa na okamžité stanovenie priorít, spustenie interných incidentných procesov a eskaláciu smerom k vedeniu.
CVE záznam nie je dôkaz existencie chyby
CVE je štandardizovaný identifikátor, ktorý umožňuje rôznym nástrojom a organizáciám hovoriť o rovnakej zraniteľnosti. National Vulnerability Database k záznamom pridáva ďalšie údaje, napríklad hodnotenie závažnosti, dotknuté produkty alebo odkazy. V praxi sa preto CVE a NVD stali základom automatizovaného skenovania, správy opráv aj reportingu rizík.
Samotné pridelenie identifikátora však nie je matematickým dôkazom, že chyba existuje. Kvalita záznamu závisí od kvality pôvodného hlásenia, procesu overenia a správnosti následného obohatenia. Ak sa do prvého kroku dostane presvedčivá fikcia, ďalšie systémy ju môžu spracovať ako legitímny vstup.
Generatívne modely tento problém zosilňujú. Vedia napodobniť štýl bezpečnostného reportu, skombinovať reálne názvy komponentov s neexistujúcimi cestami vykonania a doplniť vierohodné technické detaily. Text môže byť syntakticky čistý a vecne chybný zároveň. Automatizovaný systém, ktorý kontroluje najmä formát a úplnosť polí, tak nemá dostatok signálov na odmietnutie.
Ako vzniká falošná dôveryhodnosť
Bezpečnostné databázy sú navzájom prepojené. Jeden záznam môže byť prevzatý skenermi, distribúciami Linuxu, výrobcami softvéru, nástrojmi na správu závislostí aj internými dashboardmi. Každé ďalšie zobrazenie vytvára dojem, že informáciu overilo viac nezávislých strán. V skutočnosti môžu všetky čerpať z jediného neovereného zdroja.
Skóre závažnosti tento efekt ešte posilňuje. Hodnota 10.0 je zrozumiteľná aj bez hlbšieho technického kontextu a ľahko sa stane prioritou. Ak je však základný opis chybný, presnosť výpočtu CVSS nepomôže. Systém iba veľmi presne ohodnotí scenár, ktorý neexistuje.
Falošný záznam pritom nie je neškodný. Tímy môžu stráviť hodiny hľadaním neexistujúcej opravy, testovaním nereprodukovateľného útoku alebo vysvetľovaním rizika zákazníkom. Správcovia open-source projektov musia reagovať na hlásenia, ktoré vyzerajú profesionálne, ale nemajú technický základ. Skutočné chyby sa tak môžu stratiť v rastúcom objeme nekvalitných podaní.
Prečo jednoduchý AI detektor nestačí
Pokušením je kontrolovať, či text pravdepodobne vytvoril jazykový model. Takýto prístup však nerieši podstatu problému. AI detektory nie sú spoľahlivé a kvalitné hlásenie môže byť pripravené s pomocou modelu bez toho, aby bolo nepravdivé. Naopak, človek môže ručne vytvoriť úplne falošný report.
Rozhodujúca musí byť overiteľnosť tvrdenia. Hlásenie by malo presne uvádzať dotknutú verziu, prostredie, vstup, očakávané a skutočné správanie a postup reprodukcie.
Prvou zmenou je oddeliť prijatie hlásenia od jeho potvrdenia. Nový záznam môže mať stav čakajúci na verifikáciu a nemal by automaticky spúšťať rovnaké procesy ako reprodukovaná zraniteľnosť. Stav musí byť dostupný aj strojovo, aby ho skenery a dashboardy vedeli zohľadniť.
Druhou zmenou je povinný balík dôkazov. Nestačí opis a presvedčivý scenár. Systém by mal vyžadovať reprodukovateľný test, presné verzie, hash relevantného commitu a výsledok overenia. Automatizácia môže kontrolovať, či odkazy existujú a či sa tvrdenia zhodujú s repozitárom, no finálne technické posúdenie nemá byť iba formálnou validáciou polí.
Treťou zmenou je reputácia zdroja bez slepej dôvery. História kvalitných hlásení môže urýchliť spracovanie, ale nesmie nahradiť dôkaz. Pri sériách podaní z jedného účtu by mala anomália, napríklad náhly príval kritických chýb, automaticky vyvolať manuálnu kontrolu.
Napokon treba opravy šíriť rovnako dôsledne ako pôvodné upozornenia. Keď sa záznam ukáže ako falošný, zmena musí prejsť do NVD, skenerov, distribúcií aj interných databáz. Inak zostane neplatná informácia v závislých systémoch ešte dlho po vyvrátení.
