Основные угрозы вайб-кодинга и LLM-ассистентов разработчика

От чего защищаться разработчикам ПО, активно применяющим ИИ-ассистентов и вайб-кодинг

Хотя польза ИИ-ассистентов на работе остается спорной темой, увереннее всего они внедряются в разработку ПО. Здесь LLM играют самые разные роли — от рефакторинга и документирования до создания приложений «под ключ». К традиционным проблемам ИБ в разработке здесь добавляются уникальные уязвимости ИИ-моделей. На этом стыке областей новые ошибки и проблемы возникают едва ли не еженедельно.

Уязвимый ИИ-код

Когда языковая модель создает код, в нем могут содержаться ошибки и программные уязвимости. Ведь для обучения LLM брали данные из Интернета, в том числе тысячи примеров не очень качественного кода. Недавнее исследование Veracode показало, что ведущие ИИ-модели стали генерировать значительно более корректный код — в 90% случаев он компилируется без ошибок. Два года назад успешно компилировалось менее 20% кода. А вот безопасность кода не улучшилась — 45% созданного моделью кода содержало классические программные уязвимости из OWASP Top 10, и за два года мало что изменилось. Исследование проводилось на сотне популярных разновидностей LLM и фрагментах кода, написанных на Java, Python, C# и JavaScript. Это означает, что вне зависимости от того, в каком режиме и каком сервисе применяется LLM — дописывание кода в Windsurf или вайб-кодинг в Lovable — готовому приложению требуется очень тщательная проверка на уязвимости. В реальности ее часто не проводят — по данным исследования Wiz, 20% приложений созданных при помощи вайб-кодинга, содержат серьезные уязвимости или ошибки конфигурации.

В качестве примеров подобных ошибок часто приводят кейс скандально известного из-за двух крупных утечек данных приложения Tea, предназначенного исключительно для женщин. Но в реальности это приложение было создано гораздо раньше, чем появился вайб-кодинг. Виноват ли в проблемах Tea ИИ, мы окончательно узнаем в суде. Но ИИ-программирование точно стало причиной бед стартапа Enrichlead. Его основатель хвастался в соцсетях, что весь программный код его платформы написан с помощью Cursor AI: «ноль кода написано вручную». Но через несколько дней после запуска проекта выяснилось, что он полон тривиальных ИБ-уязвимостей и любой желающий может пользоваться платными функциями или модифицировать данные. В результате проект пришлось закрыть, потому что доработать код до нужного уровня при помощи Cursor у автора не получилось. Впрочем, он не унывает и пробует запустить новые проекты, основанные на вайб-кодинге.

Основные виды уязвимостей в ИИ-коде

Хотя феномену программирования с ИИ всего год-два, уже накопилась статистика по типовым ошибкам в сгенерированном коде. Как правило это:

• отсутствие проверок ввода, очистки ввода от посторонних символов и другие детские ошибки, ведущие к классическим уязвимостям вроде cross-site scripting (XSS) и SQL injection;
• API-ключи и другие секреты, зашитые прямо в веб-страницу и видимые пользователю в ее коде;
• логика аутентификации, целиком реализованная на стороне клиента, прямо в коде сайта, работающая в браузере. Ее несложно подделать для обхода любых проверок;
• ошибки журналирования — от недостаточной фильтрации при записи в журнал до полного отсутствия журналов;
• избыточно мощные и опасные функции — ИИ-модель оптимизирована на выдачу кода, решающего задачу кратчайшим путем. Но кратчайший путь часто небезопасен. Азбучный пример — применение в коде функции eval для математических вычислений над данными, введенными пользователем. Это открывает дорогу к выполнению произвольного кода в созданном приложении;
• устаревшие или несуществующие зависимости. ИИ-код часто ссылается на старые версии библиотек, делает устаревшие и небезопасные API-вызовы или даже требует подключить библиотеку, не существующую в природе. Последнее особенно опасно, потому что атакующие могут создать вредоносную библиотеку с правдоподобным именем, и ИИ-агент включит ее в реальный проект.

В систематическом исследовании авторы сканировали ИИ-код на наличие недостатков, входящих в Top 25 видов дефектов (MITRE CWE). Наиболее часто встречались такие ошибки, как CWE-94 (инъекция кода), CWE-78 (инъекция команд ОС), CWE-190 (целочисленное переполнение), CWE-306 (отсутствующая аутентификация), CWE-434 (неограниченная загрузка файлов).

Громким примером CWE-94 стал недавний инцидент с компрометацией проекта NX build, о котором мы писали. Троянизировать популярный инструмент разработки удалось благодаря похищению токена, дающего права публикации новых версий продукта. А похитили его, эксплуатируя уязвимость, внесенную простым фрагментом кода, созданного ИИ.

Опасные промпты

Известная среди разработчиков присказка «сделано строго по техническому заданию» уместна и при работе с ИИ-ассистентом. Если запрос для создания функции или приложения недостаточно четкий и не упоминает аспекты безопасности, вероятность генерации уязвимого кода значительно возрастает. Специальное исследование показало, что даже общие ремарки в промпте наподобие «make sure the code follows best practices for secure code» вдвое снижают процент уязвимого кода.

