По состоянию на 06.11: секрет, удалённый из кода, остаётся в истории коммитов Git и может быть доступен через старые версии файлов. Первым шагом отзовите или замените ключ в сервисе, затем найдите остальные секреты сканером Gitleaks. Очистка истории отзыв ключа не заменяет.
Что произошло
Автор разбора на Habr от 04.11.2026 описывает, как находить секреты в репозиториях Git: публикация на Habr. Подтверждения других изданий пока нет, поэтому ниже только то, что сказано в этой публикации.
Автор описывает типичный сценарий. Разработчик вставляет API-ключ в конфиг, делает коммит и отправляет его в репозиторий. Через неделю ключ убирают из кода, задачу закрывают. Но строка пропала только из актуальной версии, а в истории Git она осталась.
По словам автора, если репозиторий публичный, ключ может обнаружиться спустя месяцы. Если ключ даёт доступ к облачной инфраструктуре, базе данных или стороннему API, последствия могут быть тяжёлыми. Он также пишет, что секрет нельзя считать безопасным, если он пробыл в публичном репозитории несколько минут: автоматические сканеры могут обнаруживать новые коммиты практически сразу.
К чувствительным данным статья относит API-ключи и токены доступа, пароли от баз данных, приватные SSH-ключи, учётные данные облачных сервисов, секреты для интеграций и вебхуков, а также файлы .env. Искать нужно не только в исходниках, но и в конфигурациях, тестовых данных, скриптах развёртывания и старых коммитах.
Для поиска автор предлагает Gitleaks. Инструмент работает по набору правил и проверяет как локальный репозиторий вместе с историей коммитов, так и обычный каталог с исходниками. Документация лежит в официальном репозитории Gitleaks. Автор предупреждает: находка ещё не означает действующий секрет, потому что сканер может принять за ключ тестовое значение или заглушку.
Статья называет четыре меры: переменные окружения или хранилище секретов, проверку перед коммитом, сканирование в CI/CD и отказ от опоры только на .gitignore. Если секрет уже в репозитории, автор советует сначала отозвать или заменить ключ. Очистка истории, по его словам, не заменяет отзыв: старые коммиты могут остаться в клонах, форках и других копиях. О конкретных инцидентах и причинах утечек в публикации не сообщается.
Что это значит для интернет-магазина
Дальше идёт наша оценка для магазинов, а не пересказ публикации. По нашей оценке, у магазина секретов обычно больше, чем помнят владельцы: ключ платёжного шлюза, токен службы доставки, доступ к CRM, пароль от базы заказов, токен Telegram-бота, секрет вебхука маркетплейса. Каждый из них мог когда-то оказаться в конфиге, скрипте выгрузки или тестовом файле.
Представьте гипотетический сценарий. Подрядчик когда-то написал интеграцию с доставкой и вставил токен прямо в код. Потом токен заменили на переменную окружения, и все решили, что вопрос закрыт. Но старый токен лежит в истории и может продолжать работать, если его не отозвали в кабинете сервиса.
По нашей оценке, здесь два риска. Первый касается денег и заказов: чем шире права ключа, тем больше действий можно выполнить от имени магазина. Второй касается данных покупателей: если ключ открывает доступ к клиентской базе, вопрос выходит за рамки техники. О том, где держать базу и какие требования к ней предъявляют, мы писали в материале Хранение данных ФЗ-152: где держать базу интернет-магазина.
Мы рекомендуем сканировать копию репозитория: так работающий сайт остаётся нетронутым. Отзыв ключа, напротив, требует аккуратности: если новый ключ не прописать в интеграции, она перестанет работать. Поэтому порядок действий важнее скорости, и ниже он расписан по шагам.
Если вы только выстраиваете общий порядок проверок, начните с материала Что проверить в интернет-магазине: план владельца. Поиск секретов туда вписывается отдельной строкой.
План действий: до, в первый час и после
Этот план верен независимо от новостей. Он рассчитан на владельца магазина, у которого есть хотя бы один репозиторий с кодом сайта или интеграций, и на разработчика, который его ведёт.
До: что подготовить заранее
Главная подготовка — знать, какие секреты у магазина есть. Составьте реестр: название сервиса, что даёт ключ, кто его создал, где используется и когда его последний раз меняли. Хватит таблицы на одном листе. Без реестра при инциденте вы тратите время на вопрос «а что это за ключ».
Второй шаг — убрать секреты из кода. Ключи живут в переменных окружения или в хранилище секретов, а в репозитории лежит только пример файла с пустыми значениями, например .env.example. Файл .env добавьте в .gitignore, но не рассчитывайте только на него: он защищает от случайного добавления новых файлов, но не удаляет уже отслеживаемый файл и не чистит историю.
Третий шаг — автоматические проверки. Gitleaks запускают в двух местах: на компьютере разработчика перед коммитом и в CI при каждом изменении кода. Если сканер нашёл секрет, сборка падает, и ключ не доезжает до сервера. Так разработчик узнаёт о проблеме до развёртывания, а не после.
Четвёртый шаг — разовая проверка старых репозиториев. Проверьте историю целиком, а не только текущую ветку: именно там лежат забытые ключи. Это особенно важно для проектов, которые долго развивались без проверок и сменили несколько подрядчиков.
Пятый шаг — права. У каждого ключа должен быть минимальный набор разрешений: ключ для чтения каталога не должен уметь менять цены. Мы рекомендуем ограничить ключи по правам и сетевым адресам, где сервис это позволяет. Тогда даже утёкший ключ даст меньше возможностей.
Ниже — что закрывает каждая мера и чего не закрывает.
| Мера | Что закрывает | Чего не закрывает |
|---|---|---|
| .gitignore | Случайное добавление новых файлов | Уже отслеживаемые файлы и старые коммиты |
| Проверка перед коммитом | Секрет до отправки в удалённый репозиторий | Секреты, которые уже лежат в истории |
| Сканирование в CI | Обход локальной проверки и забывчивость | Секреты, уже попавшие в историю |
| Очистка истории | Секрет в основном репозитории | Клоны, форки и сам действующий ключ |
Вывод: ни одна мера не работает в одиночку, а единственное, что обесценивает утёкший ключ, — его отзыв.
В первый час: что сделать сразу
Представьте, что сканер нашёл действующий ключ в старом коммите. Действуйте в таком порядке, без пропусков.
- Отозвать ключ в кабинете сервиса — это делает владелец аккаунта или администратор интеграции. Удаление строки из кода ключ не обезвреживает.
- Выпустить новый ключ и прописать его в переменных окружения на сервере — это делает разработчик, который отвечает за деплой.
- Проверить журнал использования старого ключа в кабинете сервиса — это делает тот, у кого есть доступ к кабинету. Ищите запросы с незнакомых адресов и в нерабочее время.
- Оценить, какие данные и действия были доступны через ключ, и записать это в реестр — это делает владелец магазина вместе с разработчиком.
- Убедиться, что интеграция работает с новым ключом: оформить тестовый заказ или выполнить тестовый запрос — это делает тот, кто настраивал интеграцию.
- Закрыть доступ к репозиторию для посторонних, если он был публичным, — это делает владелец организации на хостинге кода.
Обратите внимание на порядок. Сначала отзыв, потом всё остальное: пока старый ключ жив, остальные действия не защищают магазин. Если сервис не позволяет выпустить второй ключ до отзыва первого, заранее согласуйте окно и предупредите команду.
После: что проверить и закрепить
Когда ключ заменён, переходите к истории. Уберите секрет из актуальной версии кода, затем решите, нужна ли очистка истории. Её делают специальными инструментами переписывания истории. Мы рекомендуем заранее предупредить команду: после такой очистки участникам придётся заново клонировать репозиторий.
Дальше мы рекомендуем провести ретроспективу без поиска виноватых. Ответьте на три вопроса: как ключ попал в коммит, почему проверка не остановила его и что нужно изменить в процессе. Часто выясняется, что у проекта не было ни проверки перед коммитом, ни шаблона .env.example, ни правила про подрядчиков.
Затем обновите реестр секретов и добавьте в него дату следующей ротации. Мы рекомендуем в первую очередь заменить ключи, которые никто не менял с момента создания, и менять ключи при уходе сотрудника или подрядчика.
Наконец, проверьте, что автоматика работает. Мы рекомендуем положить в тестовую ветку заведомо фальшивый ключ в формате, который ловит Gitleaks, и убедиться, что CI упал. Если не упал, правило проверки не подключено. После этого сделайте повторный полный скан истории и сравните результаты с первым: новых находок быть не должно.
Если у вас уже работает автоматизация на n8n и Supabase, добавьте туда уведомление о находках сканера в рабочий чат. Как собрать такую цепочку, показывает материал Автоматизация рутины на n8n и Supabase: пошаговый гайд.
Частые вопросы
Если удалить ключ из кода и сделать новый коммит, он перестанет быть доступен?
Нет. Новый коммит убирает строку только из актуальной версии файлов. Предыдущий коммит с ключом остаётся в истории, и любой, у кого есть доступ к репозиторию или его копии, может открыть старую версию файла. Поэтому после такой правки ключ считается скомпрометированным. Единственная надёжная мера — отозвать его в сервисе и выпустить новый.
Как проверить старые коммиты репозитория на забытые секреты через Gitleaks?
Установите Gitleaks по инструкции из официального репозитория и запустите проверку Git-репозитория в нужном каталоге: инструмент умеет работать с историей коммитов. Для каталога без Git есть отдельный режим проверки файлов. Точные команды зависят от версии, поэтому сверяйтесь с документацией. Каждую находку проверьте вручную: сканер может принять за ключ тестовое значение или заглушку.
Достаточно ли добавить .env в .gitignore, чтобы ключи не попали в репозиторий?
Нет, этого мало. Запись в .gitignore защищает только от случайного добавления новых файлов. Если файл .env уже отслеживается Git, запись его не удалит, а история коммитов останется прежней. Секреты также попадают в репозиторий через скрипты развёртывания, тестовые данные и конфиги. Надёжнее связка: переменные окружения или хранилище секретов, проверка перед коммитом и сканирование в CI.
Что сделать первым, если сканер нашёл действующий API-ключ в старом коммите?
Отозвать или заменить ключ в кабинете сервиса. Пока старый ключ работает, всё остальное не защищает магазин. Затем проверьте журнал его использования на подозрительную активность, оцените, к каким ресурсам и данным он давал доступ, и пропишите новый ключ в переменных окружения.
Нужно ли чистить историю Git после отзыва ключа и зачем?
Желательно, но это вторичный шаг. После отзыва старый ключ уже не открывает доступ. Очистка нужна, чтобы секрет не всплывал в новых проверках и не путал разбор находок. Старые коммиты могут сохраниться в клонах и форках, поэтому очистка идёт после отзыва, а не вместо него. Мы рекомендуем перед переписыванием истории предупредить команду: репозиторий придётся клонировать заново.
Что делать дальше
Начните с реестра секретов и полного скана истории всех репозиториев магазина, затем подключите проверку перед коммитом и в CI. Если нет времени или внутреннего разработчика, передайте поиск забытых ключей на Аудит и миграцию.
