Vibe-Code to Production

Сегодня приложение собирается за несколько часов из пары предложений: функция заказывается в Cursor, интерфейс проектируется в Lovable, бэкенд поднимается в Replit, а Codex или Claude Code подключают интеграцию. Экраны работают, форма сохраняет данные, вход в систему настроен. Но модель, написавшая этот код, оптимизировала завершение запроса, а не устойчивость в проде. В отчёте Veracode за 2025 год, где протестировали больше сотни моделей, 45 процентов сгенерированного кода содержало уязвимость из списка OWASP Top 10, и размер модели на эту долю не влиял. В независимом аудите vibe-код приложений безопасными оказались лишь 10,5 процента. Проблема не сводится только к безопасности: интеграции вроде платежей или авторизации остаются недоделанными, приложение ни разу не проверялось под настоящей пользовательской нагрузкой, а вызовы ИИ уходят без лимита расходов или ограничения частоты. Эта услуга существует именно для такой точки: команда довела продукт до определённого состояния с помощью этих инструментов и теперь не понимает, чего не хватает перед запуском.

Три ситуации, три разные точки входа

К нам приходят в одном из трёх состояний. Первое: уже случившаяся утечка, когда данные пользователя, ключ API или чужая запись оказались видны по ошибке, и это заметили либо вы сами, либо сторонний исследователь безопасности. Второе: проверка перед запуском, когда продукт считается готовым, но никто ещё не смотрел на безопасность и устойчивость системно, и нужен профессиональный взгляд до выхода в прод. Третье: остановка роста, когда код превратился в кучу, к которой все боятся прикасаться, любая быстро выпущенная функция рискует что-то сломать, и никто в команде не знает, с чего вообще начать. Первый шаг во всех трёх случаях одинаков: внимательно прочитать существующий код и отделить то, что работает по-настоящему, от того, что работает лишь по счастливой случайности.

Три этапа: найти, исправить, поставить шлюз

Большинство аудитов vibe-кода поставляют одну вещь: отчёт со списком находок, отсортированным по важности. Список находок не меняет вашу кодовую базу, он лишь показывает, где вы стоите. Наша работа устроена в три этапа: первый этап аудит, охватывающий не только уязвимости безопасности, но и недоделанные интеграции, точки, никогда не проверенные под нагрузкой, и риск затрат от неограниченных вызовов ИИ; второй этап исправление; а третий этап постоянный шлюз безопасности, встроенный в ваш конвейер CI/CD, то есть в систему, которая автоматически собирает и готовит код к выпуску при каждом обновлении. Без третьего этапа первые два временны, потому что следующий коммит, сделанный с помощью ИИ, воспроизведёт тот же класс ошибки. После установки шлюза каждое новое изменение, отправленное вами или вашим ИИ-инструментом, сканируется автоматически и блокируется до слияния.

Куда мы смотрим во время аудита

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

Контроль доступа и права видимости

Самый дорогой класс ошибок это контроль доступа, потому что он остаётся незаметным дольше всех остальных. В приложении Tea ошибочная логика авторизации, сгенерированная моделью, открыла личные сообщения пользователей другим пользователям. Каждый проект, созданный на Lovable до ноября 2025 года, был открыт 48 дней подряд: бесплатный аккаунт мог получить доступ к исходному коду, учётным данным базы данных и клиентским данным другого пользователя. В обоих случаях код работал исправно, экраны выглядели правильно, а проблема лежала там, куда тесты не заглядывают: может ли пользователь подменить собственный идентификатор и получить доступ к чужой записи. Во время аудита мы вручную проверяем каждую точку входа на то, кто какую запись может увидеть, потому что автоматический сканер этого в одиночку не ловит.

Утечки секретов и учётных данных

Коммиты, сделанные с помощью ИИ, раскрывают секреты вдвое чаще, чем код, написанный человеком: ключ API, пароль базы данных, токен стороннего сервиса оказываются прямо в коде или в файле окружения Replit. Модель делает это не со злым умыслом, она выбирает кратчайший путь к работающему примеру, а кратчайший путь обычно означает записать секрет открытым текстом. Аудит сканирует всю кодовую базу, включая прошлые коммиты, потому что если секрет уже попал в историю, удалить его из файла окружения недостаточно: сам ключ нужно перевыпустить.

Зависимости и галлюцинированные пакеты

Когда модели просят написать код, в среднем пятая часть предложенных пакетов на самом деле не существует, и эти названия не случайны: при повторном запуске того же запроса высокая доля тех же несуществующих имён повторяется снова. Эта предсказуемость породила новый класс атак под названием slopsquatting. Злоумышленник регистрирует реальный пакет под галлюцинированным именем и вкладывает туда вредоносный код, а разработчик устанавливает его без проверки именно потому, что это имя предложила модель. Во время аудита мы проверяем, существует ли на самом деле каждый пакет из списка зависимостей и выглядят ли разумно его число загрузок и история поддержки.

