Как ИИ-код меняет кибербезопасность и чего ждать разработчикам и вайб-кодерам.
Хотя польза ИИ-ассистентов на работе остается спорной темой, увереннее всего они внедряются в разработку ПО. Здесь LLM играют самые разные роли — от рефакторинга и документирования до создания приложений «под ключ».
К традиционным проблемам ИБ в разработке здесь добавляются уникальные уязвимости ИИ-моделей. На этом стыке областей новые ошибки и проблемы возникают едва ли не еженедельно.
Недавнее исследование Veracode показало, что ведущие ИИ-модели стали генерировать значительно более корректный код — в 90% случаев он компилируется без ошибок. Два года назад успешно компилировалось менее 20% кода. А вот безопасность кода не улучшилась — 45% созданного моделью кода содержало классические программные уязвимости из OWASP Top 10, и за два года мало что изменилось.
Исследование проводилось на сотне популярных разновидностей LLM и фрагментах кода, написанных на Java, Python, C# и JavaScript. Это означает, что вне зависимости от того, в каком режиме и каком сервисе применяется LLM — дописывание кода в Windsurf или вайб-кодинг в Lovable — готовому приложению требуется очень тщательная проверка на уязвимости.
В качестве примеров подобных ошибок часто приводят кейс скандально известного из-за двух крупных утечек данных приложения Tea, предназначенного исключительно для женщин.
Но в реальности это приложение было создано гораздо раньше, чем появился вайб-кодинг. Виноват ли в проблемах Tea ИИ, мы окончательно узнаем в суде. Но ИИ-программирование точно стало причиной бед стартапа Enrichlead. Его основатель
Но через несколько дней после запуска проекта выяснилось, что он полон тривиальных ИБ-уязвимостей и любой желающий может пользоваться платными функциями или модифицировать данные. В результате проект пришлось закрыть, потому что доработать код до нужного уровня при помощи Cursor у автора не получилось. Впрочем, он не унывает и пробует запустить новые проекты, основанные на вайб-кодинге.
Громким примером CWE-94 стал недавний инцидент с компрометацией проекта NX build. Троянизировать популярный инструмент разработки удалось благодаря похищению токена, дающего права публикации новых версий продукта. А похитили его, эксплуатируя уязвимость, внесенную простым фрагментом кода, созданного ИИ.
Но наибольшую эффективность дают более конкретные рекомендации, адаптированные для используемого языка программирования и призывающие не делать программных ошибок из списков MITRE или OWASP. Большой набор подобных инструкций собран в GitHub Wiz, их рекомендуется добавить в системный промпт ИИ-ассистента с помощью файлов claude.md, .windsurfrules и подобных.
В исследовании независимо тестировались 4 стратегии написания промптов: в одном подчеркивались требования эффективности, в другом — безопасности, в третьем — требования новых возможностей, четвертый был нечетким.
В случае когда промпты фокусировались на новых функциях, в код добавилось 158 уязвимостей, включая 29 критических. Когда промпт подчеркивал необходимость написать безопасный код, дефектов было гораздо меньше, но все равно много — 38 новых уязвимостей, включая 7 критических.
При этом промпт, приоритизирующий безопасность, привел к написанию кода с наибольшим процентом ошибок в функциях, относящихся к криптографии.
Эту проблему часто называют «отсутствием глубины», missing depth. Поэтому способы хранения и обработки персональных, медицинских и финансовых данных, предписываемые региональным или индустриальным регулированием, не будут учтены ИИ-разработчиком. Например, ассистент может написать математически корректную функцию для вычисления процентов по вкладам, но не учесть в ней законодательные требования к округлению.
Особые требования по хранению медицинских карт включают подробное журналирование каждой попытки доступа — ИИ по умолчанию не внедрит в код нужный уровень протоколирования.
Это делает вайб-кодеров привязанными к платформе во всех аспектах, включая подверженность платформенным уязвимостям и зависимость от практик безопасности платформы. Например, в июле была обнаружена уязвимость в платформе Base44, из-за которой злоумышленник без аутентификации мог получать доступ к любым приватным приложениям.
Автономный ИИ-агент Replit
Промпт-инъекция, размещенная в комментарии к исходному коду приложения, побуждала ИИ-среду разработки Windsurf
В инциденте
Хотя польза ИИ-ассистентов на работе остается спорной темой, увереннее всего они внедряются в разработку ПО. Здесь 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-вызовы или даже требует подключить библиотеку, не существующую в природе. Последнее особенно опасно, потому что атакующие могут создать вредоносную библиотеку с правдоподобным именем, и ИИ-агент включит ее в реальный проект.
Громким примером 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 (
Для просмотра ссылки необходимо нажать Вход или Регистрация) позволяла «попросить» популярный инструмент ИИ-разработки, Cursor, запустить произвольные команды на компьютере разработчика. Достаточно, чтобы в Cursor был подключен MCP-сервер (Model Context Protocol), через который к ИИ-агенту может обратиться посторонний. Ситуация совершенно типовая — MCP-серверы предоставляют ИИ доступ к сообщениям из Slack, позволяют забирать описания проблем из таск-трекера Jira и так далее. Промпт-инъекцию можно провести через любой подобный канал.
- Уязвимость EscapeRoute (
Для просмотра ссылки необходимо нажать Вход или Регистрация) позволяла записывать и читать произвольные файлы на диске разработчика. Дефект содержался в популярном MCP-сервере Anthropic, который позволяет ИИ-агенту читать и записывать файлы в системе. Ограничения доступа, предусмотренные сервером, на практике не работали.
Для просмотра ссылки необходимо нажать
Вход или Регистрация
, позволяющий ИИ-агенту принимать и отправлять e-mail через сервис Postmark, одновременно пересылал всю переписку на скрытый почтовый адрес. О перспективе появления
Для просмотра ссылки необходимо нажать
Вход или Регистрация
мы писали в сентябре.- Уязвимость в инструменте командной строки Gemini CLI позволяла
Для просмотра ссылки необходимо нажать Вход или Регистрацияна компьютере, если разработчик всего лишь просил ИИ-ассистента изучить код нового проекта. Вредоносная инъекция срабатывала из файла readme.md.
- ИИ-ассистент Q Developer Extension, созданный Amazon и поставляющийся в виде расширения для Visual Studio Code, кратковременно содержал
Для просмотра ссылки необходимо нажать Вход или Регистрацияс компьютера разработчика. Автор модификации воспользовался ошибкой разработчиков Amazon и смог добавить этот вредоносный промпт в публично доступный код ассистента, не имея особых прав. К счастью, из-за небольшой ошибки в коде он не срабатывал.
- Уязвимость в агенте Claude Code (
Для просмотра ссылки необходимо нажать Вход или Регистрация) позволяла извлекать данные с компьютера разработчика через DNS-запросы. Промпт-инъекция могла быть внедрена в любой код, анализируемый агентом, и содержала обращение к «невинным» инструментам, которые запускаются без дополнительного подтверждения.
Автономный ИИ-агент Replit
Для просмотра ссылки необходимо нажать
Вход или Регистрация
, потому что решил, что база требует очистки. При этом он нарушил прямую инструкцию на внесение изменений (code freeze). За шокирующим поведением ИИ-агента можно упустить важную архитектурную деталь — на момент инцидента в Replit
Для просмотра ссылки необходимо нажать
Вход или Регистрация
на базы данных тестового и основного (реально эксплуатируемого) проекта.Промпт-инъекция, размещенная в комментарии к исходному коду приложения, побуждала ИИ-среду разработки Windsurf
Для просмотра ссылки необходимо нажать
Вход или Регистрация
, которые могут месяцами красть информацию с компьютера.В инциденте
Для просмотра ссылки необходимо нажать
Вход или Регистрация
инструменты командной строки для обращения к Claude, Gemini и Q использовались для поиска паролей и ключей, которые можно украсть из зараженной системы.Как пользоваться ИИ-кодом безопасно
Существенно снизить (но далеко не обнулить) уровень риска при использовании ИИ-кода можно, применяя комплекс организационных и технических мер:- внедрять автоматическую проверку сгенерированного ИИ-кода прямо по мере его написания при помощи оптимизированных инструментов
Для просмотра ссылки необходимо нажать Вход или Регистрация;
- внедрять требования безопасности в системные промпты используемых ИИ-сред;
- проводить детальный разбор кода опытным живым специалистом. Вооружить его специализированными ИИ-инструментами анализа безопасности, чтобы повысить эффективность анализа;
- тренировать разработчиков писать безопасные промпты и в целом обучать безопасному применению ИИ .
Для просмотра ссылки необходимо нажать
Вход или Регистрация