In der GitLab Cloud lassen sich derzeit in grossem Umfang gueltige Zugangsdaten, API-Schluessel und Tokens in oeffentlichen Repositories finden. Eine automatisierte Auswertung von 5,6 Millionen Projekten foerderte 17.430 verifizierte, noch aktive Secrets zutage, die zu mehr als 2.800 eindeutigen Domains gehoeren – ein erhebliches Risiko fuer Unternehmen, deren Infrastruktur direkt ueber diese Daten angreifbar ist.
Ausmass des GitLab-Lecks: 17.430 aktive Secrets in 5,6 Millionen Repositories
Unter den gefundenen Secrets befinden sich API-Keys, Passwoerter, Access Tokens und Verbindungs-Strings zu Datenbanken, also genau jene Informationen, die in professionellen Umgebungen ausschliesslich in dedizierten Secret-Managern liegen sollten. Auffaellig ist dabei nicht nur die absolute Zahl, sondern auch die Dichte der Leaks.
Im Vergleich zu einer frueheren Untersuchung von Bitbucket (2,6 Millionen Repositories, 6.212 gefundene Secrets) zeigt sich: Die Leck-Dichte – also Secrets pro Repository – ist in GitLab um rund 35 % hoeher. Dies deutet auf systematische Schwaechen beim Secrets Management in GitLab-basierten Workflows hin und spiegelt einen generellen Trend in DevOps-Umgebungen wider, in denen Geschwindigkeit oftmals vor Sicherheit priorisiert wird.
Methodik: Automatisiertes GitLab-Scanning mit TruffleHog und AWS
Zur Identifikation der exponierten Zugangsdaten kam das Open-Source-Werkzeug TruffleHog zum Einsatz. Dieses Tool durchsucht sowohl die Git-Historie als auch die aktuelle Dateistruktur nach Mustern, die auf API-Schluessel, Tokens und andere Secrets hinweisen. Damit lassen sich nicht nur aktuelle Commits, sondern auch versehentlich eingecheckte, spaeter wieder geloeschte Dateien aufspueren.
Skalierung ueber AWS: SQS und Lambda im Einsatz
Um mehrere Millionen GitLab-Repositories effizient zu scannen, wurde eine vollautomatisierte Cloud-Architektur aufgebaut. Ein Python-Skript rief ueber das GitLab-Public-API sukzessive alle Projekt-IDs ab und stellte diese als Aufgaben in eine AWS Simple Queue Service (SQS)-Warteschlange.
Fuer jedes Repository startete eine AWS-Lambda-Funktion, die TruffleHog ausfuehrte, das Projekt scannte und die Funde protokollierte. Das komplette Scanning dauerte etwas mehr als 24 Stunden und verursachte Cloud-Kosten von lediglich rund 770 US‑Dollar. Damit wird deutlich, dass ein Massen-Scan oeffentlicher Repositories laengst kein exklusives Werkzeug staatlicher Akteure mehr ist, sondern auch fuer finanziell schwach ausgestattete Angreifer realistisch ist.
Welche Zugangsdaten betroffen sind: Von GCP bis Telegram-Bots
Die Mehrzahl der Secrets stammt aus der Zeit ab 2018. Besonders kritisch: Es wurden sogar Schluessel aus dem Jahr 2009 gefunden, die nach wie vor gueltig waren. Solche Alt-Schluessel sind haeufig mit Legacy-Systemen verknuepft, die nur unzureichend ueberwacht und selten gehardet werden – ein ideales Ziel fuer Angreifer.
Top-Kategorien der exponierten Secrets
Die Analyse der Funde zeigt deutliche Schwerpunkte bei konkreten Plattformen und Diensten. Am haeufigsten waren Google Cloud Platform (GCP)-Credentials betroffen, insgesamt mehr als 5.200 Faelle. Daneben fanden sich unter anderem:
– Zugangsdaten und Connection Strings fuer MongoDB-Datenbanken;
– Tokens fuer Telegram-Bots, die etwa fuer Phishing, Spam oder Kontouebernahmen missbraucht werden koennen;
– API-Schluessel von OpenAI und anderen KI-Plattformen, die unautorisierte Nutzung und erhebliche Kosten verursachen koennen;
– ueber 400 Secrets, die direkt GitLab-Services zugeordnet sind.
In Kombination reichen solche Informationen oft aus, um komplette Cloud-Umgebungen zu kompromittieren: von unbefugtem Zugriff auf produktive Datenbanken und Storage-Buckets bis hin zur Manipulation von CI/CD-Pipelines oder dem Versand glaubwuerdiger Phishing-Nachrichten ueber legitime Bots.
Reaktion der Unternehmen und Rolle von Bug-Bounty-Programmen
Angesichts von 2.804 betroffenen Domains ist eine manuelle Kontaktaufnahme praktisch unmoeglich. Deshalb wurden Websuche, Python-Skripte und automatisierte Textgenerierung mit einem Sprachmodell (Claude Sonnet 3.7) eingesetzt, um Benachrichtigungen zu erstellen und zu versenden.
Viele Organisationen reagierten zeitnah, zogen exponierte Schluessel zurueck und ersetzten sie. Ein Teil der Meldungen wurde im Rahmen von Bug-Bounty-Programmen eingereicht, was zusammengenommen rund 9.000 US‑Dollar an Praemien einbrachte. Dennoch sind zahlreiche Secrets weiterhin oeffentlich abrufbar. Das bestaetigt Erkenntnisse unter anderem aus dem Verizon Data Breach Investigations Report, wonach kompromittierte Zugangsdaten einer der zentralen Angriffsvektoren bleiben.
Ursachen und Gegenmassnahmen: Technische und organisatorische Defizite
Die Funde in GitLab, aehnliche Analysen zu Bitbucket und Leaks in oeffentlichen Datensaetzen wie Common Crawl zeigen: Die Kernursache ist weniger ein technischer Fehler der Plattform, sondern unzureichende Prozesse und Schulungen rund um Secrets Management in Entwicklungs- und DevOps-Teams.
Bewaehrte Sicherheitspraktiken umfassen insbesondere: 1) Kein Speichern von Secrets im Quellcode – stattdessen Nutzung von Secret-Managern wie Cloud-eigenen Key Stores oder HashiCorp Vault; 2) automatisiertes Scanning von Repositories mit Tools wie TruffleHog, Gitleaks oder aehnlichen Loesungen, integriert in CI/CD-Pipelines vor dem Merge; 3) konsequente, kurzzyklische Rotation von Schluesseln und Tokens, um den Schaden bei einem Leak zu begrenzen; 4) wiederkehrende Schulungen fuer Entwicklerinnen und Entwickler, damit Sicherheitsrichtlinien auch in experimentellen und Prototyping-Phasen eingehalten werden.
Die aktuellen Erkenntnisse aus der GitLab-Cloud machen deutlich, dass professionelles Secrets Management zu einer Kernaufgabe jeder Entwicklungsorganisation werden muss. Unternehmen, die Cloud-Plattformen, Datenbanken und externe APIs einsetzen, sollten ihre DevOps- und DevSecOps-Prozesse zeitnah ueberpruefen, automatisierte Geheimnis-Scans etablieren und robuste Verfahren fuer die schnelle Deaktivierung und Erneuerung von Zugangsdaten definieren. Wer diese Hausaufgaben jetzt angeht, reduziert signifikant das Risiko, in kuenftigen Berichten ueber oeffentliche Secrets-Leaks namentlich aufzutauchen.
