Гонка ИИ-вооружений — как LLM вносят уязвимости в код и как другие LLM их находят

Ваш ИИ-агент только что выдал строчку. И она выглядит… подозрительно? Указатель без проверки на NULL, сериализация через pickle без валидации и логика базы данных, никак не защищённая от SQL-инъекций. Заметить одну-две таких подстав легко, но если строк больше 5 тысяч? А сколько коллег нажали Approved без должной внимательности?

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

Ирония ситуации заключается в том, что инструментом, способным разобрать эту гору потенциально уязвимого мусора, оказывается всё тот же искусственный интеллект. Зачем ручками разгребать сено, если можно поставить магнит.

Сено и магниты теперь соревнуются в гонке ИИ-вооружений в коде. С одной стороны — LLM, которые плодят уязвимости с невероятной скоростью и железной постоянностью. А с другой стороны — LLM, которые эти уязвимости ищут. И те и другие могут оказаться продуктами одних и тех же компаний. Забавно, правда?

Масштаб бедствия: не «может быть», а «скорее всего»

Тема безопасности ИИ-шного кода далеко не нова. Группа исследователей под руководством Пирса ещё в 2022-м опубликовала работу «Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions», где протестировала Copilot на 89 сценариях, релевантных CWETop 25. 

Поскольку модель обучалась на открытом коде из GitHub, содержащем ошибки, она неизбежно перенимает небезопасные паттерны. Для анализа авторы создали 89 сценариев, которые привели к генерации 1689 программ. Как итог: 40% сгенерированного кода уязвимо. «Cи» показал себя хуже всего — 50,29% провалов. Python — 38,35%.

Было выявлено, что если в файле уже присутствовал уязвимый код, вероятность того, что Copilot предложит новую уязвимую функцию, резко возрастала.

То есть баги плодили новые баги, которые затем плодили новые баги, те новые и так далее.

Можно было бы списать всё на старую модель времён динозавров (на момент исследования Copilot работал на семействе моделей OpenAI Codex, которые являются потомками модели GPT-3, специально дообученными на коде из репозиториев GitHub). 

Но в 2023-м была проведена репликация исследования. Цель авторов заключалась в том, чтобы проверить, насколько улучшилась безопасность GitHub Copilot с выходом новых версий модели и обновлений системы безопасности от GitHub. Авторы сосредоточились на репликации предыдущего исследования, ограничив область анализа языком Python.

И да, стало лучше, но не намного: процент уязвимых предложений кода снизился до 27,25%. Почти треть кода всё ещё дырявая.

Самое забавное, что в некоторых сценариях новая версия Copilot предложила больше уязвимостей, чем старая.

Но это все лирика, и давно не актуальные данные. Теперь — свежее. Отчёт Veracode за 2025 год протестировал более ста LLM на четырёх языках. Этот отчет фокусируется на оценке безопасности кода, генерируемого ИИ в ответ на конкретные задачи без указания параметров безопасности. К этому моменту ИИ-код перестал быть экзотикой и стал частью повседневной разработки. 

Исследовали безопасность кода, созданного ИИ для 80 типовых задач на четырех языках Java, JavaScript, C#, Python, связанных с четырьмя типами уязвимостей: SQL-инъекции, XSS, инъекции в логи и небезопасная криптография.

Результат: 45% кода уязвимы. Java провалилась с треском — только 28,5% сгенерированных фрагментов не содержали проблем. В исследовании авторы связывают это с тем, что Java имеет долгую историю в качестве языка серверной разработки, и она появилась еще до того, как SQL-инъекции были признаны серьезной угрозой. Поэтому обучающая выборка для Java содержит гораздо больше примеров с уязвимостями, чем для других, более современных языков.

Это не я придумал, в оригинальном труде так и сказано

ИИ в целом хорошо справился с SQL-инъекциями (80,4% безопасного кода), но крайне плохо — с XSS (13,5%) и Log Injection (12%)

Выяснилось, что размер не имеет значения (фух, ну хоть здесь). Увеличение количества параметров модели (от <20B до >100 B) практически не влияет на безопасность генерируемого кода.

А как картина выглядит в реальных проектах? Такая информация тоже есть. Исследование AI Code in the Wild посвящено изучению реального присутствия и влияния кода, созданного ИИ, в открытых проектах.

Авторы проанализировали коммиты из 1000 крупнейших репозиториев GitHub за период с 2022 по 2025 год, а также более 7000 изменений в коде, связанных с недавними уязвимостями CVE. Для этого была создана специальная система детекции (Cascade-Aggregation Framework) для отличия ИИ-кода от человеческого. (ИИ, который ищет ИИ. Те же сено и иголки, только в профиль).

