CVE-uri false, rapoarte generate de IA și nevoia de verificare

Crearea unor rapoarte convingătoare despre vulnerabilități devine tot mai ieftină, ceea ce sporește consecințele pentru responsabilii de mentenanța software-ului și echipele de securitate. În iulie 2026, au fost publicate șase vulnerabilități și expuneri comune (CVE-uri) care vizau SQLite, iar două dintre ele au primit un scor de severitate de 9,8. Rapoartele păreau legitime: descriau erori legate de siguranța memoriei și includeau explicații tehnice și cod demonstrativ de tip proof of concept.

Însă cercetătorii JFrog au descoperit că unele dintre funcțiile menționate în aceste rapoarte nu existau în versiunile afectate. Mai mult, niciuna dintre demonstrațiile de tip proof of concept (PoC) nu a reprodus vulnerabilitățile pretinse. Pagina CVE proprie a SQLite afirmă în prezent că aceste șase rapoarte nu descriu erori; ulterior, înregistrările CVE au fost respinse.

Problema nu se limitează la SQLite. Daniel Stenberg, responsabilul de mentenanța curl, a estimat anul trecut că aproximativ 20% dintre rapoartele de securitate primite erau rezultatul conținutului de slabă calitate generat de IA. Autoritatea de Numerotare CVE (CNA) a GitHub a primit aproape 4.000 de solicitări CVE în mai 2026; aceasta reprezintă o creștere de aproximativ 10 ori a volumului față de anul precedent. GitHub nu a pus această creștere pe seama IA și nici nu a semnalat o scădere a calității trimiterilor, însă creșterea masivă a volumului evidențiază presiunea copleșitoare asupra procesului de divulgare a vulnerabilităților.

IA facilitează formularea unor afirmații detaliate despre vulnerabilități, însă stabilirea legitimității lor necesită timp. Iar odată ce un CVE ajunge în fluxurile de informații despre securitate și în bazele de date publice, corectarea înregistrării originale nu înseamnă automat că va fi corectată fiecare copie. Prin urmare, este tot mai necesar să se facă distincția între o vulnerabilitate raportată și una verificată din punct de vedere tehnic.

Ce este un CVE „fals”?

Oamenii folosesc frecvent termenul „CVE fals” pentru a desemna un CVE care, cel mai probabil, a fost raportat incorect. Dar „fals” nu înseamnă că raportul urmărește să inducă în eroare. Acesta poate proveni dintr-o analiză statică ce trece cu vederea o verificare de validare sau interpretează greșit datele de intrare ca fiind controlate de un atacator. Un raport poate descrie o funcție reală, dar poate pretinde că există o cale de atac nevalidă. Un identificator (ID CVE) poate fi atribuit și apoi retras dacă situația raportată nu constituia, de fapt, o vulnerabilitate. Acest lucru este diferit de un raport inventat în mod deliberat.

Nici o dispută nu înseamnă că un CVE este fals. Un furnizor poate contesta concluziile unui cercetător privind posibilitatea exploatării, limitele amenințării sau intenția ca o funcție să proceseze date de intrare nefiabile. Dar o dispută nu dovedește că cercetătorul s-a înșelat. Iar respingerea unui CVE nu înseamnă neapărat că acesta a fost fabricat; poate fi respins ca duplicat sau din motive administrative. Deși un identificator CVE nu reprezintă o verificare tehnică independentă, industria trebuie să trateze cu seriozitate rapoartele reale.

De ce sunt CVE-urile false o problemă

Una dintre problemele pe care le observăm este folosirea IA pentru a genera rapoarte despre vulnerabilități fără verificarea corespunzătoare a constatărilor. Aceste rapoarte pot include explicații tehnice detaliate, referințe la cod și chiar PoC-uri, ceea ce le poate face să pară legitime. Însă, după cum am văzut în cazul CVE-urilor SQLite, unele dintre funcțiile menționate nici măcar nu existau în versiunile afectate.

GitHub a raportat o creștere semnificativă a numărului de trimiteri privind vulnerabilități în 2026, deși nu a atribuit această creștere IA și nici nu a raportat o scădere a calității trimiterilor. Problema este că, pe măsură ce crește numărul rapoartelor, crește și volumul de muncă necesar pentru investigarea lor, indiferent dacă respectivele constatări sunt reale sau nu.

