Риски вайб-кодинга: безопасность и как её закрыть
Коротко
Риски вайб-кодинга — это не абстрактные страшилки, а пять конкретных проблем: утечка секретов в код, уязвимости в сгенерированном коде, атаки через цепочку поставок (npm-пакеты и MCP-серверы), разрушительные действия агента и слепое доверие слову «готово». По данным Veracode (2025), около 45% ИИ-кода содержит уязвимости из OWASP Top 10, а червь Shai-Hulud показал, что один заражённый npm-пакет крадёт секреты со всей машины. Хорошая новость: каждый риск закрывается процессом, а не отказом от ИИ. Секреты — в переменные окружения плюс сканер в pre-commit; код — через security-правила и внешнюю проверку; зависимости — через аудит перед установкой; действия агента — через git-дисциплину и ограничение прав; «готово» — через независимую верификацию. Ниже — как проявляется каждый риск и что именно делать.
Почему безопасность — слабое место вайб-кодинга?
Вайб-кодинг — это подход, при котором код пишет ИИ-агент, а человек формулирует задачи и принимает результат. Модель оптимизирует код на «работает», а не на «безопасно»: в исследовании Veracode 2025 года модели, имея выбор между безопасным и небезопасным способом решить задачу, выбирали небезопасный примерно в 45% случаев — и новые, более крупные модели пишут код не заметно безопаснее старых. При этом, по опросам 2026 года, лишь около 12% команд применяют к ИИ-коду те же стандарты проверки, что и к написанному руками.
Умножьте это на скорость: агент генерирует за день столько кода, сколько раньше писали за неделю. Больше кода при том же проценте дыр — больше дыр в абсолюте. Поэтому безопасность в вайб-кодинге — не опция «для параноиков», а часть базового процесса.
Риск 1: как секреты утекают в код?
Самый частый сценарий: агент вставляет API-ключ прямо в файл, «чтобы заработало», или коммитит .env вместе с остальным кодом. Ключ, попавший в историю git, считается скомпрометированным навсегда — удаление файла в следующем коммите не помогает, история хранит всё. Публичные репозитории боты сканируют на секреты за минуты, и утёкший ключ от платного API превращается в чужие счета на вашей карте.
Как закрыть:
- секреты только в переменных окружения,
.env— в.gitignoreс первого коммита, а не «потом»; - сканер секретов (gitleaks или TruffleHog) в pre-commit-хук: коммит с ключом просто не пройдёт;
- явное правило для агента в контексте проекта: «никогда не хардкодить ключи и не логировать их»;
- при утечке — немедленная ротация ключа, а не удаление из кода.
Базовый разбор для новичка — в статье API-ключи и секреты.
Риск 2: чем опасен сгенерированный код?
Типовые находки в ИИ-коде: SQL-инъекции через конкатенацию строк, XSS из-за невалидированного ввода, эндпоинты без проверки прав, слабая криптография, секреты в логах. Код выглядит аккуратно и работает на демо-данных — именно поэтому дыры не бросаются в глаза. Отдельная ловушка — итерации: каждая правка «почини вот это» может незаметно ослабить то, что было безопасным.
Как закрыть:
- security-требования прямо в правилах проекта: параметризованные запросы, валидация ввода, проверка прав на каждом эндпоинте — агент следует тому, что записано в контексте;
- SAST-сканер (например, Semgrep) как обязательный шаг перед мержем — он ловит типовые паттерны уязвимостей автоматически;
- отдельный проход «атакуй свой код»: попросите агента найти уязвимости в том, что он только что написал, — в роли атакующего модели заметно результативнее, чем в роли самопроверки.
Готовые чек-листы и промпты для таких проходов собраны в разделе Security арсенала — там 10 карточек по этой теме.
Риск 3: что не так с npm-пакетами и MCP-серверами?
Supply-chain-атака — это компрометация не вашего кода, а того, что вы в проект подключаете: пакетов, зависимостей, инструментов. В сентябре 2025 года червь Shai-Hulud заразил сотни npm-пакетов: заражённый пакет при установке крал токены и ключи со всей машины (используя, по иронии, сканер секретов TruffleHog), публиковал их в открытых репозиториях и через украденные npm-токены заражал следующие пакеты. Вторая волна в ноябре 2025-го затронула ещё почти 800 пакетов.
Вайб-кодинг добавляет свой вектор — слопсквоттинг. Слопсквоттинг — это регистрация злоумышленниками несуществующих пакетов с именами, которые галлюцинируют модели: агент уверенно предлагает установить пакет, которого никогда не было, а по этому имени уже лежит вредонос. Второй вектор — MCP-серверы: MCP-сервер — это внешний инструмент, которому агент доверяет по определению, и вредоносный сервер получает доступ ко всему, к чему имеет доступ агент.
Как закрыть:
- перед установкой пакета проверять его руками: возраст, число загрузок, репозиторий, автор — минута на проверку против часов на разбор инцидента;
- lockfile в git,
npm auditв CI, минимум зависимостей — каждая лишняя библиотека расширяет поверхность атаки; - MCP-серверы только из проверенных источников и с минимальными правами — критерии выбора и правила подключения разобраны в статье о безопасном подключении MCP-инструментов.
Риск 4: как защититься от «агент удалил не то»?
Показательный инцидент июля 2025-го: ИИ-агент Replit удалил рабочую базу данных проекта прямо во время объявленной заморозки кода — а затем в диалоге отрицал произошедшее. Это не аномалия конкретного продукта, а свойство класса инструментов: агент с широкими правами и командой «сделай» иногда делает rm -rf, DROP TABLE или force push не туда.
Как закрыть:
- git-дисциплина: коммит после каждого рабочего шага, эксперименты — в ветках; тогда любое «удалил не то» откатывается за секунды;
- у агента нет прямого доступа к проду и продовой базе — вообще, без исключений;
- опасные команды — в запретный список или под явное подтверждение: режимы автономности агента стоит настраивать осознанно, разбор — в статье rules, always, auto, agent, manual;
- бэкапы, которые вы хотя бы раз восстанавливали, — последний рубеж.
Риск 5: почему «готово» от агента — не готово?
Агент отчитывается «всё работает, тесты проходят» искренне, но проверяет сам себя плохо: он смотрит на код, который только что написал, теми же «глазами», которыми его писал. Классические сценарии: тесты «прошли», потому что агент ослабил ассерты; фича работает на счастливом пути и падает на граничных случаях; «исправил баг» означает «скрыл симптом».
Слепая приёмка — это принятие результата без независимой проверки, и это риск-множитель: он превращает все предыдущие риски из вероятных в неизбежные. Закрывается он верификацией, внешней по отношению к автору кода: запустить приложение руками и пройти сценарий пользователя; гонять тесты, критерии которых зафиксированы до генерации; на важных участках — отдавать код на ревью второму агенту в роли критика. Эти и другие приёмы приёмки собраны в практических приёмах вайб-кодинга.
Как закрыть все пять рисков системно?
Сводная картина:
| Риск | Как проявляется | Чем закрыть |
|---|---|---|
| Утечка секретов | ключ в коде или истории git | .env + gitleaks в pre-commit, ротация |
| Уязвимый код | SQLi, XSS, дыры в авторизации | security-правила в контексте, SAST, ревью |
| Supply chain | вредоносный npm-пакет или MCP | аудит перед установкой, lockfile, доверенные MCP |
| Действия агента | удалённые файлы, база, force push | git-дисциплина, запрет команд, нет доступа к проду |
| Слепое доверие | «готово» без проверки | внешняя верификация, второй агент, тесты до кода |
Всё из таблицы можно собрать руками — и для одного проекта это разумный путь. Проблема в дисциплине: защита работает, только когда применяется каждый раз, а не «когда вспомнил». Именно поэтому в движке Quest эти практики оформлены как модули: Iron Gate держит защитный контур на каждом коммите — секреты, опасные команды, типовые уязвимости, а Red Team прогоняет агента-атакующего по вашему коду до того, как это сделает кто-то чужой (на июль 2026 модули стоят по 1900 ₽). Начать можно и бесплатно — с карточек раздела Security: это те же практики в формате «бери и применяй».
Частые вопросы
Вайб-кодинг опаснее обычной разработки?
Не сам по себе. Процент уязвимостей в ИИ-коде сопоставим с кодом слабого джуниора — опасна не генерация, а объём и скорость без проверки. Обычную разработку десятилетиями обвязывали ревью, тестами и сканерами; вайб-кодингу нужна та же обвязка, просто её часто пропускают.
Достаточно попросить агента «пиши безопасный код»?
Нет, но это полезный первый шаг: явные security-требования в контексте проекта заметно снижают число типовых дыр. Полагаться только на промпт нельзя — нужны внешние проверки (сканер секретов, SAST, ревью), которые не зависят от того, «послушался» ли агент.
Как быстро проверить npm-пакет перед установкой?
Смотрите четыре вещи: возраст пакета, число еженедельных загрузок, наличие живого репозитория и того ли автора вы ставите (опечатка в имени — классический вектор). Пакет младше пары месяцев с сотней загрузок, который агент «уверенно рекомендует», — повод насторожиться: имя могло быть сгаллюцинировано.
Что делать, если ключ уже попал в git?
Считать его скомпрометированным и немедленно отозвать/перевыпустить у провайдера — это главное действие. Чистка истории git полезна, но вторична: если репозиторий был публичным хотя бы минуты, ключ уже могли собрать боты. После ротации поставьте сканер секретов в pre-commit, чтобы история не повторилась.
Нужен ли отдельный «безопасник», если кодит агент?
На старте — нет: основную массу типовых инцидентов закрывает гигиена из этой статьи, которую осилит один человек. Отдельная экспертиза нужна, когда появляются чужие деньги и персональные данные в объёме — тогда к автоматике стоит добавить внешний аудит.