Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowe ustalenia dotyczące podpisanych commitów w Git wskazują na istotną słabość modelu zaufania związanego z oznaczeniem „Verified” w GitHubie. Problem polega na tym, że ten sam logicznie commit może zostać zapisany w alternatywnej, nadal poprawnej kryptograficznie formie, co skutkuje wygenerowaniem nowego hasha obiektu bez utraty statusu weryfikacji.
W praktyce oznacza to, że zweryfikowany commit nie zawsze jest jednoznacznie związany z jednym, trwałym identyfikatorem. To ważna różnica dla organizacji, które traktują hash commita jako niezmienny wskaźnik integralności i pochodzenia kodu.
W skrócie
Opisane zjawisko nie oznacza złamania podpisów kryptograficznych ani podmiany kodu. Zmienia się wyłącznie sposób zapisania podpisu lub jego struktury binarnej, przez co powstaje inny hash, mimo że autor, treść i znaczenie commita pozostają takie same.
- nie dochodzi do kolizji funkcji skrótu,
- nie dochodzi do obejścia weryfikacji podpisu przez sfałszowanie autora,
- możliwe jest jednak utworzenie alternatywnego hasha dla tego samego logicznie commita,
- ryzyko dotyczy głównie mechanizmów bezpieczeństwa opartych na hashach commitów.
Kontekst / historia
Podpisane commity od lat stanowią ważny element budowania zaufania w ekosystemie open source i DevSecOps. W wielu organizacjach status „Verified” jest interpretowany nie tylko jako potwierdzenie autentyczności autora, ale również jako gwarancja stabilnego odniesienia do konkretnego obiektu w historii repozytorium.
Badania Jacoba Ginesina zwróciły uwagę na zjawisko określane jako hash chain malleability. Problem wynika z tego, że commit w Git identyfikuje także swojego rodzica po hashu. Jeśli więc jeden podpisany obiekt można zapisać w innej poprawnej formie, zmiana propaguje się dalej i wpływa na identyfikatory kolejnych commitów w łańcuchu historii.
Z perspektywy kryptografii nie jest to koncepcja całkowicie nowa. Podobne zjawiska były już wcześniej znane, między innymi w kontekście modyfikowalności transakcji opartych na ECDSA. W przypadku Git skutki są jednak szczególnie istotne, ponieważ hashe commitów są szeroko wykorzystywane w politykach bezpieczeństwa, audycie i systemach śledzenia pochodzenia kodu.
Analiza techniczna
Źródłem problemu jest sposób, w jaki Git oblicza hash obiektu commita. Skrót liczony jest z całego obiektu, w tym z surowych bajtów podpisu zapisanych w nagłówku. Jeśli ten sam podpis może zostać przedstawiony w więcej niż jednej poprawnej postaci, każda z tych reprezentacji wygeneruje inny hash.
Badania opisują kilka ścieżek prowadzących do takiego efektu. W przypadku ECDSA możliwe jest przekształcenie wartości podpisu do matematycznie równoważnej formy, która nadal przejdzie proces weryfikacji. Dla RSA i EdDSA problem może wynikać z dodania dodatkowych pól w części podpisu nieuwzględnianej przez sam mechanizm kryptograficzny. Z kolei przy S/MIME można zmieniać elementy struktury DER w sposób niestandardowy, lecz nadal akceptowany przez platformę.
Wspólny mianownik pozostaje ten sam: brak pełnej normalizacji podpisu przed uznaniem commita za zweryfikowany. Jeżeli system akceptuje kilka niekanonicznych wariantów tego samego podpisu, może przypisać status „Verified” wielu różnym hashom reprezentującym ten sam logiczny obiekt.
Warto podkreślić, czego ten problem nie oznacza. Nie jest to atak na SHA-1 ani SHA-256, nie pozwala też ukryć innego kodu pod prawidłowym podpisem. Jeśli organizacja pobiera konkretny hash commita, otrzyma dokładnie tę treść, którą wskazuje dany identyfikator. Problem pojawia się dopiero wtedy, gdy bezpieczeństwo procesu opiera się na założeniu, że jeden podpisany commit może istnieć wyłącznie pod jednym hashem.
Konsekwencje / ryzyko
Największe zagrożenie dotyczy środowisk, w których hashe commitów pełnią rolę podstawowych identyfikatorów zaufania. Jeśli atakujący może odtworzyć logicznie ten sam podpisany commit pod nowym hashem, może potencjalnie ominąć mechanizmy wykrywania i blokowania oparte wyłącznie na identyfikatorach obiektów.
- obchodzenie blocklist bazujących wyłącznie na hashach commitów,
- problemy z deduplikacją historii i obiektów,
- osłabienie części systemów provenance oraz audytu łańcucha dostaw,
- rozbieżności w analizie historii między mirrorami i repozytoriami pośredniczącymi,
- błędne przekonanie, że status „Verified” gwarantuje unikalność hasha.
Ryzyko jest szczególnie istotne w środowiskach korzystających z zewnętrznych mirrorów, zautomatyzowanej analizy pochodzenia kodu, CI/CD oraz reguł bezpieczeństwa opartych na prostym powiązaniu podpisu z jednym identyfikatorem. Mniejsze znaczenie problem ma tam, gdzie organizacja dodatkowo weryfikuje niezależne hashe plików źródłowych, drzew repozytorium lub końcowych artefaktów builda.
Rekomendacje
Zespoły bezpieczeństwa, AppSec i DevSecOps powinny potraktować tę kwestię jako sygnał do przeglądu założeń dotyczących zaufania do podpisanych commitów. Sam status „Verified” nadal pozostaje użyteczny jako wskaźnik autentyczności podpisu, ale nie powinien być utożsamiany z gwarancją niepowtarzalności identyfikatora obiektu.
- nie traktować statusu „Verified” jako dowodu unikalności hasha commita,
- oddzielić pojęcie poprawnego podpisu od trwałego identyfikatora treści,
- w blocklistach i systemach detekcji analizować także kanoniczną postać podpisu,
- w procesach provenance przechowywać dodatkowe metadane dotyczące treści drzewa lub artefaktów builda,
- stosować niezależne mechanizmy integralności, takie jak pinning hashy plików, manifestów i artefaktów,
- monitorować zachowanie platform forge oraz narzędzi CI/CD wobec niekanonicznych podpisów,
- uwzględnić ten scenariusz w modelowaniu zagrożeń dla software supply chain.
W praktyce bardziej odporne podejście powinno opierać się na zestawie atrybutów, a nie na samym hashu commita. Obejmuje to analizę autora, treści drzewa, znormalizowanego podpisu oraz dodatkowych danych potwierdzających pochodzenie kodu.
Podsumowanie
Opisana technika nie łamie kryptografii i nie umożliwia niezauważonej podmiany kodu. Podważa jednak istotne założenie operacyjne, zgodnie z którym podpisany i zweryfikowany commit ma zawsze jeden niezmienny hash.
To subtelna, lecz ważna słabość dla bezpieczeństwa łańcucha dostaw oprogramowania. Wniosek dla organizacji jest jasny: podpis może potwierdzać autentyczność, ale nie zawsze gwarantuje unikalność reprezentacji obiektu, dlatego procesy bezpieczeństwa powinny uwzględniać więcej niż jeden punkt odniesienia.
Źródła
- The Hacker News — GitHub 'Verified’ Commits Can Be Rewritten Into New Hashes Without Breaking Signatures — https://thehackernews.com/2026/07/github-verified-commits-can-be.html
- arXiv — publikacje i materiały badawcze powiązane z analizą Jacoba Ginesina — https://arxiv.org/
- GitHub — publiczne repozytoria i demonstracje odnoszące się do badań — https://github.com/
- Bitcoin Wiki — tło dotyczące transaction malleability i ECDSA — https://en.bitcoin.it/wiki/Transaction_malleability