ИИ-патчи опаснее уязвимостей? Разбор рисков

47% - ровно столько AI-патчей полностью устранили уязвимость без регрессий. Это данные 1Password по шести high-impact CVE. Хуже подбрасывания монетки. Оставшиеся 53% либо закрыли часть exploit-путей, либо привнесли новые баги, либо сломали поведение приложения. Параллельно Veracode прогнала сотню моделей через тесты безопасности: в 44% случаев автоматическое исправление кода нейросетями вносило в кодовую базу свежую уязвимость из OWASP Top 10. За последний год я настраивал Copilot Autofix и Snyk DeepCode AI в пайплайнах трёх продуктовых команд. Картина одна и та же: автопатч "чинит" SQL-инъекцию, а через два эндпоинта тот же параметр входит в запрос без санитизации. SAST-алерт исчезает, тикет закрывается, уязвимость остаётся. Красиво на дашборде, опасно в проде.

Масштаб провалов: ошибки AI при исправлении кода в цифрах​

Исследование 1Password - одно из первых, протестировавших AI patching безопасность на реальных CVE, а не на синтетических примерах. Исследователи Кит Худлет, Аксель Мерчук и Спенсер Майклс взяли шесть CVE категории "high-impact, high-complexity", включая уязвимость "Copy Fail" - дефект ядра, дающий root-доступ в GNU/Linux-облачных средах. Что зафиксировала команда: Подробнее - в нашем материале про appsec в devsecops.

• Полное устранение без побочных эффектов - 47%, хуже монетки
• Модели адресовали только подмножество уязвимых code paths
• Добавляли хрупкий guard-код, который проходил тесты, но не устранял корневую причину
• В ряде случаев меняли поведение приложения - создавали побочный вектор атаки при патчинге основного

Veracode подтвердила паттерн на масштабе: из ста протестированных моделей средний security pass rate - около 56%. Отдельные топовые модели подтягиваются к 70%, но большинство сидят в коридоре 50-53%. Исследователи зафиксировали "стагнацию" - прогресс показывает небольшая группа моделей, остальные не улучшаются от версии к версии. Это не "пока сырое, скоро допилят". Это архитектурное ограничение.

Ещё одна точка данных - по оценкам исследователей (IEEE), значительная доля предложений GitHub Copilot содержала уязвимости. Это генерация нового кода, не патчинг, но корневая проблема общая: LLM генерация кода безопасность не гарантирует по определению. Модель оптимизирована на функциональность, не на security.

Контекст давления понятен. По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и устранением - 29 месяцев. Когда у вас очередь из сотен непропатченных уязвимостей, AI-автофикс кажется спасением. Но это automated vulnerability remediation со встроенным дефектом: скорость без верификации генерирует иллюзию прогресса. Тикеты закрываются, дашборд зеленеет, а дыры остаются.

Как нейросети ломают код: таксономия провалов AI-патчей​

Риски автоматического исправления кода делятся на три категории по характеру провала. Каждая требует отдельного detection-подхода и разных правил корреляции.

Частичный фикс - иллюзия безопасности AI-кода​

Самый опасный класс. Модель закрывает один exploit path, оставляя два других. SAST-отчёт показывает зелёный свет (сканер проверял именно тот path), команда мержит, в проде - открытая дверь.

Конкретная механика: Copilot Autofix получает алерт на инъекцию в эндпоинте /api/users. Модель добавляет параметризованный запрос в основном обработчике. Но тот же параметр приходит ещё через маршруты bulk import и admin panel, которые AI не видит - они в других файлах, за пределами его context window. SAST перестаёт алертить. Тикет закрыт. Уязвимость формально устранена, фактически открыта для двух из трёх входных точек. Я видел это трижды за полгода - каждый раз модель правила ровно тот файл, на который указывал SAST, и игнорировала соседние.

По данным OX Security, AI-инструменты часто лишены контекстного понимания требований безопасности приложения и организационных best practices - генерируют код без надлежащей валидации ввода (OWASP A03:2021 - Injection).

Хрупкий guard-код: когда code review AI патчей спасает от катастрофы​

Исследователи 1Password описали это точно: модели добавляют "guard code that satisfied tests while failing to address the vulnerability's root cause""Код безопасности который удовлетворял тестам, но при этом не устранял корень уязвимости". На практике - вместо исправления логики обработки данных AI добавляет проверку на конкретный payload из тест-кейса. Unit-тесты проходят. Любая вариация payload обходит защиту.

Пример для понимания масштаба проблемы: модель "фиксит" XSS, добавляя проверку if "<script>" in user_input: reject(). Тест на <script>alert(1)</script> проходит. А <img onerror=alert(1)> пролетает без проблем. Это не исправление уязвимости - это прохождение конкретного теста. Veracode подчёркивали эту проблему: SQL-инъекции относительно легко патчить автоматически, но XSS-уязвимости эксплуатируются множеством способов и требуют либо участия человека, либо дополнительного контекста, либо и того и другого. Обычно - и того и другого.

Новые уязвимости в AI-сгенерированном коде​

