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

0
13
Обложка статьи: Секреты в 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. Сначала отзовите секрет

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

  1. Выпустите новый пароль, токен или ключ.
  2. Подставьте новый в сервисы, которые его используют.
  3. Отзовите старый.
  4. Посмотрите журналы сервиса за период, пока секрет был в репозитории: не использовали ли его посторонние.

Шаг 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 не находит прежних секретов в истории.
  • Попытка закоммитить файл с тестовым ключом блокируется хуком.
  • Старый токен возвращает ошибку авторизации.

Оставьте свой ответ