Jak sprawdzić, czy ktoś podmienił lub zmienił kod źródłowy?

Sprawdzenie, czy ktoś zmienił kod źródłowy, to w praktyce pytanie o to, czy plik, który masz teraz, jest bitowo identyczny z tym, który był w określonym momencie w przeszłości. Zmiana nawet jednej spacji, komentarza, znaku nowej linii czy kolejności importów powoduje, że plik przestaje być taki sam. W codziennej pracy programisty to nie tylko kwestia podejrzeń wobec współpracownika czy dostawcy, ale też audytu bezpieczeństwa, weryfikacji integralności biblioteki pobranej z internetu, potwierdzenia, że build na serwerze pochodzi z dokładnie tego commita, który został zatwierdzony, albo dokumentacji w sporze o autorstwo i zakres prac. Najprościej rzecz ujmując, potrzebujemy dowodu technicznego, a nie opinii. Taki dowód daje kryptografia, a nie czytanie kodu na oko.

Najbardziej podstawowym i powszechnie akceptowanym narzędziem jest suma kontrolna, czyli hash kryptograficzny. SHA-256, MD5 czy CRC32 to funkcje, które z dowolnego pliku tworzą unikalny odcisk o stałej długości. Jeśli plik się zmieni, nawet minimalnie, odcisk zmienia się w sposób nieprzewidywalny i praktycznie nie do podrobienia. W praktyce oznacza to, że wystarczy porównać hash zapisany w momencie publikacji z hashem pliku pobranego teraz. Równość oznacza identyczność bitową, różnica oznacza modyfikację. MD5 jest szybki i historycznie popularny, ale dziś traktuje się go jako pomocniczy. SHA-256 jest standardem w forensyce i dystrybucji oprogramowania. CRC32 jest przydatny do wykrywania przypadkowych błędów transmisji, ale nie zapewnia ochrony przed celową manipulacją. To ważne rozróżnienie techniczne, bo hash dokumentuje stan pliku, nie mówi kto i dlaczego go zmienił.

Hash sam w sobie nie mówi nic o kontekście pliku. Dlatego w pełnej weryfikacji kodu źródłowego warto spojrzeć też na metadane techniczne. Pliki źródłowe, choć same w sobie są tekstowe, często trafiają do archiwów ZIP, TAR.GZ, repozytoriów czy paczek, które niosą dodatkowe informacje. W ZIP-ie można odczytać czasy utworzenia i modyfikacji wpisów, atrybuty kompresji, komentarze. W repozytorium Git metadane commita, tagi i podpisy GPG tworzą łańcuch dowodowy. W praktyce oznacza to, że oprócz porównywania hashy pliku .py, .js, .c czy .java warto sprawdzić, czy data modyfikacji na dysku odpowiada wersji, którą deklaruje autor, czy w archiwum nie pojawiły się nowe pliki, czy nie zmieniły się uprawnienia. To właśnie analiza metadanych pozwala zbudować pełniejszy obraz, co się stało z plikiem i kiedy.

Przykład z życia wygląda tak. Otrzymujesz od podwykonawcy paczkę source.zip z kodem modułu płatności. W umowie masz zapisany SHA-256: a3f4...9c1. Po rozpakowaniu liczysz hash całego archiwum i hash kluczowego pliku payment_gateway.py. Jeśli którykolwiek się nie zgadza, wiesz, że plik nie jest tym, który był zatwierdzony. Kolejny krok to porównanie z wersją z repozytorium wewnętrznego. Pobierasz commit z datą dostawy, tworzysz z niego archiwum w identyczny sposób i liczysz hash. Jeśli hashe się zgadzają, masz techniczne potwierdzenie zgodności. Jeśli nie, szukasz przyczyny: inna końcówka linii Windows vs Unix, dodany plik .DS_Store, zmiana kolejności plików w archiwum. Dlatego w standardach forensic porównuje się najpierw hash całego pakietu, a potem hash poszczególnych plików krytycznych.

W codziennej pracy zespołowej to właśnie szybkie, niezależne narzędzie do wyliczenia odcisków i metadanych oszczędza godziny. Można wgrać plik, archiwum czy nawet cały folder spakowany do ZIP i uzyskać raport z hashami SHA-256, MD5, CRC32, listą metadanych pliku systemowego, czasem utworzenia i modyfikacji oraz strukturą zawartości. Takie podejście jest szczególnie przydatne, gdy nie masz dostępu do oryginalnego repozytorium albo gdy chcesz udokumentować stan pliku dla audytu bez instalowania lokalnego oprogramowania. Na stronie głównej FilesAudit można wgrać plik w przeglądarce i uzyskać profesjonalny raport PDF z odciskami i metadanymi, który nadaje się do dokumentacji. Platforma obsługuje ponad dwieście formatów, w tym wszystkie typowe rozszerzenia kodu źródłowego, skrypty, pliki wykonywalne i archiwa, co znajdziesz w pełną listę obsługiwanych formatów.

Dla zespołów, które weryfikują pliki regularnie, wygodniejsze jest lokalne przetwarzanie. Aplikacja desktopowa pozwala na masową analizę bez wysyłania danych poza firmę, co jest ważne przy kodzie poufnym. W praktyce analityk może załadować paczkę z dostawą, wygenerować raport z hashami i metadanymi dla każdego pliku, a następnie porównać go z raportem z poprzedniej dostawy. Różnice w hashach wskazują dokładnie, które pliki zostały zmienione, a metadane pokazują, kiedy i czy zmieniała się struktura archiwum. To nie jest dowód prawny o autorstwie, to dokumentacja techniczna, która mówi jednoznacznie: plik A z dnia X ma odcisk Y, a plik A z dnia Z ma odcisk W, czyli są różne. Interpretacja prawna, kto dokonał zmiany i czy była umówiona, należy już do zespołu prawnego i procesu.

Warto też pamiętać o ograniczeniach. Hash potwierdza zmianę, ale nie mówi co się zmieniło. Do tego służy diff. Hash nie identyfikuje osoby, która wprowadziła modyfikację, chyba że mamy podpisany commit GPG albo logi dostępu. Hash nie chroni przed sytuacją, w której ktoś celowo zmieni plik i jednocześnie zaktualizuje zapisany hash w dokumentacji. Dlatego dobre praktyki łączą hash z datą pobrania, zapisem w systemie zarządzania wersjami i niezależnym raportem z metadanymi. Metadane EXIF, XMP czy IPTC nie występują w czystych plikach .c czy .java, ale pojawiają się w dokumentacji projektowej, obrazach w repozytorium czy w plikach PDF z opisem API. Spójność tych śladów wzmacnia wiarygodność całego pakietu dowodowego.

Podsumowując, sprawdzenie, czy ktoś zmienił kod źródłowy, sprowadza się do uzyskania niezależnego, powtarzalnego odcisku pliku w przeszłości i porównania go z obecnym stanem. SHA-256 daje pewność bitowej identyczności, metadane dają kontekst czasowy i strukturalny, a profesjonalny raport pozwala udokumentować to dla audytu, compliance czy sporu. To podejście techniczne, nie praw