Уязвимости ПО, созданного с помощью вайб-кодинга
Еще несколько лет назад написать работающую программу без знания языков программирования и принципов построения алгоритмов было невозможно. А сегодня это способны делать люди без каких-либо специальных знаний: маркетологи, аналитики, менеджеры отделов продаж и даже секретари с помощью таких ИИ-инструментов, как Cursor, GitHub Copilot или Claude Code. Явление получило широкое распространение и было названо «вайб-кодингом». Суть его в том, что человек описывает задачу на естественном языке, модель генерирует код, который сама же помогает развернуть и… инструмент запускается! Все это происходит быстро, дешево, а главное — не нужно стоять в очереди к вечно занятым и неприступным разработчикам.
Для бизнеса это выглядит настоящей находкой. Зависимость от дефицитных и дорогих специалистов снижается, путь от идеи до рабочего прототипа становится сильно короче. Но у этой очевидной выгоды есть и обратная сторона, которая не сразу бросается в глаза, и именно о ней я сегодня и хочу поговорить.
Чем результат вайб-кодинга отличается от «просто плохого» кода
Плохой код встречался всегда — столько, сколько существуют невнимательные, ленивые или безответственные люди. Но природа уязвимостей, которые возникают при вайб-кодинге, принципиально отличается от продукции, произведенной при помощи «кривых человеческих рук».
Языковая модель воспроизводит паттерны из датасетов, на которых она обучалась, но при этом она не понимает контекст конкретного приложения, не знает, с какими данными оно будет работать, не учитывает архитектуру системы, в которую ее будут встраивать. Результат — код, который бойко работает в демо и сразу же разваливается в продакшене. Или, что еще хуже, все-таки работает, но содержит в себе системные дыры: токены и пароли, прописанные прямо в тексте программы, отсутствие валидации входных данных, небезопасные сторонние зависимости и открытые API-эндпоинты.
Проблема — и проблема принципиальная — в том, что вайб-кодер этих уязвимостей не видит. Он не может построчно прочитать код, он смотрит только на результат. Он не обладает навыками анализа кода, откуда! С его стороны это не халтура и не небрежность — я бы сказал, что это структурная слепота, которая органически присуща самому подходу.
Векторы атак: что реально угрожает вайб-коду
С позиции практикующего специалиста по информационной безопасности картина выглядит так: вайб-кодинг существенно расширяет поверхность возможной атаки — причем с наименее защищенных сторон.
Давайте порассуждаем о потенциальных векторах. Первый и самый нелепый — утечка учетных данных через репозиторий. Разработчик-непрофессионал сохраняет код вместе с паролями и токенами доступа, которые модель вписала прямо в листинг программы. Репозитории регулярно индексируются, и злоумышленники рано или поздно их находят.
Второй — классические SQL-инъекции (когда в форму вводится, например, команда к базе данных) или XSS (межсайтовый скриптинг, исполняемый код, вставляемый в форму), который сохраняется на сервере и впоследствии исполняется в браузерах других пользователей. Так какой-нибудь внутренний инструмент для сбора заявок или выгрузки отчетов, написанный вайб-кодером, может не иметь от таких атак вообще никакой защиты. Для злоумышленника это просто подарок — протяни руку и возьми.
Третий вектор — небезопасные API. Эндпоинт без аутентификации или с предсказуемой структурой запросов — для вайб-кодинга это общее место. Автор просто не знал, что такое нужно предусматривать.
Четвертый — уязвимые сторонние библиотеки. Модель подключает зависимости, которые были актуальны на момент ее обучения. Там могут встречаться в том числе устаревшие пакеты с уязвимостями, для которых уже существуют публично задокументированные способы эксплуатации. Они были бы сразу обнаружены при аудите такого кода специалистом, но если до аудита дело не дошло…
Каждый из этих векторов по отдельности ничего нового собой не представляет. Но вайб-кодинг воспроизводит их одновременно и массово — в инструментах, которые никто не воспринимает как объект потенциальной атаки. Преступнику в этом случае не нужно преодолевать защищенный периметр, достаточно найти внутренний инструмент, написанный сотрудником без ИБ-компетенций. Например, форму для сбора заявок от клиентов, простенькую CRM-таблицу с веб-интерфейсом или утилиту для выгрузки отчетов, собранную за два часа, чтобы не ломиться к занятым разработчикам и не упрашивать их помочь. И увы, мы видим, что таких инструментов в компаниях становится все больше.
Как понять, когда нужно начинать беспокоиться
Руководителю не нужно самому разбираться в коде, чтобы задавать сотрудникам правильные вопросы, могущие предотвратить беду. Вот несколько простых признаков, которые должны его насторожить:
- инструмент написан за один-два дня человеком, у которого нет профильного технического образования;
- code review не проводился или проводился формально;
- не проводился аудит зависимостей;
- новый инструмент работает с реальными данными — клиентскими, финансовыми или, не дай бог, персональными.
Если хотя бы два из этих условий имели место одновременно — то это повод для серьезного разговора с командой, а возможно, и для организации внешней проверки всей ИТ-инфраструктуры.
Что сделать, чтобы перестать беспокоиться
Запрещать вайб-кодинг бессмысленно и даже контрпродуктивно. Эти инструменты уже используются — гласно или втихомолку, в обход корпоративных политик. Задача не в том, чтобы остановить этот процесс, а в том, чтобы выстроить минимально достаточный контроль над ним.
Я бы предложил рассмотреть три уровня мер.
- Организационный: любой код, который работает с реальными данными, должен пройти проверку вне зависимости от того, кто его написал. Это должно быть железным правилом.
- Процессный: статический анализ кода должен быть обязательным этапом перед выводом в продакшен. Сегодня и его можно автоматизировать, инструментов для этого достаточно, и порог входа невысок.
- Экспертный: при внедрении любого нового инструмента, работающего с чувствительными данными, есть смысл подстраховаться и положиться на внешний аудит. Не потому что «своим не доверяем», а потому что взгляд изнутри системы обычно заметно ограничен, если не сказать замылен.
В общем, вайб-кодинг — это просто инструмент, а не троянский конь с врагом внутри. Он становится ею только тогда, когда результат его применения воспринимается как готовый продукт. Воспринимайте код, написанный с помощью ИИ, как черновик. Да, неплохой черновик, иногда почти готовый к публикации. Но все-таки черновик.
Опубликовано 14.05.2026