Третья категория - когда автопатч вносит уязвимость, которой не было. По данным Veracode, в 44% тестов модели вводили в кодовую базу обнаруживаемую уязвимость из OWASP Top 10. Типичные паттерны по данным OX Security:

• Хардкод секретов - AI встраивает API-ключи или credentials прямо в код при генерации "примера использования". Классика, казалось бы, но модели это делают с пугающей регулярностью
• Обход авторизации - при патчинге одной функции модель убирает проверку прав в соседней, считая её "дублированием". Для LLM два одинаковых if user.is_admin - избыточность. Для security - это defense in depth
• Устаревшие зависимости - AI подтягивает библиотеки с известными CVE (OWASP A06:2021, Vulnerable and Outdated Components)
• Ошибки бизнес-логики - модель не понимает домен и меняет поведение, открывая вектор для манипуляций

Технический долг от AI-патчей отличается от обычного тем, что он скрыт за видимостью исправления. Классический broken patch хотя бы ломает тесты. AI-broken patch проходит тесты - и ломает security.

AI-патчи как вектор атаки: TTPs и MITRE ATT&CK​

Автоматизация патч-менеджмента ИИ создаёт атакующую поверхность, которую злоумышленники уже начинают использовать. Разберём бизнес-логику угрозы и конкретные TTPs.

Зачем атакующему ваш AI-автофикс. Мотивация прямая: скомпрометировать инструмент, который автоматически мержит код в продакшен. Один успешный бэкдор через AI-патч даёт персистентный доступ, который выглядит как легитимный commit от CI/CD-бота. SOC-аналитик видит коммит от github-actions[bot] с сообщением "fix: resolve SQL injection in /api/users" - это не алерт, это рутина. Никто не полезет смотреть диф. С точки зрения insider threat модели, AI-бот - идеальный скомпрометированный субъект: у него есть доступ, доверие и автоматический мерж.

Compromise Software Supply Chain (T1195.002, Initial Access) - по аналогии описывает вектор rules file backdoors (термин из отчётов Pillar Security): атакующий манипулирует конфигурационными файлами, которые AI-модель использует при генерации кода, создавая персистентные бэкдоры в будущих патчах. Оговорка: маппинг этого вектора на T1195.002 - моя интерпретация, а не официальное соответствие MITRE ATT&CK.
Compromise Software Dependencies and Development Tools (T1195.001, Initial Access) - аналогично может описывать компрометацию AI-инструментов разработки (Copilot, Snyk как dev-tool). Тоже авторская экстраполяция.

Вредоносные инструкции в комментариях кода, README или issue-трекере заставляют LLM генерировать патч с бэкдором. Звучит как сценарий из CTF? На практике prompt injection через комментарии в коде уже воспроизводился исследователями.

Poisoned Pipeline Execution (T1677, Execution) - если AI-автофикс интегрирован в CI/CD без guardrails, атакующий с доступом к конфигурации пайплайна модифицирует промпты или подменяет модель.

Stored Data Manipulation (T1565.001, Impact) - результат атаки: изменённый код прошёл CI/CD, выглядит легитимным в git-истории, содержит уязвимость, внедрённую через AI-инструмент.

По данным CrowdStrike Global Threat Report 2025, вредоносное использование GenAI для социальной инженерии удвоилось за 2024 год. Тот же тренд логично переносится на атаки через AI-инструменты разработки - инфраструктура уже на месте.

Detection: чек-лист проверки AI-фиксов в пайплайне​

Базовая линия для мониторинга (DE.AE-01 по NIST CSF 2.0): средний размер дифа автопатча, количество затронутых файлов, частота добавления зависимостей. Отклонение - алерт на расследование (RS.AN-01).

Отдельный момент, который многие упускают: модели теряют контекст между сессиями. По данным Veracode, это напрямую влияет на корректность и повышает вероятность галлюцинаций. Практический вывод: AI-автофикс, применённый вторым в серии, может не учитывать изменения первого. Один патч за прогон, полный ресет контекста между итерациями. Иначе второй фикс может откатить первый - и вы об этом не узнаете.

Вопрос «использовать или нет» уже неактуален - команды используют нейросети для исправления уязвимостей, и этот процесс не остановить. Вопрос в архитектуре контроля. Моя позиция после года работы с тремя AI-автофиксерами: они полезны ровно настолько, насколько жёсток review-процесс поверх них. Без SAST-дифа, без чек-листа побочных эффектов, без pipeline gate - вы получаете генератор ложного чувства безопасности, который закрывает тикеты в Jira, не закрывая уязвимости. Индустрия толкает нарратив "AI починит всё быстрее людей", но 29 месяцев среднего TTR (IBM X-Force) не сократятся от того, что модель генерирует диф за секунду. Они сократятся, когда этот диф будет корректно проверен и безопасно задеплоен. При текущих 47% корректных фиксов это инструмент помощи, не замены. Кто строит процесс на иной предпосылке - к концу года обнаружит коллекцию мержнутых уязвимостей вместо коллекции закрытых CVE. Если интересно как другие команды строят ревью AI-патчей и на каких этапах ломается автоматизация - обсуждение с конфигами под разные пайплайны идёт на codeby.net.