Вайб-кодинг как мечта хакера: какие уязвимости плодит код, сгенерированный ИИ

Дмитрий Богачев

Эксперт команды AppSec Альфы, AppSec BP

Когда вы входите в мобильный банк, проверяете баланс или переводите деньги — где-то за этим интерфейсом работает код. Код, который кто-то написал, и всё чаще этот «кто-то» — не человек.

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

Проблема в том, что скорость генерации обогнала скорость проверки. Хакеры не изобрели ничего нового. Они просто заметили, что в ИИ-коде одни и те же уязвимости воспроизводятся предсказуемо и в одних и тех же местах.

В этой статье мы разбираем, как именно выглядит ИИ-код с точки зрения безопасности: что AppSec-команда Альфы видит на ревью, какие классы уязвимостей воспроизводятся системно, как адаптировать процесс проверки под новый темп и объём — и что вообще делать разработчику, которому всё чаще приходится отвечать за код, который написал не он.

Что видит AppSec, когда приходит ИИ-код

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

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

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

Чтобы понять разницу, нужно сравнить два источника уязвимостей:

1. В классической разработке уязвимости возникают из-за человеческого фактора: спешка, давление сроков, размытые требования, фокус на бизнес-сценарии вместо защитных проверок. Разработчик понимает систему, знает контекст, но под нагрузкой пропускает проверку доступа или не доходит до граничного случая. Вопрос ресурсов и приоритетов — классика.
2. С ИИ-агентом механизм другой — у него нет контекста системы, агент решает задачу, которую ему поставили, самым коротким путём к рабочему результату. 

Модель решает задачу так, как её сформулировали, и стремится получить рабочий результат самым простым способом. Если в задаче явно не заданы требования к безопасности, такие проверки модель просто не добавляет: валидацию и нормализацию входных данных, проверки авторизации и разграничения доступа, защиту от типовых веб-уязвимостей и другие базовые защитные механизмы.

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

Какие уязвимости находят, или пять угроз вайб-кодинга

Теперь, когда понятна сама природа проблемы, можно посмотреть, где именно она проявляется на практике. Ниже — пять видов уязвимостей, которые особенно часто продолжают всплывать в коде, сгенерированном ИИ, при текущем уровне моделей, инструментов и самой парадигмы их использования.

1. Ошибка в бизнес-логике

Функция работает на нормальных данных, юнит-тесты и функциональные тесты на основных сценариях проходят. Проблема появляется там, где логика зависит от контекста, которого агент не знал.

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

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

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

2. Ошибка в проверке прав доступа

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

Как правило, модель не пытается изобретать собственную небезопасную криптографию, а переиспользует типовые схемы входа. Проблемы возникают позже в тех проверках, которые должны срабатывать после аутентификации: имеет ли этот пользователь право выполнять именно это действие и работать именно с этим объектом.

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

В вайб-кодинге это особенно типичный сбой: в задаче обычно формулируют основной сценарий показать данные, дать доступ, выполнить операцию, но отдельно не проговаривают проверки прав доступа. Модель добросовестно решает поставленную задачу, но не добавляет защитную логику, если её не потребовали явно.

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

3. Ошибки в обработке пользовательского ввода

На текущем уровне развития моделей этот паттерн сохраняется вне зависимости от конкретного инструмента.Что у Claude, что у GPT, что у Gemini проблема обычно одна и та же: модель строит рабочую логику, но не всегда достаточно жёстко ограничивает и проверяет данные, которые приходят извне.

Это скорее системная история. Мы видим, что такие проблемы встречаются независимо от конкретной модели ИИ.

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

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

4. Ошибки в выборе и использование зависимостей

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

Проблема здесь в том, что модель подбирает зависимость под задачу, а не оценивает её состояние и риски для проекта. Её цель — быстро закрыть сценарий, а не проверить, насколько библиотека жива, кто её поддерживает и какие риски она принесёт в проект через несколько месяцев. Дополнительная сложность в том, что модель может опираться не на актуальное состояние экосистемы, а на тот срез данных, который был у неё во время обучения. Поэтому часть уязвимостей, появившихся недавно, она просто не учитывает: для модели библиотека может выглядеть нормальной, хотя в реальности по ней уже вышли новые CVE или серьёзные предупреждения сообщества.

