🛡 Секрет в Git не удаляется следующим коммитом Ошибочный коммит с API-ключом, паролем или дампом не исправляется удалением в новой версии. История хранит объект, и любой, кто читает репозиторий, может откатиться до нужного коммита. По данным habr_infosec, доступ на чтение получают ещё CI/CD, ответвления и клоны — доступ к репозиторию не должен означать доступ к базе. Сначала проверяем. Betterleaks проходит по каждому коммиту, патчу и изменению: betterleaks git . --log-opts="--all" -v. Если ключ засветился десять коммитов назад, он останется в отчёте. На примере статьи найден generic-api-key в config/sync/recaptcha_v3.settings.yml, строка 4. Кроме регулярных выражений там есть быстрый фильтр по ключевым словам, BPE-токенизация и декодирование Base64, шестнадцатеричного представления, URL. Ложные срабатывания есть, найденное разбирайте вручную. Чистим через git-filter-repo. Сначала создаём зеркальную резервную копию: git clone --mirror repo-backup.git, закрываем PR и останавливаем коммиты. Дальше два файла: secrets-to-replace.txt для замены секретов и paths-to-remove.txt для опасных расширений. Запуск: git filter-repo --invert-paths --paths-from-file paths-to-remove.txt --replace-text secrets-to-replace.txt. Затем git push --force --mirror origin. После принудительной отправки коллеги заново клонируют репозиторий, а не выполняют pull/rebase: идентификаторы коммитов стали другими. Старые объекты останутся в клонах, ответвлениях, кэшах CI/CD и журналах. Поэтому отозвать и заменить ключи надо до чистки, а не после. Я не считаю репозиторий чистым после переписывания истории, пока токен жив. Ротация — это ликвидация инцидента, git-filter-repo — гигиена. #Git #Betterleaks #gitfilterrepo #DevSecOps #secrets