Но наибольшую эффективность дают более конкретные рекомендации, адаптированные для используемого языка программирования и призывающие не делать программных ошибок из списков MITRE или OWASP. Большой набор подобных инструкций собран в GitHub Wiz, их рекомендуется добавить в системный промпт ИИ-ассистента с помощью файлов claude.md, .windsurfrules и подобных.

Ухудшение безопасности при доработках

При многократных доработках кода по дополнительным запросам безопасность этого кода снижается. К такому выводу пришли в свежем исследовании, где GPT-4o до 40 раз просили доработать написанный ей же код, сканируя результат на уязвимости после каждого раунда. Уже после пяти раундов доработок в коде было на 37% больше критических уязвимостей, чем в начале. В исследовании независимо тестировались 4 стратегии написания промптов: в одном подчеркивались требования эффективности, в другом — безопасности, в третьем — требования новых возможностей, четвертый был нечетким.

В случае когда промпты фокусировались на новых функциях, в код добавилось 158 уязвимостей, включая 29 критических. Когда промпт подчеркивал необходимость написать безопасный код, дефектов было гораздо меньше, но все равно много — 38 новых уязвимостей, включая 7 критических.

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

Незнание индустриального контекста

Во многих отраслях, таких как финансы, здравоохранение и логистика, существуют технические, организационные и юридические требования, которые нужно учитывать при разработке приложений. ИИ-ассистенты обо всем этом не знают. Эту проблему часто называют «отсутствием глубины», missing depth. Поэтому способы хранения и обработки персональных, медицинских и финансовых данных, предписываемые региональным или индустриальным регулированием, не будут учтены ИИ-разработчиком. Например, ассистент может написать математически корректную функцию для вычисления процентов по вкладам, но не учесть в ней законодательные требования к округлению. Особые требования по хранению медицинских карт включают подробное журналирование каждой попытки доступа — ИИ по умолчанию не внедрит в код нужный уровень протоколирования.

Ошибочная конфигурация приложений

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

• базы данных, необходимые приложению, создаются с широкими правами доступа извне — так возникают утечки вроде Tea/Sapphos. Из-за этого всю базу данных можно фактически выкачать или удалить в обход приложения;
• приложения для внутренних нужд компании доступны без аутентификации всему миру;
• приложениям выдаются высокие права доступа к важным базам данных. В сочетании с уязвимостями ИИ-кода это упрощает SQL-инъекции и другие атаки.

Платформенные уязвимости

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

Угрозы этапа разработки

Риски создает уже само наличие ассистента с широкими правами доступа на компьютере разработчика. Вот несколько тому примеров.

Уязвимость CurXecute (CVE-2025-54135) позволяла «попросить» популярный инструмент ИИ-разработки, Cursor, запустить произвольные команды на компьютере разработчика. Достаточно, чтобы в Cursor был подключен MCP-сервер (Model Context Protocol), через который к ИИ-агенту может обратиться посторонний. Ситуация совершенно типовая — MCP-серверы предоставляют ИИ доступ к сообщениям из Slack, позволяют забирать описания проблем из таск-трекера Jira и так далее. Промпт-инъекцию можно провести через любой подобный канал.

Уязвимость EscapeRoute (CVE-2025-53109) позволяла записывать и читать произвольные файлы на диске разработчика. Дефект содержался в популярном MCP-сервере Anthropic, который позволяет ИИ-агенту читать и записывать файлы в системе. Ограничения доступа, предусмотренные сервером, на практике не работали.

Вредоносный MCP-сервер, позволяющий ИИ-агенту принимать и отправлять e-mail через сервис Postmark, одновременно пересылал всю переписку на скрытый почтовый адрес. О перспективе появления вредоносных MCP-серверов мы писали в сентябре.

Уязвимость в инструменте командной строки Gemini CLI позволяла запускать произвольные команды на компьютере, если разработчик всего лишь просил ИИ-ассистента изучить код нового проекта. Вредоносная инъекция срабатывала из файла readme.md.

ИИ-ассистент Q Developer Extension, созданный Amazon и поставляющийся в виде расширения для Visual Studio Code, кратковременно содержал инструкции по удалению всей информации с компьютера разработчика. Автор модификации воспользовался ошибкой разработчиков Amazon и смог добавить этот вредоносный промпт в публично доступный код ассистента, не имея особых прав. К счастью, из-за небольшой ошибки в коде он не срабатывал.

Уязвимость в агенте Claude Code (CVE-2025-55284) позволяла извлекать данные с компьютера разработчика через DNS-запросы. Промпт-инъекция могла быть внедрена в любой код, анализируемый агентом, и содержала обращение к «невинным» инструментам, которые запускаются без дополнительного подтверждения.

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

Промпт-инъекция, размещенная в комментарии к исходному коду приложения, побуждала ИИ-среду разработки Windsurf автоматически добавлять в свою «долговременную память» вредоносные инструкции, которые могут месяцами красть информацию с компьютера.

В инциденте с компрометацией NX build инструменты командной строки для обращения к Claude, Gemini и Q использовались для поиска паролей и ключей, которые можно украсть из зараженной системы.

Как пользоваться ИИ-кодом безопасно

Существенно снизить (но далеко не обнулить) уровень риска при использовании ИИ-кода можно, применяя комплекс организационных и технических мер:

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

10.10.2025