Cei care au triat rapoarte despre vulnerabilități recunosc cu ușurință dificultatea practică. Un model de IA poate identifica un apel API suspect, poate schița rapid un scenariu de exploatare și poate genera în scurt timp un raport cu aspect profesionist. Pentru a stabili dacă scenariul este viabil, poate fi necesar să se verifice versiunea exactă, să se urmărească fluxul de control, să se afle cum ajung datele la funcție, să se construiască un mediu de testare și să se execute presupusul exploit. Același proces este necesar indiferent dacă raportul este corect sau nu, iar acest lucru poate fi costisitor.

CVE-urile false pot afecta și reputația. Un anunț despre o vulnerabilitate se poate răspândi rapid prin fluxurile de informații ale scanerelor, bazele de date de securitate și rezultatele căutărilor. Însă este posibil ca rectificarea ulterioară să nu ajungă la fel de departe. Chiar și după contestarea sau respingerea unui raport, furnizorii se pot vedea nevoiți să se apere în fața clienților care au văzut raportul inițial.

Există și riscul ca vulnerabilitățile reale să fie trecute cu vederea sau investigate cu întârziere, deoarece echipele își consumă timpul cercetând rapoarte incorecte. Când responsabilii de mentenanță și echipele de securitate au resurse limitate, fiecare oră petrecută pentru a infirma un rezultat fals pozitiv este o oră care ar fi putut fi folosită pentru investigarea unei probleme reale de securitate.

Automatizarea, o soluție de ripostă

Mulți investigatori încă triază manual rapoartele pentru a face față avalanșei recente, însă această abordare nu este sustenabilă. Automatizarea se dovedește de mare ajutor pentru verificarea unei afirmații privind o vulnerabilitate în raport cu versiunea și configurația afectate efectiv. Iată cele cinci întrebări care trebuie puse:

• Sunt plauzibile condițiile prealabile ale atacului, inclusiv configurația și permisiunile?
• Există funcția menționată în versiunea afectată?
• Poate un atacator să ajungă la codul vulnerabil? Stabiliți dacă fragmentul de cod relevant poate fi executat în condițiile care afectează sistemul și dacă un atacator poate furniza date de intrare care să ajungă la el.
• Pot testerii să reproducă comportamentul într-un test controlat sau cu ajutorul unui PoC?
• Manifestă comportamentul observat impactul asupra securității descris în aviz?

Instrumentele bazate pe agenți pot crea medii de testare, analiza fluxurile de execuție a codului, genera PoC-uri și înregistra dovezi ale execuției pentru a fi analizate. Ele nu pot soluționa automat orice afirmație. Chiar și atunci când o vulnerabilitate este autentică, un PoC poate eșua dacă mediul este incomplet sau dacă declanșatorul nu este cel corect. Testerii pot reproduce o blocare fără să demonstreze exploatabilitatea pretinsă. Aceste rezerve explică de ce judecata umană rămâne esențială. Totuși, aceste instrumente pot ajuta echipele să ajungă mai aproape de un răspuns reproductibil, înainte ca un raport să consume și mai mult timp în echipele de inginerie, de gestionare a vulnerabilităților și de asistență pentru clienți.

Cum să facem față avalanșei din ecosistemul CVE

Nicio politică succintă nu va rezolva ca prin magie problema CVE-urilor false. Ar fi însă util să se ceară dovezi mai solide la trimiterea sesizărilor și să se clarifice mai bine stadiul reproducerii. Ar fi utilă și o abordare mai clară a înregistrărilor contestate, precum și corectarea mai rapidă a datelor derivate. Cercetătorii ar trebui încurajați să-și valideze constatările obținute cu ajutorul IA înainte de a le trimite.

Echipele de securitate și furnizorii trebuie să se concentreze asupra examinării dovezilor. Un scor CVE de severitate critică nu arată dacă o cale vulnerabilă poate fi accesată în mediul lor. Faptul că un PoC eșuează nu înseamnă că totul este în regulă. Iar primirea unui ID CVE nu scutește echipele de munca tehnică necesară pentru a înțelege problema.

IA sporește capacitatea de a descoperi vulnerabilități și, totodată, permite formularea unor afirmații care par solide, dar sunt incorecte. Într-o lume în care rapoartele se înmulțesc, organizațiile trebuie să investească în verificare. Aceasta presupune crearea de teste, reproducerea rezultatelor, verificarea ipotezelor și facilitarea evaluării dovezilor. Testarea de securitate bazată pe agenți ar putea juca un rol important în acest domeniu.