Код, сгенерированный ИИ, уже составляет значительную долю в общем объёме нового кода, однако его внедрение всё же носит структурированный характер. ИИ концентрируется в связующем коде (т. н. glue code), тестах, рефакторинге, документации и другом шаблонном коде, в то время как основная логика и критически важные для безопасности конфигурации по-прежнему пишутся преимущественно людьми.

Было замечено, что некоторые семейства CWE непропорционально часто встречаются в коде, помеченном как ИИ-генерируемый. То есть почти идентичные небезопасные шаблоны кода повторяются в совершенно разных проектах из-за использования одних и тех же моделей при генерации.

Уязвимости, внесённые ИИ, в 86,8% случаев связаны с сетевыми атаками, что выше, чем у людей (80,8%). Также уровень внедрения ИИ в Java (25,45%) и C (27,33%) заметно ниже, чем в TypeScript или C#, из-за жестких требований к стабильности систем. Плюс, как вам уже стало понятно по предыдущим исследованиям, в «старых» языках программирования ИИ лажает куда чаще.

Но есть и хороший тренд. Хоть ИИ вносит уязвимости, он и помогает их исправлять. Для наглядной демонстрации в исследовании есть подобные графики:

На графиках отражена суть «гонки ИИ-вооружений» с 2022-го по 2025 год.
Вкратце: 

• График А (Объём работы): Закрашенная область показывает долю ИИ-кода в проектах. Видно, что в 2022 году доля ИИ была около 65%. А в июле 2025 нейросети пишут около 50% кода.

• График B (Нападение vs Защита): Красная линия показывает, как часто ИИ создаёт уязвимости, зелёная — как часто помогает их исправлять. То, что зелёная линия идёт выше, означает, что глобально ИИ исправляет больше багов, чем вносит. А резкий взлёт зелёной кривой в 2025 году — это момент выхода нового поколения автономных ИИ-агентов, которые начали массово детектить и латать дыры.

• График C (Критичность ошибок): Сравнивает тяжесть багов по стандарту CVSS. Сплошная линия — ИИ и пунктир — человек идут практически ноздря в ноздрю на уровне 7–7,5 баллов. В исследовании это трактуется так, что нейросети делают такие же опасные и критические уязвимости, как и живые программисты, а не только мелкие недочёты.

Также выделены 3 фазы взаимодействия ИИ и человека. 

• Фаза 1: ИИ помощник. Началась с массового релиза GitHub Copilot. Это этап всеобщих экспериментов, когда разработчики начали скармливать нейросетям всё подряд.

• Фаза 2: Совместная разработка. Период равновесия. Вау-эффект прошел, ИИ стал привычным инструментом, а разработчики научились работать с ним. Выстроилась парадигма: ИИ пишет черновик — человек проверяет.

• Фаза 3: Автономные ИИ-агенты. Переходный момент, связанный с появлением продвинутых LLM-агентов, умеющих анализировать код, строить графы вызовов и автономно писать патчи.

Для себя я отметил момент, что судя по графику(b), в третью фазу разработчики убрали руки с руля и отдали управление ИИ-агентам, тем самым показатель багов стал расти и почти достиг уровня 2022 года. Но стоит отметить, что детекция багов стала намного лучше. Исправлений старых багов больше, чем созданий новых.

Нейросеть не думает

А следует шаблонам. Это основная проблема современных LLM — их фундаментальная неспособность к глубокому логическому анализу, что исследователи называют «эффектом попугая». GPT-4o провалил элементарную задачу по определению размера буфера. Когда из стандартного алфавита в промпте специально убрали одну букву (G), ИИ в 58,4% случаев упорно выдавал размер 26 вместо 25, просто следуя заученному шаблону и игнорируя реальный контекст.

С криптографией тоже возникли проблемы. Сгенерированная ИИ реализация алгоритма SHA-1 успешно компилировалась, но выдавала неверные хеш-значения для любых входных данных. Если человек целенаправленно не проверит код на адекватность, ошибка может остаться незамеченной и дойти до продакшена.

Ситуация становится еще хуже, когда разработчик вступает в итеративный диалог с нейросетью, пытаясь доработать код. Исследование процесса многократных правок выявило «парадокс деградации»: безопасность кода стремительно падает по мере его «улучшения». Всего за пять итераций количество критических уязвимостей в изначально безопасных файлах возрастает на 37,6%. Самой деструктивной стратегией оказалась попытка оптимизации производительности — в 42,7% случаев стремление ИИ сделать код быстрее приводило к фатальным ошибкам памяти, таким как buffer overflow или use-after-free.

В 2026 году мало что поменялось

