Разработчик случайно закоммитил ключ доступа к платёжному провайдеру и через час удалил его следующим коммитом. Что нужно сделать?
- Что делать, если секрет попал в git?
- Где хранить секреты приложения?
Секрет в истории git — утёк. Единственное надёжное действие — отозвать и перевыпустить (ротация), затем проверить журналы использования ключа.
- Удаляющий коммит не убирает секрет из истории; клоны, форки, кэши и CI уже могли его получить
- Переписывание истории — уборка, но не замена ротации
- Профилактика: секреты в менеджере (Vault, облачный KMS), сканер секретов в pre-commit и CI
А ещё Публичные репозитории сканируют боты — ключи облаков используют за минуты
Подробно
Почему удаление не помогает. Git хранит все версии: объект с ключом доступен по старому коммиту. Репозиторий уже клонирован коллегами и CI, мог попасть в зеркала, кэш хостинга, в логи сборки. В публичных репозиториях ключи облачных провайдеров находят автоматические сканеры за минуты.
Порядок действий:
- отозвать ключ у провайдера и выпустить новый;
- обновить секрет во всех окружениях;
- проверить журнал использования старого ключа: были ли операции не от нас;
- по желанию — вычистить историю (
git filter-repo) и попросить хостинг очистить кэш; это не отменяет первых шагов; - разобрать причину и закрыть её.
Профилактика:
- секреты не хранятся в репозитории — только в менеджере секретов (Vault, Yandex Lockbox, AWS Secrets Manager) с контролем доступа, аудитом и ротацией;
- в приложение — через переменные окружения или примонтированные файлы, в Kubernetes — внешние секреты, а не значения в манифестах;
- сканеры секретов: pre-commit (gitleaks), проверка в CI и на хостинге (push protection);
- короткоживущие учётные данные (OIDC для CI, временные токены) вместо вечных ключей.
Что хотят услышать
- Секрет считается скомпрометированным, ротация обязательна.
- Почему удаление коммита не помогает.
- Порядок реагирования, включая проверку использования.
- Профилактика: менеджер секретов, сканеры.
Частые ошибки
- Ограничиться переписыванием истории.
- Хранить секреты в зашифрованном файле в репозитории с ключом рядом.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Ничего: удаляющий коммит убрал ключ из репозитория
- ✓Считать ключ скомпрометированным и ротировать: он остался в истории git
- ✗Достаточно сделать репозиторий приватным
- ✗Переписать историю через force-push — ротация не нужна
Что спросят дальше
- Как организовать регулярную ротацию секретов?
- Чем это относится к категории Security Misconfiguration?
Разбор темы
- Безопасность приложения: OWASP, доступ и секреты
OWASP Top 10 в редакции 2025, разница аутентификации и авторизации, ловушки JWT против сессий, хранение паролей и секретов, безопасность цепочки поставок.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.