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