Валидация ввода и ошибки класса инъекций

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

Исправление и постоянная защита

Поиск проблем никогда не продаётся отдельно от их исправления, они идут вместе, потому что список находок сам по себе никого не защищает. Исправление тоже не сводится к безопасности: доделать недостроенную платёжную интеграцию, завершить поток авторизации или добавить лимиты расходов и частоты для вызовов ИИ входит в тот же пакет работ.

Исправление: код для слияния, а не отчёт

Мы не останавливаемся на списке находок. Каждая находка получает собственный pull request, то есть самостоятельный пакет изменений, который вы можете просмотреть и одобрить: изменённые файлы, обоснование и тест, доказывающий, что уязвимость существовала до исправления. Приоритет строится по серьёзности и близости к пользовательским данным: ошибка доступа, раскрывающая личные данные в проде, закрывается раньше, чем проблема конфигурации без измеримого эффекта. Мы работаем как новый инженер, читающий вашу кодовую базу, а не навязываем собственные предпочтения: делаем минимальное изменение, вписывающееся в уже существующую архитектуру.

Шлюз безопасности, встроенный в CI/CD

Исправление не постоянно, потому что ваш ИИ-инструмент может воспроизвести ту же ошибку завтра. Поэтому последний и самый важный шаг состоит в том, чтобы встроить статический анализ, сканирование зависимостей и поиск секретов прямо в ваш конвейер выкладки: каждый pull request сканируется автоматически, а критическая находка блокирует слияние. Шлюз работает одинаково независимо от того, кто отправил изменение: написали вы его сами или коммит сделал ИИ-агент, разницы нет. Этот шлюз добавляется в уже существующий конвейер CI/CD или строится вместе с нашей услугой DevOps и CI/CD, если конвейера пока нет. После установки шлюза тот же класс ошибок больше не доходит до продакшена вовсе, и ваша команда сможет поддерживать его сама, без нашего участия.

Как определяется объём работ

Объём работ фиксируется письменно уже на звонке по определению границ: какой репозиторий, какая среда, какие интеграции входят. То, каким инструментом ИИ написан код, не меняет объём аудита: всё проходит один и тот же процесс. Аудит сканирует известные классы ошибок, которые можно найти при текущем уровне знаний, и каждый просканированный класс закрывается либо исправлением, либо письменной заметкой об осознанно принятом риске. Архитектурное решение, например, полное перепроектирование модели данных, естественным образом выходит за границы этого аудита; если такая потребность возникает, работа уходит в масштабирование бэкенда или CTO as a Service. Поскольку эта ясность закладывается с самого начала, обеим сторонам понятно, что именно они получают, уже с первого дня разговора.

Результаты первого сканирования

При первом сканировании vibe-код приложения почти всегда всплывают одни и те же три вещи, независимо от того, каким инструментом написан код: административный экран, доступный без аутентификации, минимум один ключ API, зашитый прямо в код, и минимум один пользовательский ввод без настоящей валидации. Независимое сканирование более пяти тысяч публично развёрнутых vibe-код приложений в мае 2026 года показало, что около 40 процентов из них раскрывали чувствительные данные вроде медицинских или финансовых записей, а больше двух тысяч корпоративных приложений вообще не имели контроля доступа. К себе мы применяем ту же дисциплину: любой код, который мы выпускаем, включая этот сайт, проходит через слой санитизации, не пропускающий ничего сверх разрешённого списка тегов, и через автоматическую проверку перед коммитом. Мы не рекомендуем метод, который сами не применяем к собственной работе.

Процесс: от первого контакта до сданного кода

Процесс состоит из четырёх шагов. Начинается всё с короткого разговора об объёме предстоящих работ: какой репозиторий, какие окружения и какие интеграции затронуты. Дальше идёт сам аудит, обычно занимающий от трёх до пяти рабочих дней и завершающийся письменным списком находок, отсортированным по серьёзности; этот список можно при желании забрать и отдельной самостоятельной работой. На третьем шаге начинается исправление, чья длительность зависит от того, сколько находок вошло в согласованный объём, причём каждое исправление приходит отдельным pull request. Последний шаг состоит в установке шлюза CI/CD и пробном прогоне вместе с вашей командой. Завершается всё документом передачи, где написано, что именно ищет каждая проверка, что делать, когда она срабатывает, и как ваша команда будет обновлять шлюз дальше самостоятельно.