Ведь проблема не в недостатке знаний, а в архитектуре. Было установлено, что модели «знают», как писать безопасно, на этапе код-ревью они находят ошибки, но подавляют эти знания в процессе генерации ради соблюдения формата или краткости (т. н. Format-Reliability Gap). 

Например, Llama-3.1-8 B-Instruct в 90% тестов на код-ревью правильно помечает функцию sprintf как опасную и рекомендует использовать sNprintf. Однако в 93% случаев генерации кода та же модель сама использует sprintf состязательной (adversarial) генерации кода.

Этот изъян связан с выполнением задачи в условиях конфликтующих требований, а не с отсутствием знаний: когда промпты включают требования к форматированию или структурные ограничения, модель отдаёт приоритет соблюдению формата, а не рассуждениям о безопасности.

Посмотрите на рисунок.

Левая вертикальная ось (Probe Accuracy %): Показывает точность работы специальных «зондов» (линейных классификаторов), которые пытаются найти признаки безопасности во внутренних слоях модели. 

Сплошная синяя линия (Context Probe): Показывает, что уже на 0-м слое модель на 100% отличает безопасный контекст от небезопасного.

Пунктирная синяя линия (Behavioral Probe): С точностью 91,9% предсказывает финальный выбор модели (безопасный или небезопасный код) по её внутренним состояниям ещё до того, как код будет написан.

Правая вертикальная ось (): Показывает реальную вероятность появления «безопасного» токена в выдаче модели, измеренную методами Logit Lens и Tuned Lens.

Красные линии (Logit/Tuned lens): Остаются практически на нулевом уровне (около 0.15%) на протяжении почти всей сети (слои 0–30) и резко взлетают до 37–42% только на финальном 31-м слое

Авторы провели анализ выхода по слоям. Они спроецировали остаточный поток (residual stream) каждого слоя через матрицу деэмбеддинга, чтобы посмотреть на вероятностное распределение для функции sNprintf. Вероятность держится ниже 0,01% со слоя 0 по слой 28, поднимается до 0,15% на слое 30, а затем совершает скачок до 36,9% на слое 31: рост в 250 раз за один шаг.

Знания о безопасности кодируются, начиная с 0-го слоя. На протяжении почти всей глубины сети эти знания остаются «вычислительно инертными». Модель несёт эти знания внутри себя, но они никак не влияет на предсказание следующего токена. В это время нейросеть занята планированием синтаксиса и соблюдением инструкций по формату («пиши кратко», «только реализация»).

Лишь на самом последнем слое вероятность выбора безопасной функции внезапно взлетает в 250 раз.

Это открытие доказывает, что нейросети совершают ошибки не из-за глупости или дефицита обучения, а из-за архитектурного подавления знаний. Что это значит для практики? Поскольку знание о безопасности физически присутствует в модели, её не обязательно переучивать (что дорого и чревато забыванием других навыков).

Исследователи предложили метод «хирургического вмешательства»: добавление векторов управления (т. н. steering vectors) именно на 31-м слое. Такое точечное воздействие позволяет использовать скрытые знания модели и снижает количество уязвимостей на 74% при почти нулевых задержках в работе

LLM наносят ответный удар: AI ищет уязвимости в коде

Ладно, хватит про плохое. Потому что та же технология, что плодит дыры, их же и затыкает. И вот тут начинается самое интересное.

2026 год встретил нас новостью, что компания Anthropic создала кибер-оружие в лице модели Claude Mythos. Нейросеть показала пугающую способность к автономному созданию сложных цепочек эксплойтов. В ходе тестирования модель смогла самостоятельно обнаружить и эксплуатировать уязвимости нулевого дня во всех основных операционных системах и браузерах. То, что раньше требовало недель работы экспертов мирового уровня, теперь выполняется ИИ за несколько часов и стоит меньше $1000 по API. Модель находит ошибки, которые десятилетиями оставались незамеченными: например, 27-летнюю уязвимость в OpenBSD, системе, известной своей безопасностью. И ещё 16-летнюю брешь в медиабиблиотеке FFmpeg. Claude Mythos не планируют выкладывать в общий доступ и лицензия пока выдана в пользование ограниченному числу компаний.

Эпоха, когда нейросети были лишь помощниками в написании кода, официально закончилась. Мы вступили в фазу агентского аудита, где ИИ берёт на себя роль полноценного специалиста по безопасности. Когда на ваше веб-приложение с котятами совершается серия кибератак, инициированная жадным до крови и багов искусственным интеллектом, становится ясно — вы больше не на верхушке кибербезопасной цепи. Человеческих сил справиться с таким монстром не хватит ни при каких обстоятельствах. (Только если залить его дата-центры водой, иначе ноль шансов)

