Wprowadzenie do problemu / definicja luki
Najnowsze badanie przeprowadzone z użyciem otwarto-źródłowego skanera TruffleHog wykazało, iż w publicznych repozytoriach GitLab Cloud znajdują się 17 430 zweryfikowane, wciąż działające sekrety (m.in. klucze API, tokeny dostępu, hasła). Dane te pochodzą z pełnego skanu ~5,6 mln publicznych repozytoriów, a sekrety zmapowano do ponad 2,8 tys. unikalnych domen.
W skrócie
- 5,6 mln publicznych repozytoriów GitLab → 17 430 aktywnych sekretów; koszt skanu ~770 USD; czas ~24 h (architektura AWS Lambda + SQS).
- Najczęściej wyciekały klucze GCP, dalej m.in. MongoDB, Telegram bot tokens, OpenAI; znaleziono też >400 kluczy GitLab.
- GitLab ma wbudowane mechanizmy Secret Detection (push protection, skanowanie w pipeline’ach, klient-side), a część sekretów może być automatycznie unieważniana.
Kontekst / historia / powiązania
Badanie jest drugą częścią serii o wyciekach sekretów z głównych platform Git. Wcześniej ten sam badacz przeskanował publiczne repozytoria Bitbucket (2,6 mln repo), gdzie potwierdził 6 212 działających sekretów. Porównanie wskazuje, iż gęstość sekretów na GitLab jest o ok. 35% wyższa niż na Bitbucket.
Analiza techniczna / szczegóły luki
Autor wykorzystał publiczne API GitLab do enumeracji wszystkich publicznych projektów i zbudował bezserwerową kolejkę skanów: nazwy repo trafiały do AWS SQS, a równoległe funkcje AWS Lambda uruchamiały TruffleHog i zapisywały wyniki. Taki model pozwolił przeskanować 5,6 mln repozytoriów w ~24 godziny przy koszcie ok. 770 USD.
Wybrane obserwacje z wyników:
- Rodzaje sekretów: dominacja kluczy GCP, dalej m.in. łańcuchy połączeń MongoDB, tokeny Telegram i klucze OpenAI; wykryto także setki tokenów GitLab.
- „Zombie secrets”: działające poświadczenia sprzed ponad dekady (rekordowo od 2009 r.), co potwierdza, iż sekrety nie „wygasają” same — trzeba je rotować i unieważniać.
- Automatyzacja powiadomień: do zgłoszeń wykorzystano templaty i generowanie e-maili; część organizacji zareagowała, ale nie wszystkie.
Praktyczne konsekwencje / ryzyko
Ujawnione sekrety w repozytorium eskalują ryzyko:
- Przejęcie zasobów chmurowych (np. GCP/AWS/Azure), kradzież danych i kosztowne nadużycia rozliczeń.
- RCE / pivoting przez dostęp do wewnętrznych usług (bazy, kolejki, webhooki).
- Przejęcie kont i supply chain (np. publikacja paczek, manipulacja pipeline’ami).
- Automatyczne skanery i grupy przestępcze monitorują publiczne Gity pod kątem świeżych sekretów; czas do nadużycia bywa liczony w minutach.
Rekomendacje operacyjne / co zrobić teraz
- Włącz Secret Detection w GitLab w trzech warstwach:
- Push protection (blokuje push z sekretami).
- Pipeline secret detection (skany w CI/CD + historyczny skan po włączeniu).
- Client-side scanning (opisy MR/issue).
- Zrób historyczny skan istniejących repozytoriów (jednorazowo po włączeniu), a potem skany ciągłe na gałęziach/MR.
- Natychmiastowa remediacja: każdy wykryty sekret unieważnij/rotuj, przejrzyj logi użycia, poszukaj nadużyć; dla tokenów GitLab — revoke + przegląd aktywności.
- Sekrety trzymaj poza Git: menedżery sekretów (GCP Secret Manager, AWS KMS, HashiCorp Vault), zmienne CI/CD, szablony środowiskowe zamiast .env w repo.
- Domyślna prywatność: ustaw prywatność grup/projektów jako private i ogranicz widoczność, szczególnie dla forka/archiwów.
- Reguły i polityki: wymuś skanowanie i blokowanie pushy politykami bezpieczeństwa; utrzymuj niestandardowe reguły (np. własne formaty tokenów).
- Higiena developerów: pre-commit hooks (np. trufflehog, gitleaks), szkolenia, monitorowanie shadow IT (prywatne repozytoria devów, gisty).
Różnice / porównania z innymi przypadkami
Na tle badania Bitbucket, GitLab ma 2,1× więcej publicznych repozytoriów, a liczba zweryfikowanych sekretów jest 2,8× większa, co przekłada się na ~35% większą gęstość sekretów per repo. To potwierdza, iż problem nie jest specyficzny dla jednej platformy, ale jego skala i profil sekretów różnią się między ekosystemami.
Podsumowanie / najważniejsze wnioski
- Publiczne repozytoria to magnes na wycieki — także wieloletnie, wciąż aktywne sekrety.
- Nawet dojrzałe platformy (GitLab) mają luki „procesowe”: brak rotacji, brak blokad push, brak skanów historycznych.
- Warstwowa obrona (push protection + CI/CD + klient + rotacja + polityki) drastycznie obniża ryzyko i koszt incydentów.
Źródła / bibliografia
- BleepingComputer: Public GitLab repositories exposed more than 17,000 secrets (28 listopada 2025). (BleepingComputer)
- Truffle Security (Luke Marshall): Scanning 5.6 million public GitLab repositories for secrets (25 listopada 2025). (trufflesecurity.com)
- GitLab Docs: Secret detection (funkcje, automatyczne unieważnianie). (GitLab Docs)
- GitLab Docs: Pipeline secret detection (włączanie, historyczne skany, polityki). (GitLab Docs)
- GitLab Blog: Best practices to keep secrets out of GitLab repositories. (about.gitlab.com)
