Ваш ИИ ошибался, ошибается и будет ошибаться

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

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

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

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

---

Масштаб бедствия

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

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

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

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

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

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

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

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

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

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

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

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

Оригинальный текст. Отрывок.

We believe that this again reflects the nature 
of the training data. Java has a long 
history as a server-side implementation 
language, and it predates the recognition of 
SQL injection as a vulnerability.

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

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

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

Авторы проанализировали коммиты из 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 провалил элементарную задачу ^[8] по определению размера буфера. Когда из стандартного алфавита в промпте специально убрали одну букву (G), ИИ в 58,4% случаев упорно выдавал размер 26 вместо 25, просто следуя заученному шаблону и игнорируя реальный контекст.

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

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

---

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

Ведь проблема не в недостатке знаний, а в архитектуре. Было установлено, что модели «знают», как писать безопасно, на этапе код-ревью они находят ошибки, но подавляют эти знания ^[11] в процессе генерации ради соблюдения формата или краткости (т. н. 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 раз за один шаг.

Для любознательных

Кстати, много интересного о эмбедингах вы можете узнать из моей статьи ^[12].

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

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

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

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

---

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

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

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

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

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

Проект TitanCA ^[16], ставший результатом сотрудничества Сингапурского университета управления и агентства 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 — исследовательский ИИ-агент для поиска уязвимостей ^[17] на базе GPT-5. Aardvark внедряется непосредственно в конвейер разработки CI/CD. Действует по следующему алгоритму:

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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