Git History Secret-Scrub Dry-Run Simulator
Показать, что удалит фильтрация истории по списку секретов, без реального переписывания репозитория.
Как это работает
Пароль от продакшн базы случайно закоммитили полгода назад, с тех пор было полсотни коммитов поверх, и теперь стоит понятная, но пугающая задача — вычистить секрет из всей истории репозитория через git filter-repo или BFG Repo Cleaner. Проблема в том, что оба инструмента переписывают историю необратимо: если список коммитов для очистки составлен неточно, можно снести часть легитимной истории или, наоборот, пропустить нужный коммит. Git History Secret-Scrub Dry-Run Simulator online показывает, какие именно коммиты и файлы попадут под фильтрацию по вашему списку секретов, прежде чем вы запустите необратимую команду на реальном репозитории.
Есть отдельная, почти комичная в своей серьёзности ирония в том, чтобы вставить утёкший пароль в чат стороннего облачного сервиса именно в процессе его удаления из истории — вы буквально создаёте вторую копию утечки в момент борьбы с первой. Локальный дозапуск в браузере полностью убирает этот риск: секрет, который вы анализируете, физически не покидает вкладку. А сама логика работы filter-repo и BFG — where именно в истории коммитов встречается строка, через какие родительские связи она наследуется дальше по дереву — вещь, которую языковая модель без доступа к реальному git-объекту репозитория попросту не может посчитать точно, а лишь правдоподобно предположить.
Симулятор принимает упрощённое текстовое представление истории коммитов (хэш, родитель, список изменённых файлов с содержимым или diff) и список секретных строк или паттернов для поиска, и строит отчёт: какие коммиты содержат совпадение, в каких файлах, и — что критичнее всего — какие из них станут точками ветвления после реальной фильтрации, потому что переписывание истории меняет хэши всех дочерних коммитов последовательно.
Частые вопросы
Чем это отличается от реального запуска git filter-repo?
Симулятор не трогает никакой реальный репозиторий и не переписывает историю, он лишь показывает по введённым вами данным о коммитах, что предположительно попадёт под фильтрацию, финальное решение и сама операция остаются за вами и выполняются отдельно вашим собственным git filter-repo или BFG.
Почему переписывание истории меняет хэши даже тех коммитов, где секрета не было?
Хэш каждого коммита в git вычисляется в том числе на основе хэша его родителя, если родительский коммит изменился при фильтрации, хэш дочернего коммита тоже меняется автоматически, даже если содержимое самого дочернего коммита осталось прежним по сути.
Нужно ли после реальной очистки истории ещё что-то делать с секретом?
Да, и это критически важно: сам по себе секрет всё ещё считается скомпрометированным, потому что мог успеть засветиться в форках, локальных клонах коллег или кэшах CI, единственное по-настоящему надёжное действие — отозвать и заменить сам секрет, а не только вычистить его из истории git.
Можно ли проверить сразу несколько разных секретных паттернов одновременно?
Да, инструмент принимает список строк или regex-паттернов и проверяет каждый коммит на совпадение с любым из них, показывая, какой конкретно паттерн сработал в каждом найденном случае.
Что если секрет менялся в разных коммитах, а не просто один раз закоммичен?
Симулятор находит каждое отдельное вхождение паттерна в каждом коммите независимо, если значение секрета менялось со временем, стоит добавить все его исторические варианты в список паттернов для поиска, иначе часть истории с устаревшим, но всё ещё чувствительным значением может остаться незамеченной.