Перед выводом кода, написанного с ИИ (vibe code), в продакшен нужно проверить восемь вещей: не утекли ли секреты, проверяется ли авторизация на сервере, закрыты ли правила доступа к базе данных, валидируется ли ввод, реальны ли зависимости, есть ли rate limit, не раскрывают ли лишнего ошибки и логи и разделены ли среды. Это важно, потому что в отчёте Veracode 2025 года 45% сгенерированных образцов кода содержали уязвимость из OWASP Top 10.
Пройти путь от идеи до работающего приложения за несколько дней сегодня обычное дело. Прототип, собранный в Cursor, Claude Code, Lovable или Bolt, может выглядеть безупречно на демо. Проблема в том, что расстояние между «работает на демо» и «можно открывать реальным пользователям» невидимо.
В этой статье мы пытаемся сделать это расстояние измеримым: что говорят исследования о коде, созданном ИИ, какие уязвимости встречаются чаще всего и какие проверки нужно провести до запуска.
Работающий код и безопасный код не одно и то же: что говорят исследования
Языковые модели отлично пишут код, который выполняет запрошенное поведение. Но выполнить запрос и гарантировать, что им нельзя злоупотребить, это разные задачи. Попросите «страницу профиля пользователя», и модель её сделает. Вопрос «что будет, если другой пользователь поменяет ID в URL?» она обычно не задаёт, пока его не зададите вы.
Природа vibe coding это усиливает. Когда код принимается без построчного чтения, решения по безопасности просто не принимаются. Приложение работает, потому что проверялся единственный сценарий: добросовестный пользователь.
Насколько часто это оборачивается уязвимостями, показывают уже не догадки, а измерения. Выделяются два исследования.
Veracode 2025 GenAI Code Security Report протестировал более 100 языковых моделей на задачах, чувствительных к безопасности, на Java, JavaScript, Python и C#. 45% сгенерированных образцов кода содержали уязвимость из OWASP Top 10. В задачах на cross-site scripting (XSS) доля неудач достигла 86%.
Отчёт CodeRabbit за 2025 год рассмотрел реальные pull request: 320 PR с участием ИИ против 150 PR, написанных только людьми. В PR с ИИ в среднем было 10,83 проблемы, в человеческих 6,45. По категориям разница ещё заметнее:
| Тип уязвимости | В коде с участием ИИ |
|---|---|
| Cross-site scripting (XSS) | в 2,74 раза чаще |
| Небезопасная прямая ссылка на объект (IDOR) | в 1,91 раза чаще |
| Неправильная обработка паролей | в 1,88 раза чаще |
Здесь важна честность: часто повторяемая фраза «в коде ИИ в 2,74 раза больше уязвимостей» на самом деле относится только к категории XSS. Общая картина не «всё в три раза хуже». Но в отдельных типах уязвимостей есть явная системная тенденция, и это именно те типы, которые обходятся дороже всего в продакшене.
Чек-лист из 8 пунктов перед запуском
Этот список состоит из того, на что мы смотрим в первую очередь, когда берём проект, быстро собранный с помощью ИИ. Всё это можно проверить за аудит длиной в несколько дней.
1. Не утекли ли секреты в код или на клиент? Самая частая проблема связана с API-ключами, строками подключения к базе и учётными данными сервисных аккаунтов. Особенно ключи во фронтенд-коде: их может прочитать любой в браузере. Проверьте и историю git: удалённый ключ продолжает жить в истории коммитов.
2. Проверяется ли авторизация на сервере при каждом запросе? Аутентификация (кто ты) и авторизация (к чему у тебя есть доступ) не одно и то же. Скрыть кнопку в интерфейсе не значит авторизовать. На каждом API-эндпоинте проверяйте на сервере, что запрошенная запись принадлежит этому пользователю. Уязвимости IDOR возникают именно из-за этого пробела.
3. Открыты ли правила доступа к базе данных? В проектах на Supabase и Firebase клиент общается с базой напрямую. Тогда единственной линией защиты становятся правила безопасности на уровне строк (RLS в Supabase). Таблица без правил открыта любому, у кого есть анонимный ключ.
4. Валидируется и экранируется ли пользовательский ввод? Считайте недоверенными любые данные из форм, URL или API. Валидируйте схемы на сервере, избегайте рендеринга сырого HTML, используйте параметры в запросах к базе.
5. Реальны ли зависимости и актуальны ли они? Модели иногда предлагают несуществующие имена пакетов. Злоумышленники могут зарегистрировать эти имена и поместить внутрь вредоносный код; такую атаку называют «slopsquatting». Убедитесь, что каждая новая зависимость действительно является нужным пакетом, и запускайте автоматическое сканирование известных уязвимостей.
6. Есть ли ограничение частоты запросов и защита от злоупотреблений? Вход, регистрация, сброс пароля и особенно эндпоинты, вызывающие языковую модель, не должны быть открыты без rate limit. Иначе за одну ночь можно получить и попытки захвата аккаунтов, и неожиданный счёт за API.
7. Не говорят ли сообщения об ошибках и логи слишком много? В продакшене пользователю не должны возвращаться stack trace, ошибки SQL или внутренние пути к файлам. В логах не должно быть паролей, токенов и персональных данных.
8. Разделены ли среды разработки и продакшена? Отдельная база, отдельные ключи, резервные копии и план отката. Частый сценарий в vibe code проектах: база, использованная при разработке, переносится в продакшен как есть.
Одного чек-листа недостаточно
Эти пункты ловят самые частые проблемы, но не заменяют аудит безопасности. Больший риск в коде, который никто по-настоящему не понимает. Когда находится уязвимость, тот, кто её исправляет, должен понимать, как работает система. Подробно мы разбирали это в статье о долге знаний.
И ещё: писать код с ИИ не проблема. Большинство команд уже пользуются этими инструментами, и выигрыш в скорости реален. Проблема в том, что скорость производства обгоняет скорость проверки. Решение не в замедлении, а в том, чтобы сделать проверку частью процесса: добавить статический анализ и сканирование зависимостей в CI и сделать код-ревью обязательным для критичных эндпоинтов.
Итог. Vibe coding остаётся самым быстрым способом получить прототип за дни. Но прежде чем он станет продуктом с реальными данными пользователей, работающий код нужно превратить в безопасный. Восемь пунктов выше служат отправной точкой.
Аудит, укрепление безопасности и запуск проектов, созданных с ИИ, мы выполняем в рамках услуги Vibe Code to Production. О настройке автоматического сканирования и конвейеров развёртывания читайте на странице DevOps и CI/CD.
О том, как дать таким системам безопасный доступ в продакшене, мы рассказываем в статье ИИ-агенты в продакшене, а о выводе быстро написанного MVP в продакшен с этим чек-листом рассказывает руководстве по разработке MVP.
Часто задаваемые вопросы
Безопасен ли код, написанный ИИ? Не по умолчанию. В отчёте Veracode 2025 года 45% сгенерированных образцов кода содержали уязвимость из OWASP Top 10, а в задачах на XSS доля неудач достигла 86%. Модель выполняет запрошенное поведение, но не проверяет, можно ли им злоупотребить, пока вы сами об этом не спросите.
Правда ли, что в коде ИИ в 2,74 раза больше уязвимостей? Нет, эта цифра из отчёта CodeRabbit относится только к категории XSS. В целом PR с участием ИИ содержали в среднем 10,83 проблемы против 6,45 у человеческих, а IDOR и неправильная обработка паролей встречались примерно в 1,9 раза чаще.
Что такое slopsquatting? Модели иногда предлагают несуществующие имена пакетов. Злоумышленники регистрируют эти имена и помещают внутрь вредоносный код, поэтому каждую новую зависимость нужно проверять и запускать автоматическое сканирование известных уязвимостей.
Достаточно ли чек-листа вместо аудита безопасности? Нет. Чек-лист ловит самые частые проблемы, но больший риск несёт код, который никто по-настоящему не понимает. Решение в том, чтобы встроить проверку в процесс: статический анализ и сканирование зависимостей в CI и обязательное код-ревью критичных эндпоинтов.
Похожие услуги
