Секреты в git: как найти ключи и пароли в репозитории

Если пароль, токен или закрытый ключ попал в коммит, он остаётся в истории, даже когда вы удалили файл следующим коммитом. Ниже: как найти такие секреты и в каком порядке их обезвреживать.
Шаг 1. Найдите секреты, в том числе в истории
Gitleaks проверяет всю историю репозитория:
gitleaks detect --source . -v
# в новых версиях: gitleaks git -v (история) и gitleaks dir . (файлы)
Команды отличаются между версиями gitleaks, сверьтесь с gitleaks --help. Альтернатива, которая умеет проверять найденные ключи на действительность:
trufflehog git file://. --only-verified
Результат ищите в первую очередь по типам: ключи облаков, токены Git-платформ, пароли БД, приватные SSH-ключи. Файлы .env и *.pem в репозитории — повод проверить всю историю.
Шаг 2. Сначала отзовите секрет
Порядок важен. Если репозиторий хоть раз был доступен другим людям или клонировался, секрет нужно считать скомпрометированным. Очистка истории не вернёт его.
- Выпустите новый пароль, токен или ключ.
- Подставьте новый в сервисы, которые его используют.
- Отзовите старый.
- Посмотрите журналы сервиса за период, пока секрет был в репозитории: не использовали ли его посторонние.
Шаг 3. Очистите историю (после отзыва)
Очистка нужна, чтобы секрет не нашли сканеры и не использовали по ошибке. Используйте git filter-repo:
pip install git-filter-repo
git filter-repo --path .env --invert-paths
git push --force --all
git push --force --tags
Перепись истории меняет хеши коммитов. Предупредите коллекцию разработчиков: им нужно заново клонировать репозиторий, иначе старый секрет вернётся при следующем push. Форки и кэши платформы вы не очистите.
Шаг 4. Не допускайте повторения
Положите конфигурацию в шаблон и добавьте файл с настоящими значениями в игнор:
echo ".env" >> .gitignore
git rm --cached .env
cp .env .env.example # затем замените значения заглушками
Добавьте проверку перед коммитом (pre-commit):
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0 # укажите актуальную версию
hooks:
- id: gitleaks
pip install pre-commit && pre-commit install
Проверка локально обходится флагом --no-verify, поэтому повторите её в CI. Пример для GitLab:
secret-scan:
image:
name: zricethezav/gitleaks:latest
entrypoint: [""]
script:
- gitleaks detect --source . -v
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
Используйте закреплённые версии образов вместо latest. Сканирование зависимостей и кода в том же конвейере: Dependency-Track и SonarQube.
Как проверить
- Повторный запуск
gitleaks detectне находит прежних секретов в истории. - Попытка закоммитить файл с тестовым ключом блокируется хуком.
- Старый токен возвращает ошибку авторизации.
















