Безопасность вайб-кодинга: как не слить ключи и секреты

Безопасность вайб-кодинга — это не про модные аудиты и не про пентесты с красной командой. Для соло-мейкера это в первую очередь про одну очень скучную вещь: не дать ключам и секретам утечь наружу. Ты описываешь идею словами, AI генерит код, всё летит быстро — и ровно на этой скорости в репозиторий попадает .env с боевым паролем к базе, а в публичный коммит — API-ключ платёжки.

Проблема не в том, что ты невнимательный. Проблема в том, что LLM охотно вставит ключ прямо в код, если ты не сказал иначе, а git с радостью закоммитит всё подряд. Ниже — где именно горит, чем это грозит и что настроить один раз, чтобы дальше об этом не думать. Без страшилок: почти всё лечится десятком строк конфига и парой привычек.

Почему у вайб-кодера рисков больше, чем у обычного разработчика

Дело не в том, что вайб-кодинг «опаснее». Дело в комбинации факторов, которых у команды с выделенным девопсом обычно нет.

• Скорость. Ты гонишь от идеи к работающему прототипу за вечер. На этой скорости легко проскочить момент, где надо было остановиться и подумать про доступы.
• AI как автор. Ассистент пишет большие куски кода за раз. Ты их не набирал руками построчно — значит, глазами по ним пробегаешь бегло. Секрет в середине пачки изменений теряется.
• Соло. Нет второго человека, который на ревью скажет «стоп, у тебя тут ключ в открытую». Ты сам себе и автор, и ревьюер, и девопс.
• Дефолты по умолчанию небезопасны. Многие инструменты из коробки открывают порт, бакет или эндпоинт «чтобы точно заработало». Заработало — и осталось открытым.

Хорошая новость: ровно потому, что рисков немного и они типовые, их можно закрыть системно. Не героизмом, а настройкой.

Риск → чем грозит → как закрыть

Держи это как чек-лист. Пять строк покрывают почти все утечки, которые случаются у инди-мейкеров.

Первые две строки — про то, что секрет попал туда, где его быть не должно. Средние две — про то, что доступ к данным никто не закрыл. Последняя — про то, что делать, когда что-то уже утекло. Лечатся они по-разному, поэтому разберём по группам.

Секреты живут вне кода. Точка

Единственное надёжное правило: секретов в коде нет вообще. Ни в исходниках, ни в конфигах, которые коммитятся. Всё чувствительное — в переменных окружения.

• Ключи, пароли, токены — только в .env (локально) и в переменных окружения на сервере.
• В репозиторий кладёшь .env.example — тот же файл, но со значениями-заглушками (DB_PASSWORD=changeme). Он показывает, какие переменные нужны, и не раскрывает ничего.
• В коде читаешь их через process.env.DB_PASSWORD — не хардкодишь значение.

Когда работаешь с AI, проговаривай это в промпте прямо: «секреты бери из переменных окружения, не вставляй значения в код». Ассистент послушается, но по умолчанию может и не подумать об этом. Ты — последний фильтр перед коммитом.

Три способа хранить секреты — что выбрать

Не все хранилища одинаковы. Для соло-проекта на старте достаточно .env, но полезно знать, куда расти.

Совет простой: начинай с .env и не усложняй. Менеджер секретов — это когда у тебя уже несколько окружений и людей, а не когда ты выкатываешь первую версию продукта. Не покупай себе проблему заранее.

.gitignore и ротация: два действия, которые спасают

Настрой .gitignore до первого коммита, а не после. Минимум, что там должно быть:

.env
.env.*
!.env.example
node_modules/
*.pem
*.key

Проверь себя один раз: git status перед коммитом. Если видишь в списке .env — стоп, он не в игноре. Секунда внимания экономит день паники.

А теперь неприятная правда про ротацию. Если секрет хоть раз попал в git — считай его скомпрометированным навсегда. Удалить файл следующим коммитом мало: он остаётся в истории, и любой, у кого есть доступ к репозиторию (или клон, сделанный до удаления), его достанет. Переписать историю (filter-repo, BFG) можно, но это не отменяет главного — секрет мог уже уйти. Единственный настоящий фикс — сменить сам ключ:

1. Зайди в панель сервиса (Stripe, БД, что угодно) и выпусти новый ключ.
2. Отзови старый.
3. Обнови значение в переменных окружения.
4. И только потом, если хочешь, чисти историю.

