Разбор Vibe Code: почему ваше приложение проходит демо, но проваливает проверки безопасности

Вступление

Я занимаюсь разработкой и безопасностью приложений уже больше десяти лет. За последние полтора года я наблюдаю настоящий бум: стартапы, а иногда и крупные компании, с головой ныряют в так называемый vibe coding. Это когда разработчик формулирует задачу на естественном языке, а AI-агент (Cursor, Copilot, Replit Agent) генерирует целые блоки кода, маршруты, модели данных. И это реально быстро. Я сам так делаю прототипы — вместо двух недель уходит два дня. Демо выглядит сногсшибательно: функционал есть, интерфейс летает, заказчик в восторге. Но когда на первый спринт приходит команда безопасности или внешний пентест — начинается ад. Тот самый vibe code teardown: приложение, которое блестяще прошло демо, разваливается на проверках. В этой статье я разберу на реальных примерах, почему так происходит, и что с этим делать.

Что такое vibe code?

Термин популяризировал Andrej Karpathy в начале 2025 года. Суть: разработчик перестаёт писать код руками, а просто «вибрирует» с AI — описывает желаемое поведение, AI генерирует код, разработчик принимает или просит исправить. Это не про автодополнение, а про полноценную генерацию модулей. На 2026 год все основные IDE встроили такую функциональность. Моя команда использует Cursor в режиме Composer и Claude для генерации эндпоинтов. Удобно, но есть подводные камни.

Кейс 1: Демо с SQL-инъекциями

Пару месяцев назад ко мне пришёл стартап, который делал маркетплейс для нишевых товаров. Они на vibe code за три недели слепили MVP. На демо всё работало: поиск по категориям, корзина, оформление заказа. Но когда мы запустили статический анализатор (Semgrep) и динамическое сканирование, нашли 18 критических уязвимостей. Самая вопиющая — SQL-инъекция в поле поиска. AI сгенерировал запрос примерно так:

query = f"SELECT * FROM products WHERE name LIKE '%{user_input}%'"

Разработчик, который не писал SQL-запросов вручную последние пять лет, просто скопировал это из чата. Он не задумался об экранировании или параметризации. А на пентесте мы через ' OR 1=1 -- выгрузили всю базу пользователей с хэшами паролей. Демо прошло отлично — никто не проверял ввод на спецсимволы.

Кейс 2: Хардкоженные ключи в репозитории

Другой пример — финтех-прототип для анализа транзакций. AI сгенерировал скрипт, который подключался к Stripe API. И прямо в коде, в комментарии, лежал real API key (замаскированный, но рабочий). В документации Stripe сказано: никогда не хранить ключи в коде. Но AI не знает, что этот код будет залит в публичный репозиторий. Разработчик забыл вытащить ключ в переменные окружения. Мы нашли это автоматическим сканером секретов (git-secrets). В итоге стартап потратил два дня на ротацию ключей и аудит логов. Хорошо, что не было утечки данных клиентов.

Почему AI-код часто небезопасен?

Давайте разберём системные причины. Я вижу три основных фактора:

1. Отсутствие контекста безопасности. AI обучен на огромном количестве кода из интернета, включая старые блоги, примеры из Stack Overflow и незащищённые проекты. Он не знает вашу инфраструктуру, политики безопасности, требования к шифрованию. Он просто выдает наиболее вероятное продолжение.

2. Непонимание бизнес-логики. AI может сгенерировать эндпоинт, который возвращает is_admin = true просто потому, что в обучающей выборке был такой паттерн. Он не понимает, что это критический атрибут, который нельзя доверять клиенту.

3. Игнорирование принципов минимальных привилегий. AI часто генерирует код с правами root в базе данных, открытыми CORS-политиками или доступом к файловой системе. Потому что в примерах так проще.

Согласно рекомендациям OWASP (OWASP Top 10-2025), инъекции, неправильная аутентификация и проблемы конфиденциальности данных остаются главными угрозами. В коде, сгенерированном AI, эти уязвимости встречаются в 1,5–2 раза чаще, чем в ручном коде той же сложности (данные исследования Snyk за 2026 год, «AI-Assisted Code Security Report»).

Сравнение типичных уязвимостей

Как защититься? Практические шаги

Я не призываю отказываться от vibe coding — это суперсила. Но нужно внедрить грамотные практики безопасности. Вот что реально работает в моих проектах:

1. Обязательное code review для любого AI-сгенерированного кода. Пусть даже самое быстрое ревью: выделите 15 минут, посмотрите на обработку ввода, аутентификацию и хранение секретов.

2. Статический анализ (SAST) в CI/CD. Инструменты вроде SonarQube, Semgrep или Checkmarx автоматически найдут SQL-инъекции, XSS, hardcoded credentials. Мы встроили Semgrep в pre-commit hook — теперь код с уязвимостями не попадает в репозиторий.

3. Сканирование секретов. Используйте git-secrets, truffleHog или встроенные сканеры платформ. Например, GitHub предоставляет секрет-сканирование для всех публичных репозиториев и для частных — в GitHub Advanced Security. ASI Biont поддерживает подключение к GitHub через API — подробнее на asibiont.com/courses.

4. Динамическое тестирование (DAST). Периодически запускайте OWASP ZAP или Burp Suite против вашего приложения. Это ловит уязвимости, которые не видны в статике.

5. Обучение команды. Разработчики, которые используют AI, должны понимать основы безопасного кодирования. Я провожу внутренние воркшопы по OWASP Top 10 — это снизило количество критических багов в два раза.

Заключение

Vibe coding — это мощный инструмент, который делает разработку демократичной. Но он не отменяет ответственность за безопасность. Приложение, которое отлично выглядит на демо, может рухнуть под первым реальным пентестом. Мой совет: относитесь к AI-коду как к коду джуниора — проверяйте, тестируйте, автоматизируйте защиту. Тогда скорость не будет в ущерб качеству. И помните: безопасность — это не функция, которую можно добавить потом. Она должна быть зашита в процесс, включая момент генерации кода.