Cogent raportează că VR-1.1 aplică remedieri validate în 57,9% dintre sarcinile LiveCVEBench

Cogent Security a lansat VR-1.1 pe 3 noiembrie 2026, raportând că modelul de remediere a vulnerabilităților a produs remedieri validate pentru 57,9% dintre cele 190 de sarcini LiveCVEBench, comparativ cu câte 45,3% pentru Claude Code și Codex.

Cea mai recentă versiune din familia VR a Cogent extinde capacitățile de remediere introduse odată cu VR-1. În cadrul evaluării, VR-1.1 a fost comparat cu Claude Code, care rula Claude Opus 5.5, și cu Codex, care rula GPT-5.6-Cyber. Fiecare sistem a primit aceleași intrări și a folosit aceeași configurație, având la dispoziție trei încercări pentru fiecare sarcină; scorurile s-au bazat pe ultima corecție, după încercările interne de remediere.

Un set de evaluare axat pe remedieri funcționale

LiveCVEBench se concentrează pe remedierea vulnerabilităților reale în medii de dezvoltare. Lucrarea CVE-Factory descrie un set actualizat continuu, alcătuit din 190 de sarcini care acoperă 14 limbaje de programare și 153 de depozite de cod. Proiectul de evaluare comparativă plasează agenții în medii reale de dezvoltare, unde aceștia trebuie să exploreze autonom bazele de cod, să stabilească contextul fiecărei vulnerabilități și să implementeze o remediere. Se adaugă periodic CVE-uri noi.

Configurația Cogent a furnizat pentru fiecare sarcină un raport despre vulnerabilitate și baza de cod afectată. O corecție a fost considerată reușită numai dacă verificările de securitate erau trecute, iar verificările funcționale continuau să fie trecute. Sarcinile acoperă defecte de tip injecție, de control al accesului, de configurare și de siguranță a memoriei, astfel că o explicație convingătoare nu este suficientă dacă modificarea lasă deschisă o altă cale de exploatare a vulnerabilității, dezactivează funcționalități legitime, provoacă o regresie sau creează o nouă expunere.

Această cerință dublă distinge o remediere propriu-zisă de simpla oprire a unei demonstrații de atac. Modelul trebuie să păstreze comportamentul dorit și, în același timp, să închidă vulnerabilitatea, inclusiv pe căile conexe care o exploatează.

Fluxul de remediere al VR-1.1

Cogent atribuie rezultatul antrenării pentru remedierea vulnerabilităților de securitate și unui cadru de testare care reproduce o vulnerabilitate, o remediază și apoi verifică dacă măsura aplicată poate fi ocolită. Dacă configurația rulării permite, VR-1.1 analizează raportul și codul sursă înainte de a scrie o dovadă de concept care declanșează vulnerabilitatea. Astfel, modelul are o eroare pe care să o urmărească și un test pe care să îl ruleze din nou după aplicarea remedierii.

Înainte de a face o modificare punctuală, modelul caută căi de cod conexe care prezintă aceeași vulnerabilitate. O verificare separată, într-un context nou, analizează corecția pentru a identifica posibile ocoliri și erori introduse. VR-1.1 scrie și teste de regresie. Când validarea eșuează, analiza anterioară a modelului și informațiile despre eșec îi ghidează următoarea încercare.

Un exemplu practic de remediere în Fiber

Una dintre rulările înregistrate a vizat CVE-2025-48075 din cadrul web Fiber. Avizul de securitate al proiectului precizează că un index negativ în datele de formular imbricate poate provoca o eroare de tip panică în BodyParser și poate bloca serverul, creând un risc de atac de tip refuz al serviciului. Avizul indică versiunile începând cu 2.52.6 drept afectate și versiunea 2.52.7 drept versiunea care include remedierea.

VR-1.1 a reprodus blocarea și a adăugat o verificare a limitelor înainte de utilizarea indexului, respingând indexurile negative sau prea mari, dar păstrând procesarea validă a formularelor. Cogent raportează că, ulterior, au trecut toate cele nouă verificări de securitate, față de niciuna înainte de remediere, iar toate cele 12 verificări funcționale au trecut atât înainte, cât și după. Exemplul provine dintr-o rulare separată, înregistrată, cu 182 de sarcini, nu din evaluarea finală cu 190 de sarcini.

Limitele evaluării și utilizarea în producție

Evaluarea a blocat accesul la rețeaua externă în timpul remedierii și a ținut ascunse testele de evaluare LiveCVEBench până când fiecare agent și-a încheiat sarcina. Aceste condiții au împiedicat preluarea unei remedieri din surse externe sau folosirea directă a testelor de evaluare în timpul aplicării corecțiilor.

Cogent atrage atenția că datele-limită de antrenare pentru ambele modele de bază sunt ulterioare datelor de publicare ale CVE-urilor din versiunea actuală LiveCVEBench, ceea ce înseamnă că avizele și remedierile aferente ar fi putut apărea în datele de antrenare. Compania menționează descrierile sarcinilor, redactate în stilul rapoartelor utilizatorilor, blocarea accesului la rețea și condițiile identice drept factori care limitează acest avantaj.

În verificările punctuale efectuate de Cogent, modelele au putut descrie din memorie unele vulnerabilități, dar nu au reprodus corecțiile exacte. Compania construiește, de asemenea, un set de sarcini bazat pe CVE-uri dezvăluite după datele-limită relevante și intenționează să îl mențină la zi.

LiveCVEBench testează vulnerabilități cunoscute în medii izolate, iar trecerea evaluării presupune îndeplinirea verificărilor furnizate. Cogent precizează că implementarea în producție necesită în continuare verificare și testare în mediul de destinație. Compania integrează VR-1.1 în fluxul său de remediere, iar fiecare corecție este însoțită de diagnosticul aferent, de o dovadă de concept și de teste pe care le poate examina un evaluator. Prin urmare, rezultatul evaluării măsoară remedieri verificate în condiții controlate; utilizarea în producție depinde în continuare de validarea acestor remedieri în mediul în care va rula software-ul.