🤖🔧 LLM против уязвимостей: почему реальные баги чинятся лучше, чем искусственные

Большое исследование, которое проверяет истории о «самочинящихся» кодерах

Автоматическое исправление уязвимостей мечта индустрии последние двадцать лет. Мы уже пережили эпоху статических анализаторов, десятки попыток построить идеальный Automated Program Repair (APR) и сотни докладов, которые обещали «починку кода одним кликом».

Сегодня у нас бум LLM.  Модели генерируют не только стихи, но и создают патчи. В соцсетях уже гуляют скриншоты, где ChatGPT «за секунду» чинит SQLi или XSS.

Тем не мене вопрос остаётся открытым:

🧩 А насколько эти патчи вообще работают, когда дело доходит до реальных эксплойтов, а не до красивых текстовых примеров?

Команда исследователей из Luxembourg Institute of Science and Technology решила проверить, что LLM умеют патчить в реальном бою, когда исправления проверяют не глазами разработчика, а Proof-of-Vulnerability (PoV) тестами

🎯 Исследование

Исследование охватило 14 различных LLM, включая модели OpenAI (GPT-3.5, GPT-4, GPT-4o), Meta LLaMA (версии 3.1 и 3.3), DeepSeek R1 Qwen и несколько версий Mistral.

Модели тестировали на двух типах уязвимостей:
🔹 Реальные уязвимости
15 CVE из датасета Vul4J: уязвимый код, PoV-тест, гарантированно воспроизводящий атаку.
🔹 Искусственные уязвимости
41 синтетическая уязвимость, созданная исследователями на базе реальных, с изменениями в коде, но с тем же PoV-фейлом.

Искусственные баги воспроизводили те же ошибки, что и реальные, но выглядели иначе.

🔥 LLM плохо справляются с искусственными уязвимостями

Половина реальных уязвимостей была успешно исправлена хотя бы одной моделью. Однако была исправлена лишь четверть искусственных уязвимостей. LLM не распознавали паттерны искусственных уязвимостей.

Причина проста:
🧠 LLM чинят то, что узнают, а не то, что понимают
Модель не анализирует механику уязвимости, она пытается "вспомнить" похожий патч из обучающих данных.

🧪 Как проходило тестирование

Каждая модель получала строгий промпт:

"Исправь уязвимость. Не меняй ничего лишнего. Верни только Java-функцию."

Далее происходило следующее:
🧩 Исследователи подменяли функцию в реальном проекте.
🧱 Проект пересобирался.
💥 Прогонялся PoV-тест (реальный эксплойт).
🛡 Если PoV больше не мог воспроизвести атаку, то фикс засчитывался.

Если код не компилировался или эксплойт всё ещё работал, то патч считался провальным.

🥇 Кто справился лучше всего

В абсолютных числах:
➖DeepSeek R1 Qwen 32B исправил 14 уязвимостей
➖Mistral 8×7B тоже 14 уязвимостей
➖GPT-4 и GPT-4 Turbo по 9 исправлений
➖Остальные модели оказались слабее: около 5–6 успешных патчей.

При этом:
❗ Никто не стал «универсальным патчером».
Нет модели, которая стабильно и хорошо чинит всё.

💣 Примеры

✅ Успешный случай: CVE-2013-5960
Ошибка в криптографии (AES/CBC → AES/GCM).
Все модели без исключения смогли заменить режим и настроить correct tag length.

Почему?

Потому что это «шаблонное» исправление, встречающееся в тысячах проектов.

❌ Провальный случай: XXE в Apache Batik
Для полного исправления XXE нужно:
отключить external entities;
обновить зависимость Batik на версию, где этот флаг работает корректно.

Все модели делали только шаг №1.

PoV продолжал считывать содержимое локального файла. Уязвимость оставалась.

Причина:
LLM не может увидеть зависимость, не может проверить билд, не понимает контекст.

🔗 Ссылка на исследование: https://arxiv.org/abs/2511.23408

Stay secure and read SecureTechTalks 📚

#cybersecurity #infosec #LLM #AIsecurity #vulnerabilities #javasecurity #research #securecoding #patching #SecureTechTalks