Как снизить риски вайб-кодинга

Порог сложности в разработке приложений сильно упал — фирменный веб-сайт, личный бот для сбора новостей или «аналитическую панель» (дашборд) на работе теперь может собрать буквально каждый, просто дав чат-боту или специальному ИИ-агенту несколько инструкций на естественном языке. К сожалению, между красивым прототипом и надежным, постоянно работающим и безопасным приложением лежит настоящая пропасть. Чтобы не стать героем еще одной печальной истории про ИИ-ошибки, не потерять деньги и ценные данные, воспользуйтесь простыми советами из нашей статьи. Они ориентированы на разработчиков без специальной подготовки или очень маленькие компании. Для крупных компаний есть другие, более сложные рекомендации.

Главные риски ИИ-кода

Хотя с помощью вайб-кодинга можно буквально за несколько часов получить работающее на вид приложение, оно скорее всего будет содержать опасные ошибки. ИИ был натренирован на примерах кода из Интернета, а там часто встречаются неоптимально написанные учебные примеры, код с ошибками и вообще неизвестно что. Иногда такой код просто не работает, но чаще ситуация сложнее и опаснее — он вроде бы работает, но «под капотом» в нем может быть грубая имитация нужной логики или серьезные ошибки. Согласно исследованию Cloud Security Alliance AI Safety Initiative, при использовании ИИ для написания кода следует учитывать следующее:

• Минимум 45% ИИ-кода содержит опасные уязвимости, такие как отсутствие проверки пользователя перед доступом к важным данным.
• Профессиональный разработчик, вооруженный ИИ, создает код в 3–4 раза быстрее, но добавляет в 10 раз больше уязвимостей в код.
• 20% ИИ-кода пытается использовать внешние библиотеки и дополнительные модули, которых не существует в природе.
• Когда в приложении предусмотрен доступ к конфиденциальным данным (платежи, личная переписка или документы), ИИ-код иногда вообще не проверят учетные данные пользователя. Данные такого приложения может прочитать любой человек из Интернета.
• В других случаях верные имя и пароль все-таки запрашиваются, но не контролируется уровень доступа — зарегистрированный пользователь видит данные всех других пользователей.
• Прямо в коде могут быть записаны ключи доступа (токены) к базам данных и ИИ-сервисам, что упрощает их кражу и усложняет замену секретов после утечек и кибератак.
• Код проекта или важные файлы собранного приложения часто публикуются на сервере без ограничения доступа, поэтому оттуда можно украсть как логику приложения, так и уже упомянутые ключи доступа.
• ИИ реализует в приложении недостаточно безопасный доступ к базам данных, позволяющий как красть данные в обход приложения, так и выполнять на сервере баз данных вообще посторонний код.
• В приложениях, допускающих обращение по API, реализуется небезопасный доступ к API: без проверки прав пользователя и контроля частоты обращений (rate limiting).

Основные принципы защиты вайб-кода

Всегда проверяйте. Код, созданный ИИ, следует воспринимать как черновик. Его всегда нужно проверять и тщательно тестировать. Желательно, чтобы это делали специалисты, но если их нет, нужно как минимум проверить приложение самостоятельно, дать проверить работающее приложение знакомым или коллегам, попросить их взглянуть на ключевые фрагменты кода. Оценить корректность кода можно и при помощи отдельного запроса к нейросети: «проверь код на соответствие практикам безопасной разработки и поищи уязвимости из OWASP TOP10».

Защищайте секреты. Никогда не вставляйте пароли, API-ключи и любые другие конфиденциальные данные в запросы к ИИ. Просите нейросеть писать код так, чтобы все секреты надежно хранились в переменных окружения (специальных скрытых настройках).

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

Сделайте безопасность явным требованием. Даже наивная и простая строчка в промпте: — «при создании кода следуй стандартам и лучшим практикам безопасности» — повышает качество кода, а если указывать более конкретные требования для нужных фрагментов кода, результат будет еще лучше.

Не доверяйте настройкам по умолчанию. Часто в вайб-коде опасен даже не сам код, а настройки. Например, приложение, которое обрабатывает конфиденциальные данные организации, опубликовано на публичном конструкторе вайб-код-приложений (Lovable и ему подобным) и по умолчанию доступно всему Интернету. Даже если оно не имеет уязвимостей, сама доступность информации посторонним уже является критической ситуацией. Поэтому все компоненты приложения, от хостинга и настроек баз данных до конфигурации процесса публикации, нужно вручную проверить и правильно настраивать. Если смысл настроек неясен, можно проконсультироваться по их оптимальным значениям у чат-бота, сказав, что целью является улучшение безопасности, и описав, для кого создано приложение.

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

