vibefixbezopasnost· 2 мин чтения

Ключи API попали в репозиторий: что делать в первый час

Если ключи API попали в репозиторий на GitHub, в первый час нужно: отозвать и перевыпустить скомпрометированный ключ, убрать его из текущего кода и перенести в переменные окружения, и только потом разбираться с историей git. Ключ считается скомпрометированным с момента попадания в историю, даже если коммит сразу удалили.

Коротко

Что это и когда возникает

ИИ-инструменты часто генерируют код с ключом API прямо в файле — для быстрого теста это удобно, но если такой файл попадает в репозиторий на GitHub (особенно публичный), ключ становится доступен кому угодно, включая автоматических сканеров, которые ищут утечки секретов постоянно.

Что делать по шагам в первый час

Шаг Что делать
1. Отозвать ключ В панели сервиса, которому принадлежит ключ (например, Stripe, ЮKassa, Supabase), немедленно отозвать его
2. Перевыпустить новый ключ Создать новый ключ взамен отозванного
3. Убрать ключ из кода Удалить его из текущих файлов, заменить на чтение из переменной окружения
4. Добавить переменную в хостинг Прописать новый ключ в настройках окружения на хостинге, не в коде
5. Проверить логи Посмотреть, не было ли подозрительной активности с момента утечки до отзыва

Переписывание истории git (удаление коммита с ключом из истории) делается следующим шагом, уже не в режиме экстренного реагирования.

Сколько стоит и из чего складывается цена

Экстренная помощь в этой ситуации обычно укладывается в почасовую работу от 3 000 ₽/час — отзыв, перенос в переменные окружения и проверка логов занимают от одного до нескольких часов. Если нужен более широкий аудит безопасности после инцидента — это отдельная задача.

Сколько стоит содержать

После разового инцидента имеет смысл настроить проверку на секреты перед каждым коммитом (pre-commit hook) — это разовая настройка, а не постоянная статья расходов.

Что ломается в эксплуатации

Если отозвать ключ, но не обновить его во всех местах, где он используется (например, в нескольких окружениях — разработка, тест, продакшен), часть функциональности может перестать работать до тех пор, пока новый ключ не пропишут везде.

Когда это не нужно

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

Что спросить у подрядчика

  1. Как быстро можно отозвать и перевыпустить ключ для моего сервиса?
  2. Проверяли ли логи на подозрительную активность до отзыва?
  3. Куда переносится новый ключ — точно не обратно в код?
  4. Настраиваете ли защиту от повторения — проверку секретов перед коммитом?
  5. Нужно ли чистить историю git, и если да — когда это лучше сделать?

Как это сделано у меня

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

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

Если я сразу удалил коммит с ключом, он всё равно скомпрометирован?

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

Нужно ли переписывать историю git, чтобы убрать ключ оттуда?

Это полезно для порядка, но не отменяет необходимость отозвать ключ — переписанная история не защищает от того, что ключ уже кто-то увидел.

Как не допустить этого в будущем?

Хранить ключи только в переменных окружения, добавить .env в .gitignore с самого начала проекта и использовать инструмент проверки секретов перед коммитом.

Ещё по теме

Разработчик. Пишу о починке проектов на ИИ и ИИ-автоматизации на основе своей практики. Подробнее — как я работаю.

Написать в Telegram

Если Telegram не открывается: MAX · oongemakh@gmail.com

Обновлено: