Wprowadzenie do problemu / definicja
Ujawnianie poświadczeń w publicznych repozytoriach kodu pozostaje jednym z najpoważniejszych zagrożeń dla bezpieczeństwa aplikacji, środowisk chmurowych i usług opartych na sztucznej inteligencji. Problem dotyczy m.in. kluczy API, tokenów dostępowych, par AccessKey oraz innych sekretów, które po publikacji mogą zostać przejęte i wykorzystane przez osoby nieuprawnione.
Najnowsza analiza publicznych repozytoriów w serwisie Gitee pokazuje, że skala tego zjawiska jest alarmująca. W toku badania wykryto dziesiątki tysięcy poświadczeń, które pozostawały aktywne w chwili weryfikacji, co oznacza realne i natychmiastowe ryzyko nadużyć.
W skrócie
Badacz bezpieczeństwa przeanalizował około 7,25 mln publicznych repozytoriów Gitee i zidentyfikował 26 400 unikalnych, nadal działających poświadczeń. Wśród nich znalazły się klucze do usług chmurowych oraz platform AI, w tym Alibaba Cloud, YouTube API, DeepSeek, Zhipu BigModel i OpenAI.
Kluczowe znaczenie ma fakt, że analiza objęła również historię commitów. To oznacza, że samo usunięcie sekretu z aktualnej wersji kodu nie eliminuje zagrożenia, jeśli wcześniej został on zapisany w historii repozytorium.
Kontekst / historia
Wycieki sekretów z platform hostujących kod nie są nowym problemem. Od lat zespoły bezpieczeństwa obserwują przypadki przypadkowego publikowania kluczy API, danych dostępowych do chmury, tokenów CI/CD czy poświadczeń do baz danych w ogólnodostępnych projektach.
Ryzyko wzrosło wraz z popularyzacją architektury cloud-native, automatyzacji DevOps i gwałtownym wzrostem wykorzystania usług generatywnej AI. Każdy kolejny system, integracja i pipeline zwiększa liczbę sekretów używanych przez organizacje, a tym samym powierzchnię potencjalnego wycieku.
W tym przypadku uwaga badaczy skupiła się na platformie Gitee, szeroko wykorzystywanej w chińskim ekosystemie deweloperskim. Wyniki wskazują, że problem ma charakter systemowy, a ekspozycja danych uwierzytelniających dotyczy zarówno nowych projektów, jak i starszych commitów obecnych w historii Git.
Analiza techniczna
Badanie przeprowadzono z użyciem dwóch narzędzi do wykrywania sekretów: TruffleHog oraz Kingfisher. Skanery analizowały pełną historię commitów repozytoriów, a następnie weryfikowały znalezione poświadczenia pod kątem ich aktywności poprzez sprawdzenie, czy są nadal akceptowane przez usługi docelowe.
Taka metoda ma istotną przewagę operacyjną. Pozwala ograniczyć liczbę fałszywych alarmów i odróżnić przypadkowe ciągi znaków od rzeczywistych, działających kluczy, które mogą zostać użyte do uzyskania dostępu do zasobów.
Wśród wykrytych danych znalazły się między innymi:
- 9 473 pary AccessKey dla Alibaba Cloud,
- 3 805 kluczy YouTube API,
- 3 170 kluczy DeepSeek,
- 1 489 kluczy platformy BigModel od Zhipu,
- 1 348 kluczy OpenAI.
W mniejszych liczbach wykryto również poświadczenia związane z GitHub, AWS, Google Cloud i Gemini. Szczególne obawy budzi informacja o aktywnym poświadczeniu administracyjnym powiązanym z dużą platformą AI klasy enterprise.
Wpływ takiego wycieku zależy od zakresu uprawnień konkretnego klucza. W środowiskach chmurowych może to oznaczać możliwość tworzenia i usuwania zasobów, odczytu danych, modyfikacji konfiguracji IAM, uruchamiania instancji czy generowania niekontrolowanych kosztów. W usługach AI zagrożenie obejmuje nieautoryzowane użycie API, zużycie budżetu, zakłócenie działania aplikacji oraz potencjalny dostęp do danych przesyłanych przez interfejsy programistyczne.
Istotnym wnioskiem z analizy są także różnice między wynikami obu skanerów. Każde narzędzie wykrywało znaczną część sekretów, ale ich wspólny zbiór był ograniczony. W praktyce oznacza to, że organizacje polegające tylko na jednym silniku detekcji mogą nie zauważyć pełnej skali wycieków.
Konsekwencje / ryzyko
Skutki ujawnienia aktywnych poświadczeń mogą być wielowymiarowe. Na poziomie finansowym oznaczają ryzyko wysokich kosztów związanych z wykorzystaniem usług API, modeli AI, zasobów obliczeniowych oraz transferu danych. W przypadku płatnych platform AI nawet krótkotrwałe nadużycie może wygenerować znaczące obciążenia.
Na poziomie operacyjnym wyciek może prowadzić do przerw w działaniu usług, wyczerpania limitów, degradacji dostępności aplikacji i zakłócenia procesów biznesowych. W szerszym ujęciu może również utrudnić reagowanie na incydenty, jeśli atakujący uzyska dostęp do logów, konfiguracji lub narzędzi administracyjnych.
Najpoważniejsze konsekwencje dotyczą jednak poufności i integralności. Klucz o szerokich uprawnieniach może umożliwić dostęp do danych klientów, artefaktów budowy oprogramowania, zasobów obiektowych, kolejek komunikatów czy konfiguracji środowiska produkcyjnego. W skrajnym scenariuszu taki wyciek może stać się punktem wejścia do kompromitacji łańcucha dostaw oprogramowania.
Dodatkowe zagrożenie wynika z automatyzacji ataków. Publiczne repozytoria są stale monitorowane przez boty wyszukujące klucze i tokeny, dlatego czas między publikacją sekretu a jego wykorzystaniem może być bardzo krótki.
Rekomendacje
Najważniejsza zasada brzmi: każdy sekret, który kiedykolwiek trafił do publicznego repozytorium, należy traktować jako skompromitowany. Samo usunięcie go z kodu nie jest wystarczające. Konieczna jest natychmiastowa rotacja lub unieważnienie poświadczenia oraz przegląd logów, kosztów i aktywności administracyjnej.
Organizacje powinny wdrożyć następujące środki ochronne:
- obowiązkowe skanowanie sekretów przed każdym push oraz w pipeline CI/CD,
- regularne skanowanie pełnej historii Git, a nie tylko bieżącej gałęzi,
- przechowywanie poświadczeń wyłącznie w menedżerach sekretów i bezpiecznych zmiennych środowiskowych,
- stosowanie zasady najmniejszych uprawnień,
- używanie odrębnych kluczy dla poszczególnych projektów, zespołów i środowisk,
- konfigurację limitów kosztowych, alertów budżetowych i progów wykorzystania API,
- monitoring wykorzystania kluczy, w tym analiza anomalii, geolokalizacji i wzorców czasowych,
- regularne szkolenia deweloperów z zakresu bezpiecznego zarządzania sekretami,
- stosowanie więcej niż jednego narzędzia do wykrywania sekretów w środowiskach wielochmurowych i AI.
Z perspektywy reagowania na incydenty warto posiadać gotową procedurę obejmującą identyfikację zakresu wycieku, rotację poświadczeń, analizę potencjalnych nadużyć, ocenę wpływu na dane oraz działania naprawcze.
Podsumowanie
Przypadek 26 400 aktywnych poświadczeń ujawnionych w publicznych repozytoriach Gitee pokazuje, że wyciek sekretów nadal pozostaje jednym z najbardziej niedocenianych i jednocześnie najłatwiejszych do wykorzystania wektorów ataku. Problem dotyczy nie tylko pojedynczych deweloperów, ale całych procesów wytwarzania oprogramowania, zarządzania tożsamością maszynową oraz nadzoru nad środowiskami chmurowymi i AI.
Najważniejszy wniosek jest jednoznaczny: sekret opublikowany publicznie należy uznać za utracony. Skuteczna obrona wymaga połączenia mechanizmów prewencyjnych, automatycznej detekcji, szybkiej rotacji poświadczeń i stałego monitoringu użycia kont oraz usług.
Źródła
- The Hacker News — https://thehackernews.com/2026/10/26400-valid-cloud-and-ai-credentials.html
- YouTube Data API Overview — https://developers.google.com/youtube/data/getting-started
- Keeping your OpenAI account secure — https://help.openai.com/en/articles/8304786-keeping-your-openai-account-secure
- Alibaba Cloud AccessKey leak emergency response plan — https://help.aliyun.com/
- Truffle Security blog on secret exposure in Git history — https://trufflesecurity.com/blog/removing-secrets-from-git-does-not-revoke-them