🤖🔧 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
