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

Короткий ответ

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

Как это работает подробнее

удаление файла новым коммитом не удаляет секрет из истории Git — он остаётся доступен через старые коммиты, форки, локальные клоны у разработчиков и кэши CI. Поэтому единственная гарантированная защита — сделать утёкший пароль бесполезным, сменив его в системе, где он применяется.

Пример кода

security-example-454.shКопировать

# 1. Немедленная ротация на стороне БД (до любых действий с git)
ALTER USER app_user WITH PASSWORD 'новый_надёжный_пароль';
# 2. Поиск, в каких коммитах встречается старый секрет
git log --all -p | grep -n "SuperSecret123"
# 3. Очистка истории (после ротации!)
git filter-repo --invert-paths --path config/.env

Что использовать на практике

• Практика. порядок действий — 1) сменить пароль/ключ в БД или сервисе; 2) обновить secret-хранилище и перезапустить сервисы, использующие его; 3) проверить логи доступа к БД за период утечки на подозрительную активность; 4) очистить историю репозитория (git filter-repo/BFG) и уведомить всех с локальными клонами о необходимости их пересоздать; 5) добавить pre-commit/CI-сканирование секретов (gitleaks, trufflehog), чтобы предотвратить повтор.
• Проверка. Ожидаемое поведение: после смены пароля в БД старое значение из истории Git становится бесполезным для подключения — проверяется попыткой подключиться старыми учётными данными и получением отказа аутентификации; очистка истории выполняется уже как дополнительная мера гигиены, а не как основная защита.

Подводные камни

• Ошибка. начинать с попытки «тихо» удалить коммит из истории, не меняя пароль — секрет уже может быть скопирован кем-то до очистки; считать инцидент закрытым сразу после ротации без проверки логов доступа за весь период утечки; не оповестить команду о необходимости обновить локальные клоны после перезаписи истории.