Исследователь показал неприятную вещь: Verified-коммиты GitHub можно переписать так, чтобы код, автор, дата и валидная подпись остались прежними, а хэш коммита стал другим. Для команд, которые привыкли считать подписанный commit hash уникальным паспортом изменения, это плохая новость: блоклист, журнал происхождения артефактов или дедупликация могут смотреть на «новый» объект и не заметить, что перед ними тот же самый код.
О работе 8 июля сообщило The Hacker News. Речь не о взломе SHA-1 или SHA-256 и не о способе подсунуть в репозиторий другой код под чужой подписью. Проблема уже и практичнее: если взять любой подписанный коммит, то без приватного ключа можно выпустить его вторую версию с другим хэшем, но с той же файловой структурой, тем же автором, той же датой и все той же отметкой GitHub Verified.
Автор исследования — Джейкоб Гинесин, аспирант Carnegie Mellon University и криптографический аудитор Cure53. Его пятистраничный препринт появился на arXiv 2 июля 2026 года. Вместе с ним опубликован инструмент, который воспроизводит три варианта атаки, а также две демонстрационные репозитории, где модифицированные коммиты по-прежнему отображаются на GitHub как проверенные. Это важная деталь: история тут не теоретическая и не в стиле «при определенных условиях в лаборатории», а с рабочим PoC.
Что именно ломается
Ключевой тезис исследования звучит почти как придирка, но бьет по очень земным практикам DevSecOps. Во многих процессах подписанный хэш коммита считается постоянным и единственным именем содержимого. Гинесин показывает, что это не так: меняются байты подписи внутри объекта коммита, из-за этого меняется хэш, но не меняется сам код. Если компания заблокировала вредоносный коммит по конкретному хэшу, атакующий может перепушить тот же контент под новым, тоже валидно подписанным хэшем, которого в блоклисте еще нет.
Под ударом оказываются не только блоклисты. Та же логика касается систем дедупликации, журналов provenance, записей о воспроизводимых сборках и любых внутренних контролей, которые доверяют именно хэшу подписанного коммита, а не результату дополнительной нормализации и повторной проверки подписи. Отдельный риск — зеркала и промежуточные узлы: враждебный или скомпрометированный mirror может отдавать клонам валидно подписанные коммиты с хэшами, отличающимися от тех, что лежат на каноническом forge.
При этом исследование не отменяет базовую гигиену цепочки поставки. Если вы уже зафиксировали конкретный commit hash в зависимости, GitHub Action или модуле, то получите ровно тот код, который ожидали, или не получите ничего. Новая работа не делает пиннинг бесполезным. Она бьет по более тонкой, но распространенной привычке: считать, что раз у коммита есть подпись и бейдж Verified, то его хэш автоматически становится единственным и окончательным идентификатором содержимого.
Техническая причина — изменяемость самих подписей. Хэш коммита в Git считается по всему объекту, включая сырые байты подписи в заголовке. Если подпись можно переписать в другую, но все еще корректную форму, то строка кода не меняется, а хэш уже другой. В исследовании описаны три маршрута. Для ECDSA-ключей используется классический прием с заменой значения s на n - s: обе формы валидны. Для RSA и EdDSA в подпись добавляется лишнее поле в секцию unhashed, которую проверка подписи сознательно не покрывает. Для S/MIME меняется поле длины в DER-структуре на более длинную нестандартную форму. В последнем случае строгая локальная проверка через gpgsm такой вариант отвергает, а GitHub все равно ставит Verified.
Почему это важно именно сейчас
Контекст у истории вполне прикладной. После атак на GitHub Actions, включая инцидент с tj-actions/changed-files в 2025 году и атаку на trivy-action в 2026-м, отрасль дружно повторяла один совет: не доверяйте подвижным тегам, привязывайтесь к полному хэшу коммита. Этот совет остается в силе и после новой публикации. Но в кейсе с Trivy вредоносные коммиты было проще отличить именно потому, что их нельзя было выдать за валидно подписанные. Работа Гинесина охлаждает этот оптимизм: сама по себе корректная подпись еще не означает, что хэш можно использовать как неоспоримый идентификатор объекта.
Есть и еще один неприятный штрих в реализации GitHub. По данным исследования, платформа не нормализует подпись перед проверкой, принимает неканонические формы и затем сохраняет запись о статусе Verified для конкретного хэша без повторной перепроверки. Из-за этого коммит сохраняет статус проверенного даже после отзыва ключа подписи. А если оригинал и его «близнец» отправить в разные ветки, интерфейс сравнения GitHub покажет расходящиеся истории — один коммит впереди, другой позади, хотя файлы внутри идентичны. Для ревьюера это уже не криптография, а визуальная и операционная путаница.
Разработчикам и security-командам из этой истории полезно вынести не панику, а корректировку модели доверия. Verified-коммиты GitHub по-прежнему подтверждают, кто подписал объект. Но они не гарантируют, что commit hash можно без оговорок использовать как уникальное имя содержимого в любых служебных системах. Если процесс строится на блокировке, учете или сопоставлении именно по хэшу подписанного коммита, туда нужно добавлять каноникализацию подписи и повторную верификацию. Системы, которые дополнительно хранят независимый хэш фактически полученных файлов, защищены лучше. В статье отдельно упоминается, что такой запасной контур есть, например, у fixed-output derivations в Nix.
Пока это выглядит как задача прежде всего для хостингов и forge-платформ, а не для рядового разработчика. Сам Гинесин пишет, что сообщил о проблеме GNU и Git в январе 2026 года, а GitHub — в марте, и на момент публикации ни Git, ни форжи ее не закрыли. Исправление, в общем, не из области магии: канонизировать подписи до того, как доверять хэшу, и начать, вероятно, стоит с S/MIME-сценария, где GitHub уже сейчас принимает то, что строгая локальная проверка отвергает. Вопрос теперь не в том, возможна ли такая подмена, а в том, насколько быстро инфраструктура разработки перестанет путать «подписано тем же человеком» и «это тот же самый объект». Подробности исследования собрал .