Чтобы ваш код был стойким, его придётся отдать на прокачку искусственному интеллекту.

Проект TitanCA, ставший результатом сотрудничества Сингапурского университета управления и агентства GovTech, представляет собой новый стандарт в обнаружении угроз. Главная архитектурная фича этой системы заключается в оркестрации специализированных агентов, что куда эффективнее, чем масштабирования одной монолитной модели. Четыре модуля, каждый заточен под свой этап: планирование, навигация по коду, анализ, валидация находок. 

1. Matcher (VulCoCo): ИИ-модуль, который ищет «клоны» уже известных уязвимостей в огромной базе данных, содержащей около 40 000 образцов. Он максимизирует охват, выявляя даже поверхностные сходства.

2. Filter (R2 Vul): Этот агент обучен отличать обоснованное рассуждение от логических галлюцинаций. Он строит цепочку выводов, доказывая, почему код может быть опасен.

3. Inspector (VulTrial): Самый инновационный этап, использующий метафору судебного процесса. Здесь созывается совет из четырех агентов: «Специалист по безопасности» предъявляет доказательства вины кода, «Автор кода» защищает свое решение, «Модератор» подводит итоги спора, а «Совет ревьюеров» выносит окончательный вердикт.

4. Adapter (PairVul): Финальный штрих, позволяющий системе адаптироваться к специфическим идиомам и фреймворкам конкретной организации, обучаясь на её ошибках.

Как итог, проанализировав более 127 000 репозиториев GitHub, имеем 203 подтвержденные уязвимости нулевого дня, что привело к публикации 118 новых CVE. 35% находок — критические, 91% — с низкой сложностью атаки. То есть чтобы воспользоваться ими большого ума не надо.

OpenAI не отстаёт. Представлен Aardvark — исследовательский ИИ-агент для поиска уязвимостей на базе GPT-5. Aardvark внедряется непосредственно в конвейер разработки CI/CD. Действует по следующему алгоритму:

• Построение модели угроз: Агент анализирует весь репозиторий, чтобы понять архитектуру проекта и то, что именно он пытается защитить.

• Непрерывное сканирование: Он отслеживает каждый новый коммит, сверяя изменения с моделью угроз и историей проекта.

• Валидация в песочнице: Обнаружив подозрительный участок, Aardvark пытается воспроизвести эксплуатацию уязвимости в изолированной среде. Это сильно снижает уровень шума и ложноположительных срабатываний, которыми страдают традиционные инструменты.

• Автоматическое патчинг: После подтверждения угрозы агент, используя возможности OpenAI Codex, предлагает готовое исправление. Разработчику остается лишь одобрить патч одним щелчком мыши

В ходе бенчмарк-тестирования Aardvark успешно выявил 92% известных и синтетических уязвимостей. Да, та же компания, чьи модели генерируют уязвимый код, теперь будет продавать инструмент для его проверки. Aardvark в данный момент находится на стадии закрытого бета-тестирования.

Инструменты, которые можно применить уже сегодня

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

• garak — опенсорсный сканер уязвимостей LLM от NVIDIA. Заточен не столько под AI-код, сколько под red-teaming самих генеративных моделей. Огромная база тестов. Он проверяет модель на галлюцинации, взломы системных промптов и утечку данных.

• SecurePilot — бесплатный сканер для AI-сгенерированного кода. Позиционируется как средство для исправления «плохого кода», который генерируют Copilot, ChatGPT или Claude.165+ правил, 10 языков.

• LLM Armor — Ориентирован на защиту приложений, использующих LLM, согласно классификации OWASP Top 10 for LLM. Работает как щит/фильтр. Он проверяет входящие промпты на предмет инъекций и исходящие ответы на предмет утечки конфиденциальных данных.

• Kereva Scanner — Специализированный сканер для Python-кода, который ищет уязвимости именно в местах вызова ИИ-библиотек (OpenAI SDK, LangChain и др.).

Ни один из них, естественно, не панацея, и не такие OP как Aardvark и TitanCA.

Ну что тут скажешь… Ваш ИИ-агент — диверсант! (шучу) (а может не шучу)
Сена все больше, конвейер всё быстрее, а магниты всё мощнее. Человек в этой системе выступает смотрящим. Если конвейер заклинит или вместо сена пойдёт солома, он должен будет отреагировать. Думаю полностью человека из этого процесса мы не исключим ещё долго.

Вывод только один: постоянно развиваться и учиться новому, потому что даже самые умные нейросети нуждаются в самых умных человеках.

© 2026 ООО «МТ ФИНАНС»