Ротация — это не наказание, а нормальная гигиена. Заведи привычку менять ключи, если есть хоть тень сомнения, что они где-то засветились: попали в лог, мелькнули в скриншоте, лежали в старом чате с ассистентом.

Минимальные права вместо «дать всё на всякий случай»

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

• Токену для чтения аналитики не нужны права на запись.
• Ключу фронтенда не место рядом с секретом, который списывает деньги (у платёжек есть отдельные publishable- и secret-ключи — не путай их).
• Бакет с загрузками пользователей закрывай по умолчанию, открывай точечно только то, что реально должно быть публичным.
• База данных не должна слушать внешний интернет без причины — только приложение, только по внутренней сети или сокету.
• Один сервис — один ключ. Если утечёт, ротируешь точечно, а не гасишь пол-инфраструктуры.

Это же касается делегирования: если задачу выполняет AI-воркер, у него тоже должны быть ровно те доступы, что нужны под задачу, и не шире. Как выстроить контроль над тем, что воркеры делают и с какими правами, разбирал в AI-воркеры: как делегировать.

Автопроверки перед выкаткой

Самое ценное — не полагаться на собственную внимательность, а поставить проверки, которые ловят проблему за тебя. Внимательность кончается к вечеру; конфиг не устаёт.

• Сканер секретов. Инструменты вроде gitleaks или git-secrets прогоняют код и историю на предмет ключей. Повесь их в pre-commit хук — коммит с секретом просто не пройдёт.
• Отдельный шаг в пайплайне. Перед деплоем гоняй сканер и линтер в CI. Красный чек — выкатка не едет.
• Ревью diff перед выкаткой. Даже соло — открой финальный дифф глазами. AI-воркер сгенерил пачку изменений? Пробеги их на предмет случайных ключей и открытых эндпоинтов, прежде чем нажимать «выкатить».
• Базовый security-линтер. Многие эко-системы имеют плагины, которые ругаются на очевидное — захардкоженные креды, небезопасные дефолты. Дёшево включить, дёшево держать.

Расставь их по времени срабатывания — чем раньше ловишь, тем дешевле фикс.

Ни один из слоёв не идеален по отдельности — вместе они ловят почти всё. Стоимость настройки — один вечер; окупается на первой же пойманной утечке.

Почему встроенный доступ к модели убирает часть риска

Отдельная головная боль вайб-кодинга — ключ к самой AI-модели. Чтобы кодить с Claude, обычно нужен API-ключ, и он ведёт себя как любой другой секрет: его хочется вставить в скрипт, засунуть в конфиг, прокинуть в переменную окружения на десяти машинах. Каждая копия — потенциальная утечка, а привязан он к твоей карте — то есть утёкший ключ бьёт напрямую по кошельку.

Когда доступ к модели встроен в платформу и работает без личных ключей и VPN, этого класса риска просто нет: нечему утекать, нечего ротировать, нечего случайно закоммитить. Как это устроено, разбирал в Claude внутри платформы. Это не отменяет гигиену для остальных секретов твоего проекта — но на один тип ключей, который чаще всего трогаешь руками, становится меньше.

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

Что делать, если уже слил

Паника — плохой советчик, а порядок действий — хороший. Если понял, что ключ засветился:

1. Сначала ротируй, потом разбирайся. Выпусти новый ключ, отзови старый. Пока старый жив, любые расследования — трата времени.
2. Проверь логи доступа сервиса. Многие панели показывают, откуда и когда ключом пользовались. Если видишь незнакомые обращения — считай, что им воспользовались.
3. Оцени радиус. Что этот ключ мог сделать? Если у него были минимальные права (см. выше) — выдохнул. Если полный доступ — проверяй данные и биллинг.
4. Почини причину, а не симптом. Утёк из-за отсутствия .gitignore? Настрой. Из-за хардкода? Повесь сканер. Один и тот же грабли дважды — уже не случайность.

Утечка — это не конец света и не повод стыдиться. Это повод один раз поставить проверку, которая не даст повториться.

Коротко

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

• Секреты — только в переменных окружения, никогда в коде.
• .gitignore настроен до первого коммита; git status — глазами перед каждым.
• Утёкший ключ = мёртвый ключ: ротируй без сожалений, потом разбирайся.
• Минимальные права токенам, закрытые по умолчанию бакеты и эндпоинты.
• Автосканер секретов в хуке и в CI ловит то, что ты пропустил.
• Меньше ключей на руках — меньше поверхность ошибки; встроенный доступ к модели убирает один целый класс риска.

Поставь это один раз — и дальше скорость вайб-кодинга перестанет играть против тебя.