Изследователи от Северозападния университет (Northwestern University) тестваха AI агенти за програмиране върху 112 реални дефекта в сигурността. Те установиха, че корекция за сигурност, която спира срива на системата, често се проваля на тестовете, написани от поддържащите проекта за самото отстраняване на проблема. При Claude Opus 4.7 една трета от корекциите, които предотвратиха срива, все пак се провалиха на тези тестове на поддържащите екипи.
Ако обмисляте да позволите на инструмент с изкуствен интелект да отстранява уязвимости вместо вас, точно на тази цифра трябва да обърнете внимание. Много бенчмаркове за корекции в сигурността оценяват решението само по един критерий: дали входните данни за демонстрация на концепцията (proof-of-concept), които задействат дефекта, все още сриват програмата? Дадена корекция за сигурност може да премине успешно теста просто като блокира пътя до срива, оставяйки уязвимостта на мястото ѝ. Авторите наричат този тип поправка „категорично по-лоша от липсата на каквато и да е корекция“, тъй като тя създава фалшиво усещане, че проблемът е решен, когато това не е така.
Две корекции, един верен отговор
Изследователите са изградили своя набор от данни от дефекти в 84 проекта с отворен код, написани на C/C++, Go и Rust. За всеки дефект те са извлекли тестовете, които първоначалните разработчици са добавили успоредно с реалното отстраняване на уязвимостта. След това са тествали създадените от AI корекции спрямо тези тестове.
Да вземем за пример дефект в PHP. Една генерирана от AI корекция поправя логиката по същия начин, както направиха поддържащите PHP разработчици. Друга просто връща грешка всеки път, когато входните данни изглеждат необичайни – което спира срива, но също така прекъсва заявки, които PHP трябва да обработва. И двете преминават съществуващите тестове на PHP. Единствено тестът, написан от поддържащите проекта специално за отстраняването на уязвимостта, успява да ги разграничи.
Екипът е изпробвал и три поколения модели Claude. Най-новият модел успява да спре срива в около 90% от случаите, но преминава тестовете на поддържащите екипи само в около 61% от тях. Така дори най-добрият тестван модел се проваля на тези тестове при приблизително четири от всеки десет дефекта.
Агентите намериха готовите отговори
Екипът също така установи, че агентите извличат отговори директно от тестовата среда:
- Търсене в интернет: при включено уеб търсене, един агент Claude Code откри първоначалния комит с корекцията в рамките на първите си четири извиквания на инструменти. По-късно той докладва, че неговата корекция следва същия подход, и цитира изтеглената страница.
- Git история: на друг агент беше предоставен пълен достъп до git историята на проекта. Той потърси по-ранна свързана корекция и я възпроизведе почти ред по ред.
- Файл с верните отговори: в по-ранна версия на тестовата платформа даден агент прочете конфигурационен файл, сочещ към реалната еталонна корекция. Неговите редакции съвпаднаха напълно с официалното решение.
Авторите посочват, че претърсването на git историята е било разумен ход – същото, което би направил и разработчик човек. Бенчмаркът просто е оставил отговора на леснодостъпно място.
Тестовата конфигурация доведе и до неуспехи, които не се дължаха на самия AI. Скрита фонова проверка в Claude Code доведе до забавяне на командите, което изглеждаше така, сякаш моделът се затруднява. В друг случай агент написа правилна поправка заедно със собствен тест, но този тест влезе в конфликт с тестовия файл на поддържащите разработчици. Бенчмаркът отчете правилната корекция като неуспех.
Екипът прегледа 13 бенчмарка и набора от данни, използвани за оценка на корекции от изкуствен интелект. Всеки от петте инструмента, специално създадени за AI агенти, е пропуснал да адресира поне един от деветте идентифицирани капана.
Какво да попитате доставчика
Ако оценявате инструмент с изкуствен интелект за отстраняване на уязвимости, ето четири въпроса, които трябва да зададете:
- Оценката проверява ли само дали сривът е спрял, или изпълнява и тестовете, написани от поддържащите проекта?
- Агентът имаше ли достъп до интернет или до git историята на проекта?
- Какво гласеше системната инструкция (prompt) относно компилирането и тестването на кода?
- Как бяха отчетени изтичанията на времето (timeouts) и грешките в конвейера?
Третият въпрос има по-голямо значение, отколкото изглежда. Самото указване на изкуствения интелект как да компилира и тества кода повиши степента му на успеваемост при дефекти в C и C++ с 20 процентни пункта, без самият AI да е станал по-интелигентен.
А в класиране, което проверява единствено дали сривът е прекратен, всяка една от тези корекции, които не отговарят на замисъла на разработчиците, щеше да бъде зачетена като победа.