Ponad 543 tys. aktywnych poświadczeń ujawnionych w publicznych repozytoriach GitHub

Wprowadzenie do problemu / definicja

Wycieki sekretów z kodu źródłowego pozostają jednym z najpoważniejszych problemów bezpieczeństwa w nowoczesnym cyklu wytwarzania oprogramowania. Chodzi o przypadki, w których do publicznego repozytorium trafiają aktywne poświadczenia, takie jak klucze API, tokeny dostępu, dane kont usługowych, webhooki czy connection stringi do baz danych.

Tego rodzaju ujawnienia są szczególnie groźne, ponieważ dają atakującym możliwość uzyskania legalnego dostępu do usług chmurowych, środowisk CI/CD, magazynów danych oraz interfejsów API bez konieczności klasycznego przełamywania zabezpieczeń.

W skrócie

Najnowsza analiza wykazała, że w publicznych repozytoriach GitHub znajdowało się ponad 543 tys. unikalnych, nadal aktywnych poświadczeń. Dane te zostały zidentyfikowane na podstawie analizy 224 mln repozytoriów i ponad 58 mld plików.

Ujawnione sekrety występowały łącznie w ponad 1,1 mln plików i repozytoriów, również w forkach. Mediana czasu publicznej ekspozycji pojedynczego sekretu wyniosła 784 dni, co pokazuje, że problem ma charakter długotrwały, a nie incydentalny.

Kontekst / historia

Problem wycieków sekretów z repozytoriów publicznych jest znany od lat, ale wraz z rozwojem DevOps, infrastruktury jako kodu i automatyzacji dostępu jego skala wyraźnie wzrosła. Deweloperzy coraz częściej pracują z tokenami do usług SaaS, kontami serwisowymi w chmurze, kluczami do narzędzi AI oraz danymi uwierzytelniającymi wykorzystywanymi w pipeline’ach.

GitHub rozwija funkcje secret scanning oraz push protection, które mają wykrywać i blokować część sekretów jeszcze przed zapisaniem ich w repozytorium. Rozwiązania te poprawiają poziom ochrony, ale nie obejmują wszystkich typów poufnych danych i nie rozwiązują problemu już istniejących wycieków zapisanych w historii commitów, tagach czy branchach.

Analiza techniczna

Badanie wykazało 543 699 unikalnych poświadczeń, które nadal działały w chwili weryfikacji. Zidentyfikowano je w ponad 1,1 mln plików i repozytoriów, a część ekspozycji wynikała z kopiowania kodu oraz obecności forków. Analiza opierała się na pełzaniu publicznych repozytoriów zakończonym 7 sierpnia 2025 r., natomiast stan aktywności sekretów odnosił się do lipca 2025 r.

Z technicznego punktu widzenia sekret raz zapisany w repozytorium może pozostawać dostępny nie tylko w aktualnej wersji pliku, ale również w historii Git, tagach, dodatkowych gałęziach oraz repozytoriach pochodnych. Oznacza to, że samo usunięcie poufnej wartości z bieżącej wersji kodu nie eliminuje ryzyka.

Istotnym ograniczeniem ochrony platformowej jest zależność od rozpoznawalnych wzorców. Mechanizmy blokujące dobrze radzą sobie z określonymi typami tokenów i kluczy partnerów objętych skanowaniem, ale znacznie gorzej wykrywają dane niestandardowe, takie jak własne sekrety aplikacyjne, connection stringi czy mniej typowe klucze usługowe.

W analizie wskazano również, że około 36,8% wszystkich wykrytych aktywnych poświadczeń zostało ujawnionych już po rozszerzeniu domyślnej ochrony push protection dla użytkowników publicznych repozytoriów. Dodatkowo 51,8% aktywnych sekretów należało do kategorii, których domyślna ochrona nie blokowała, co pokazuje granice skuteczności zabezpieczeń opartych wyłącznie na znanych sygnaturach.

Konsekwencje / ryzyko

Aktywne poświadczenia opublikowane w publicznych repozytoriach stanowią wyjątkowo praktyczny wektor ataku. Napastnik nie musi eksploitować aplikacji ani zdobywać haseł inną drogą, jeśli może przejąć ważny token umożliwiający dostęp do zasobów organizacji.

nieautoryzowany dostęp do usług chmurowych i środowisk developerskich,
kradzież danych z baz danych i magazynów obiektowych,
nadużycia finansowe wynikające z wykorzystania zasobów rozliczanych według użycia,
przejęcie lub modyfikacja procesów CI/CD,
ruch boczny do innych systemów wewnętrznych,
utrzymanie długotrwałej obecności w środowisku ofiary.

Długi czas ekspozycji zwiększa prawdopodobieństwo, że sekret został już zindeksowany przez zautomatyzowane boty skanujące publiczne repozytoria. W praktyce od publikacji do nadużycia może minąć bardzo niewiele czasu, podczas gdy wykrycie po stronie właściciela następuje często dopiero po wielu miesiącach.

Rekomendacje

Organizacje powinny traktować ochronę sekretów jako proces ciągły i wielowarstwowy, a nie pojedynczą funkcję platformy hostingowej. Skuteczny program ograniczania ryzyka powinien obejmować zarówno prewencję, jak i szybkie reagowanie.

wymuszanie rotacji poświadczeń po każdym potwierdzonym wycieku,
skanowanie całej historii Git, tagów, branchy i forków,
wdrożenie lokalnych kontroli pre-commit i pre-push na stacjach deweloperów,
rozszerzenie detekcji o niestandardowe wzorce i własne typy sekretów,
stosowanie krótkiego czasu życia poświadczeń i automatycznego wygaszania,
egzekwowanie zasady najmniejszych uprawnień,
utrzymywanie centralnego rejestru sekretów i przeglądu ich wykorzystania,
automatyczne alertowanie oraz playbooki reagowania obejmujące unieważnienie kluczy i analizę wpływu,
regularną edukację zespołów programistycznych,
okresowe audyty publicznego śladu organizacji w repozytoriach open source.

Z perspektywy architektury bezpieczeństwa najlepszym kierunkiem pozostaje ograniczanie liczby statycznych sekretów w kodzie i przechodzenie na rozwiązania oparte na federacji tożsamości, dynamicznym wydawaniu poświadczeń oraz menedżerach sekretów zintegrowanych z pipeline’ami.

Podsumowanie

Ujawnienie ponad 543 tys. nadal aktywnych poświadczeń w publicznych repozytoriach GitHub pokazuje, że secret sprawl pozostaje jednym z kluczowych zagrożeń dla bezpieczeństwa łańcucha dostaw oprogramowania. Choć secret scanning i push protection realnie ograniczają część incydentów, nie stanowią pełnego rozwiązania.

Największe ryzyko wynika z połączenia szerokiej ekspozycji, długiego czasu życia sekretów oraz niewystarczająco szybkiego ich unieważniania. Dla organizacji oznacza to konieczność wdrożenia dojrzałego programu zarządzania sekretami, obejmującego zapobieganie, wykrywanie, rotację i minimalizację uprawnień.