Руководства по безопасности
Останавливайте секреты до коммита с gitleaks: ловите утечки API-ключей до push
Случайно закоммитите API-ключ — и он останется в истории Git, утёкшим навсегда. Как gitleaks останавливает секреты на двух воротах — хук pre-commit и CI — плюс шаг отзыва, который одно обнаружение не завершает.
Для тех, кто использует Git в разработке в одиночку или малой командой и беспокоится «а вдруг я случайно закоммичу API-ключ?» Здесь нет механики атакующего — только механизм для остановки утечки секретов из вашего собственного репозитория.
Взгляд этого сайта: один .gitignore не защитит секреты
«Мой .env в .gitignore, так что всё нормально» — частая фраза, и в ней есть дыры. .gitignore лишь не даёт новым файлам отслеживаться; он не может поймать секреты, уже закоммиченные, принудительно добавленные впопыхах через git add -f или неожиданные имена вроде .env.local.bak. Он блокирует лишь часть входа. Нужно что-то, что реально смотрит в содержимое коммитов и помечает «строки, похожие на секреты» — детектор. Для этого и нужен gitleaks.
Почему останавливать «до коммита»
Секреты опасны тем, что Git хранит историю вечно. Удалите из последнего файла — он остаётся в прошлых коммитах. А в момент push эта история копируется на другие машины, серверы и в логи CI.
Так что защита секретов — это на самом деле профилактика до утечки, а не восстановление после неё. Та же идея, что и инвентаризация «не оставляйте секреты в публичной директории» (→ инвентаризация веб-корня), перенесённая в мир кода.
Где ставить ворота
На пути секрета от кода к миру можно поставить двое ворот: в момент локального коммита и прямо перед тем, как им поделятся (CI).
секрет в коде
API-ключ, ключ, токен
ворота 1: pre-commit
обнаружить и прервать локально при коммите
ворота 2: CI / cron
обнаружить после push, до merge/деплоя
публично / общий доступ
после этого считать утёкшим
Как встроить gitleaks
Сначала просканируйте существующую историю
gitleaks detect. Выявить секреты, спящие в прошлых коммитах, — первая задача. Всё найденное здесь, как ниже, считается требующим отзыва.Постройте ворота 1 хуком pre-commit
gitleaks protect --staged на каждом коммите, чтобы прерывать на месте любой коммит, содержащий секрет. Добавьте его в фреймворк pre-commit (.pre-commit-config.yaml), чтобы та же проверка применялась у всех, локально.Постройте ворота 2 в CI / cron
gitleaks detect как задание CI — или, для самостоятельных конфигураций, как периодический скан — чтобы ловить просочившееся (тот же подход машинного мониторинга, что и аудит зависимостей).Настройте ложные срабатывания в .gitleaks.toml
.gitleaks.toml. Правильная практика — не «заглушить», а «записать, почему это безопасно»: исключение без обоснования — семя следующего инцидента.При обнаружении «отзыв» идёт первым; переписывание истории — потом
Когда вы находите секрет, который был закоммичен и запушен, высший приоритет — отозвать и перевыпустить (сменить) этот ключ или токен. Стереть его из истории через git filter-repo важно, но это лишь уборка, чтобы «остановить дальнейшее распространение». Исходите из того, что секрет, достигший публичного репозитория, форка, лога CI или чужого клона, невосстановим — сначала аннулируйте его, затем чистите историю. Переверните порядок — и его используют, пока вы ещё удаляете.
Опора на .gitignore
- лишь предотвращает новое отслеживание
- секреты, уже закоммиченные, проходят насквозь
- бессилен против
git add -fили странных имён файлов - не может проверить «я не собирался это добавлять»
gitleaks (обнаружение + практика отзыва)
- реально инспектирует рабочее дерево и содержимое истории
- останавливает на двух воротах: pre-commit и CI
- при обнаружении — процедура, доходящая до отзыва
- ложные срабатывания исключены с записанным обоснованием
Что делает сам этот сайт
Этот сайт построен на основе полного недопущения секретов в Git — строки подключения и API-ключи живут только в защищённой конфигурации на сервере (env-файл с ограниченными правами), никогда в открытом виде в репозитории или в передаточных заметках (→ держать секреты вне git / самостоятельный Git против GitHub). Поверх этого мы наслаиваем детекторы в расчёте на то, что люди всегда оступятся. Проектирование гарантирует «не клади внутрь», а скан вроде gitleaks ловит «оно всё равно попало» — эти два слоя и есть защита этого сайта от утечки секретов. Сам принцип обращения с секретами продолжается в .env-файлы и секреты и безопасное хранение паролей.
Читать дальше
- Инвентаризация: не оставляете ли вы секреты в публичной директории
- Самостоятельный хостинг: держать секреты вне git / самостоятельный Git против GitHub
- Глоссарий: что такое «.env» — что происходит при утечке env-файла
- Инструмент: сканер утечки секретов (вставьте и проверьте)
FAQ
QЧто такое gitleaks?
Бесплатный инструмент, сканирующий рабочее дерево и историю коммитов Git-репозитория, чтобы обнаружить, не закоммичены ли секреты — API-ключи, приватные ключи, токены. Он находит «строки, похожие на секреты» по правилам regex и энтропии строк (случайности) и может работать как хук pre-commit или в CI для автоматических проверок.
QРазве помещение в .gitignore не защищает секреты?
Недостаточно. .gitignore лишь останавливает «новое отслеживание» — он не умеет обнаруживать секреты, уже закоммиченные, или принудительно добавленные через git add -f. Он блокирует лишь часть аварии, так что сочетайте его с детектором вроде gitleaks и в pre-commit, и в CI.
QЧто если я случайно закоммитил и запушил секрет?
Считайте этот секрет утёкшим. Высший приоритет — не переписать историю, а отозвать и сменить (перевыпустить) раскрытый ключ или токен. Исходите из того, что секрет, попавший в публичный репозиторий или лог, нельзя отозвать — сначала аннулируйте его, затем чистите историю и добавьте профилактику (gitleaks).