Поэтому всё, что ИИ предлагает подключить извне, нужно проверять отдельно — и не только вручную, но и через SCA-анализ в CI/CD. Именно связка из актуального сканирования зависимостей и security gate остаётся здесь самым надёжным способом не пропускать в прод известные уязвимые библиотеки.

5. Подмена skill и правил ИИ-инструмента

Это атака не на приложение, а на сам инструмент разработки. Злоумышленник публикует вредоносный навык или подменяет правила работы агента, после чего тот начинает читать локальные секреты, тянуть данные из файлов и незаметно менять поведение генерации кода. Для атакующего это удобный способ зайти в среду разработки через доверенное расширение, а не ломать код напрямую.

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

Как проверять код, который написал ИИ агент

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

• Первое — границы доверия: откуда приходят данные, что считается доверенным, где нужны валидация, нормализация, экранирование и ограничение доступа к объектам.
• Второе — авторизация: имеет ли пользователь право на конкретное действие с конкретным объектом, с учётом ролей, принадлежности данных и допустимости перехода состояния.
• Третье — опасные операции. Это всё, что связано с получением чужих данных, изменением состояния, работой с файлами, токенами, сессиями и внешними сервисами.

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

На уровне архитектуры должна использоваться эшелонированная защита с применением правильно построенной архитектуры, т.е. использование централизованных шлюзов (API Gateway), провайдеров аутентификации и необходимых классов средств защиты (FW, WAF, IPS и т.д.), а так же применяться необходимые механизмы защиты, включая сегментацию, логирование и другие домены.

Как адаптировать процесс ревью

Когда в команде появляются ИИ-агенты, первый инстинкт — придумать для них отдельный регламент. Но на практике проблема оказалась не в том, что AppSec столкнулся с новым классом уязвимостей, а в том, что прежний объём ручного контроля перестал выдерживать новый темп генерации.

Базовые принципы ревью не изменились: security gates, моделирование угроз, проверка зависимостей, контроль доступа и базовые этапы SSDLC по-прежнему работают. Меняется не логика защиты, а её точка приложения. Если раньше безопасность часто подключалась уже после того, как код был написан, то теперь этого недостаточно.

Проверки всё чаще выполняются до прохождения security gates, в том числе с использованием агентов, скиллов и инструментов автоматизации. За счёт снижения порога входа это стало проще и дешевле, что напрямую ускоряет поставки и снижает количество блокировок. Но это пока не универсальная практика, а скорее формирующееся поведение отдельных команд.

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

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

Как это пытаются решить не только в Альфе

Пока компании самостоятельно разбирается с рисками вайб-кодинга, официальный регулятор уже зафиксировал часть из них. Приказ ФСТЭК №117, который вступил в силу 1 марта 2026 года и заменил приказ №17, который регулировал защиту информации в государственных информационных системах больше десяти лет.

Для разработчиков там есть конкретика: закрывать критические уязвимости за 24 часа, высокие — за 7 дней, сканировать все активы не реже раза в месяц, для веб-приложений обязателен WAF. Отдельно приказ фиксирует векторы угроз, которых просто не существовало в 2013 году: использование ИИ при атаках, облачные среды, контейнеры.

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

Новая область, а не новая роль

Когда мы начинали работу над этой статьёй, у нас был вопрос: появляется новая роль — человек, который понимает и ИИ-генерацию кода, и безопасность? Но эксперт с такой формулировкой не согласился.

Я бы описывал это не как новую отдельную роль, а как появление новой области безопасности. Речь уже не только про проверку кода, сгенерированного ИИ, а про защиту самих агентных систем, их инфраструктуры и рисков, которые они создают вокруг процесса разработки.

Дмитрий БогачевЭксперт команды AppSec Альфы, AppSec BP

Роль можно нанять. Область — нет. Классический AppSec по-прежнему отвечает за безопасность приложения, но вокруг ИИ-инструментов и агентных систем уже формируется дополнительный слой задач: их поведение, права, память, правила работы, интеграции и среда, в которой они действуют. Это не задача одного нового «специалиста по ИИ», а расширение самой области безопасности. Это MLSecOps — и он не укладывается в должностную инструкцию одного человека.

Тем, кому интересно работать с ИИ-агентами в продакшене и видеть задачи безопасности изнутри — в Альфе открыты вакансии.