Cyberbezpieczeństwo
Cogent informuje, że VR-1.1 przechodzi testy naprawy w 57,9% zadań LiveCVEBench
Dodaj Unite.AI do preferowanych źródeł w Google
Cogent Security zaprezentowała VR-1.1 3 listopada 2026 r., informując, że model naprawiający luki w zabezpieczeniach przygotował naprawy, które przeszły testy w 57,9% z 190 zadań LiveCVEBench; w przypadku Claude Code i Codex odsetek ten wyniósł po 45,3%.
Najnowszy model z rodziny VR firmy Cogent rozwija możliwości usuwania luk w zabezpieczeniach wprowadzone w VR-1. W ramach oceny porównano VR-1.1 z Claude Code działającym w oparciu o Claude Opus 5.5 oraz Codex działającym w oparciu o GPT-5.6-Cyber. Każdy system otrzymał te same dane wejściowe i konfigurację oraz miał trzy próby na każde zadanie; wyniki oparto na końcowej poprawce, powstałej po wewnętrznych próbach naprawy.
Test porównawczy oparty na działających naprawach
LiveCVEBench skupia się na usuwaniu rzeczywistych luk w zabezpieczeniach w środowiskach programistycznych. W artykule na temat CVE-Factory opisano stale aktualizowany zbiór 190 zadań obejmujących 14 języków programowania i 153 repozytoria. Projekt testu porównawczego umieszcza agentów w rzeczywistych środowiskach programistycznych, gdzie muszą samodzielnie analizować bazy kodu, ustalać kontekst każdej luki i wdrażać poprawkę. Nowe CVE są regularnie dodawane.
W konfiguracji Cogent do każdego zadania dołączono opis luki w zabezpieczeniach oraz bazę kodu, której ona dotyczyła. Poprawkę zaliczano tylko wtedy, gdy przechodziła testy sprawdzające usunięcie luki, a testy funkcjonalne nadal kończyły się powodzeniem. Zadania obejmują błędy związane z wstrzykiwaniem kodu, kontrolą dostępu, konfiguracją i bezpieczeństwem pamięci. Przekonujące wyjaśnienie nie wystarczy, jeśli zmiana pozostawia inną drogę do wykorzystania luki, wyłącza prawidłowe działanie, powoduje regresję lub tworzy nowe zagrożenie.
Ten podwójny wymóg odróżnia naprawę od samego powstrzymania jednej demonstracji ataku. Model musi zachować zamierzone działanie programu, jednocześnie usuwając lukę, także w powiązanych ścieżkach, w których ona występuje.
Proces naprawy w VR-1.1
Cogent przypisuje uzyskany wynik treningowi w zakresie naprawiania luk w zabezpieczeniach oraz mechanizmowi testowemu, który odtwarza podatność, wprowadza poprawkę, a następnie sprawdza, czy można ją ominąć. Jeśli pozwala na to konfiguracja uruchomienia, VR-1.1 analizuje opis i kod źródłowy, zanim napisze kod weryfikujący, który wywołuje lukę. Dzięki temu model ma do prześledzenia konkretną awarię i test, który może ponownie uruchomić po wprowadzeniu poprawki.
Zanim model wprowadzi ukierunkowaną zmianę, szuka powiązanych ścieżek kodu, w których występuje ta sama luka. Osobny przegląd, przeprowadzany w nowym kontekście, sprawdza poprawkę pod kątem możliwości jej ominięcia i błędów wprowadzonych przez zmianę. VR-1.1 tworzy również testy regresji. Jeśli walidacja kończy się niepowodzeniem, wcześniejsza analiza modelu i informacje o błędzie pomagają mu podjąć kolejną próbę.
Przykład naprawy w Fiber
Jeden z zarejestrowanych przebiegów dotyczył CVE-2025-48075 w frameworku Fiber. W komunikacie o luce opublikowanym przez projekt podano, że ujemny indeks w zagnieżdżonych danych formularza może wywołać awarię metody BodyParser i serwera, stwarzając ryzyko odmowy usługi. Jako podatne wskazano wersje od 2.52.6, a wersję 2.52.7 wymieniono jako wydanie z poprawką.
VR-1.1 odtworzył awarię i dodał kontrolę zakresu przed użyciem indeksu, odrzucając indeksy ujemne lub zbyt duże, a jednocześnie zachowując prawidłową obsługę formularzy. Cogent informuje, że po wprowadzeniu poprawki wszystkie dziewięć testów sprawdzających usunięcie luki zakończyło się powodzeniem, podczas gdy wcześniej nie powiódł się żaden; wszystkie 12 testów funkcjonalnych zakończyło się powodzeniem zarówno przed poprawką, jak i po niej. Przykład pochodzi z osobnego, zarejestrowanego przebiegu obejmującego 182 zadania, a nie z końcowej oceny obejmującej 190 zadań.
Ograniczenia oceny i zastosowanie produkcyjne
Podczas naprawy w ramach oceny zablokowano dostęp do sieci zewnętrznej, a testy oceniające LiveCVEBench udostępniono dopiero po zakończeniu pracy każdego agenta. Te warunki uniemożliwiały pobranie poprawki z nadrzędnego źródła oraz bezpośrednie korzystanie z testów oceniających podczas wprowadzania poprawek.
Cogent zastrzega, że daty graniczne danych treningowych obu modeli bazowych przypadają później niż daty publikacji CVE z obecnego wydania LiveCVEBench. Oznacza to, że opisy tych luk i poprawki mogły znaleźć się w danych treningowych. Firma wskazuje, że opisy zadań sformułowane na wzór zgłoszeń użytkowników, zablokowany dostęp do sieci oraz identyczne warunki ograniczają przewagę, jaką mogłoby to dawać.
W wyrywkowych testach Cogent modele potrafiły opisać niektóre luki z pamięci, ale nie odtworzyły dokładnych poprawek. Firma tworzy również zbiór zadań oparty na CVE ujawnionych po odpowiednich datach granicznych i planuje go na bieżąco aktualizować.
LiveCVEBench sprawdza znane luki w odizolowanych środowiskach, a zaliczenie testu oznacza spełnienie dostarczonych kryteriów. Cogent podkreśla, że wdrożenie produkcyjne nadal wymaga przeglądu i testów w środowisku docelowym. Firma włącza VR-1.1 do swojego procesu usuwania luk; każdej poprawce towarzyszą diagnoza, kod weryfikujący oraz testy, które recenzent może sprawdzić. Wynik testu porównawczego mierzy zatem skuteczność napraw zweryfikowanych w kontrolowanych warunkach, natomiast wykorzystanie produkcyjne nadal zależy od sprawdzenia tych napraw w środowisku, w którym będzie działać oprogramowanie.
