Вы не изменили коммит — вы изменили прошлое. А потом никто не смог это доказать: новая техника атаки Commit Stomping

В Git обнаружена методика сокрытия истории изменений, способная запутать даже опытных специалистов по цифровой криминалистике. Речь идёт не о новой уязвимости, а о функциональности, которая при неправильном использовании может стать настоящим инструментом манипуляции — технике, получившей название Commit Stomping . Она позволяет изменить временные метки коммитов в репозитории, чтобы скрыть или исказить реальную последовательность событий, вводя в заблуждение при аудите , расследовании инцидентов или анализе кода.

Сам Git по своей природе децентрализован и доверяет пользователю. В каждый коммит закладываются две временные метки: GIT_AUTHOR_DATE — когда была написана логика, и GIT_COMMITTER_DATE — когда коммит был зафиксирован в истории. Эти значения можно легко переопределить вручную через переменные окружения, что открывает возможности для хронологических манипуляций.

Злоумышленник может, например, внести вредоносный код и задним числом «вписать» его в старый релиз, указав дату, которая органично вписывается в прошлую разработку. Таким образом, вредоносный фрагмент будет выглядеть как легитимная часть старой версии, затрудняя поиск причины уязвимости и мешая точно определить момент внедрения.

Изменение временных меток коммита (zsec.uk)

Механизмы Git вроде rebase и commit --amend также переписывают историю, автоматически изменяя GIT_COMMITTER_DATE. Но особую опасность представляет ручное указание временных меток или массовое изменение истории с помощью таких инструментов, как git filter-branch или git filter-repo. В рамках этих процедур можно не только изменить дату конкретного коммита, но и замаскировать целую серию действий под другую временную рамку.

Признаки того, что в репозитории может быть использован Commit Stomping, включают одинаковые метки времени на разных коммитах, существенные расхождения между датами автора и коммиттера, появление новых коммитов с задним числом или несовпадение метаданных с логами CI/CD. При этом, если злоумышленник проявил осторожность и использовал умеренные временные смещения, обнаружить вмешательство становится крайне сложно без дополнительных источников информации.

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

Чтобы защититься от таких манипуляций, рекомендуется:

• Внедрить проверку подписанных коммитов через GPG или SSH;

• Вести внешние логирования поступающих коммитов в CI/CD или на стороне Git-сервера;

• Использовать зеркала репозиториев на неизменяемом хранилище;

• Запретить force-push на защищённые ветки;

• Следить за аномалиями в хронологии коммитов, особенно при аудите кода или выпуске релизов.

Commit Stomping — это не баг, не эксплойт и не CVE. Это логичное следствие архитектуры Git, построенной на гибкости и доверии к разработчику. Однако в эпоху, когда контроль за исходным кодом стал частью периметра безопасности, этого доверия уже недостаточно. Без дополнительных слоёв защиты история изменений перестаёт быть источником правды и превращается в потенциальный вектор обмана.

На фоне роста атак на цепочки поставок и случаев саботажа в open-source-проектах, возможность скрыть или подделать историю коммитов должна рассматриваться как реальный риск. Особенно в сценариях, где идёт имитация действий внутри команды, сокрытие инсайдерской активности или моделирование продвинутых злоумышленников. Git рассказывает историю разработки. Commit Stomping позволяет переписать эту историю, изменяя ключевые факты — и тем самым мешая добраться до истины.