Советы по защите вайб-кода

Конечно, хочется, чтобы приложения создавались по самым общим запросам вроде «сделай красивое, удобное, быстрое, надежное и безопасное приложение для Х». Но чтобы результат был действительно хорошим, каждое из требований нужно детализировать. Ниже мы приведем рекомендации по созданию типовых компонентов, которые сделают вайб-код более безопасным. Нужно подчеркнуть, что «более безопасным» не означает «полностью безопасным», — эти подходы снижают риск, но он все равно остается далеким от нуля.

Требуйте от ИИ безопасности. Задавая задачу нейросети, прямо указывайте: «напиши безопасный код, проверь данные, зашифруй пароли». Для каждого типа задач нужен свой «запрос на безопасность». Например, просите не просто «сделать форму входа в приложение», а «сделать безопасную форму входа с проверкой учетных данных, контролем аутентификации и авторизации (прав пользователя), защитой от подбора пароля, хешированием пароля по современным стандартам, передачей строго по HTTPS и без хранения секретов в коде». Такие шаблоны безопасных требований имеет смысл использовать каждый раз. Полезно иметь короткую заготовку для типовых запросов к ИИ: «осуществляй проверку внешних данных и пользовательского ввода перед обработкой», «без секретов в коде», «защита API от злоупотреблений», «ограничение прав пользователей» и «безопасные настройки по умолчанию».

Используйте готовые решения. Если в приложении нужна система работы с пользователями, потребуйте использовать популярную и уважаемую библиотеку (NextAuth, Auth0 и тому подобное), а не изобретать собственное уязвимое решение. Это самая частая причина утечек. Речь идет не только о входе и регистрации — для других потенциально опасных действий вроде загрузки файлов и обработки API-вызовов лучше брать известные фреймворки и библиотеки с уже встроенной защитой, а не собирать все с нуля.

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

Требуйте воплотить надежное шифрование. Явно указывайте, что нужно использовать современные индустриальные стандарты при передаче и хранении данных: TLS 1.3 на базе OpenSSL для передачи по сети, argon2 или bcrypt для хеширования учетных данных и так далее.

Не верьте пользовательскому вводу. Всегда просите ИИ добавлять проверки для любых данных, которые вводят люди (как в формы, так и в строки поиска). Используйте термины «параметризация» и «экранирование ввода» (parametrization, sanitization), чтобы подчеркнуть, что вам нужна защита от злоумышленников, а не просто ошибающихся пользователей.

Установите лимиты на действия пользователя. Требуйте у ИИ добавлять ограничения на количество попыток входа или запросов. Это защитит ваш проект от автоматических атак типа DoS и попыток подобрать пароль.

Скрывайте «внутренности» системы. Если на сайте происходит сбой, пользователь должен видеть простую картинку с извинениями, а не детальный отчет об ошибке с кусками вашего кода. Эта информация — подарок для хакеров.

Помните, что вы — разработчик, и вам нужна защита. Ваши собственные учетные записи, связанные с разработкой, такие как доступ к GitHub, хостингу проекта и другим ресурсам, являются лакомой добычей злоумышленников. Обязательно включите двухфакторную аутентификацию (2FA) на всех своих рабочих аккаунтах.

Создавайте резервные копии. Регулярно делайте резервные копии проекта, как локально, так и в облаке, чтобы защититься от критических ошибок ИИ, а также от кибератак. Копии должны включать в себя как исходный код приложения, так и его базы данных.

Заведите «песочницу». Тестируйте новые функции и новые версии приложения в безопасной среде — на копии сайта или приложения и на копии базы данных. Всегда проводите подробные тесты перед тем, как публиковать обновление. Это позволяет найти проблемы без риска для пользователей и их данных.

Обновляйте зависимости и проверяйте их на уязвимости. В вашем приложении наверняка появятся сторонние библиотеки и компоненты — зависимости. Их нужно регулярно обновлять (собирать приложение на базе более свежих версий компонентов), даже если само приложение не обновлялось. Эта процедура помогает вовремя закрывать известные проблемы в используемых пакетах.

Проверяйте, не произошло ли утечки секретов в репозиторий. Используйте сканеры секретов наподобие TruffleHog, чтобы проверять себя и ИИ, который может «случайно проговориться» и все же включить один из API-ключей или паролей в исходный код. С помощью сканера вы проследите, чтобы файлы с ключами и паролями не попадали в Git и не публиковались вместе с проектом.