Как проверить безопасность вайб-кода: security review

Герман Коваленко · основатель ENGRAM · Обновлено 21 июля 2026 · Об авторе →

Коротко: Слабое место вайб-кодинга не код, а привычки: проекты выходят в интернет с ключами в коде и формами, которые принимают что угодно. Лечится одной привычкой: фраза «сделай security review» после каждого куска кода и полный промпт-аудит перед деплоем. Агент найдёт и починит большинство дыр сам.

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

Привычка 1. Security review после каждой фичи

Закончили кусок кода - скажите: «сделай security review». Агент пройдёт по свежим изменениям и проверит типовой чек-лист:

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

Одна фраза, секунды времени. Цена пропуска - утёкший ключ или дыра на живом сайте.

Привычка 2. Полный аудит перед деплоем

Перед выкладкой в интернет - глубокий проход:

Проведи полный аудит безопасности проекта перед публикацией. Действуй как
въедливый аудитор, который ищет, ЧТО пойдёт не так.
1. Секреты: проверь код, историю git, логи - нигде не светятся ключи и пароли.
2. Формы и API: что случится при пустых, гигантских, вредоносных данных?
3. Доступы: какие адреса и порты открыты наружу, всё ли из этого нужно?
4. База: доступ только у приложения? Персональные данные - только нужные?
5. Всё критичное почини сразу. Итог - отчёт: что нашёл, что исправил,
   что осталось на моё решение.

Найденное агент чинит сам; ваша точка контроля - отчёт. Непонятен пункт - спросите «объясни простыми словами, чем это грозит».

Привычка 3. Три линии защиты

Security review - последняя линия. Перед ней ещё две:

1. Секреты в .env и запреты агенту - не читать секреты, не отправлять их наружу, не удалять массово. Настраивается один раз в правилах проекта.
2. Аудит чужого кода - скиллы и MCP только после проверки исходников.
3. Security review - после каждой фичи и перед каждым деплоем.

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

Частые вопросы

Как часто делать security review?

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

Агент находит все уязвимости?

Нет, и никто не находит. Он закрывает типовые дыры - а именно через них ломают большинство маленьких проектов. Для чувствительных данных добавляйте внешний аудит.

Что делать с найденным?

Критичное агент чинит сразу, спорное выносит в отчёт. Правило одно: не откладывать. Дыра, отложенная «на потом», доживает до продакшена.

Чем security review отличается от code review?

Code review - про качество кода: ошибки, лишнее, читаемость. Security review - про уязвимости. Проверки разные, нужны обе: «найди ошибки» и «сделай security review» - две разные команды.

Что дальше

• Урок курса «Безопасность: три правила» - настройка запретов с готовым промптом.
• Аудит чужого кода - как безопасно установить скилл.
• Как устроена безопасность агента - официальная документация Claude Code.
• Перед публикацией - тест сайта агентом и деплой.