Öffentlicher GitHub-Code enthielt weiterhin 543.699 gültige Zugangsdaten

Truffle Security identifizierte 543.699 eindeutige Zugangsdaten in öffentlichen GitHub-Repositories. Bei Tests Ende Juli 2026 wurden sie von den Diensten, die sie ausgestellt hatten, weiterhin akzeptiert.

Das Ergebnis macht eine Lücke deutlich: Ein veröffentlichtes Geheimnis zu erkennen, bedeutet nicht, es unbrauchbar zu machen. API-Schlüssel, Zugangsdaten für Dienstkonten, Tokens und Datenbank-Verbindungszeichenfolgen können weiterhin Zugriff gewähren, bis der Inhaber oder der Diensteanbieter sie ändert oder widerruft.

Für die Analyse wurde ein Datensatz verwendet, der zum Training großer Sprachmodelle zusammengestellt worden war. Laut dem Bericht von BleepingComputer über die Untersuchung umfasste der zugrunde liegende Crawl 224 Millionen Repositories und mehr als 58 Milliarden Dateien, bevor er am 7. August 2025 abgeschlossen wurde.

SecurityWeek zufolge fand der Scan insgesamt 1.103.438 offengelegte Zugangsdaten. Truffle stellte anschließend fest, dass davon 543.699 noch aktiv waren. Untersucht wurden die öffentliche Offenlegung und die fortbestehende Gültigkeit – nicht, ob Angreifer die einzelnen Zugangsdaten entdeckt oder missbraucht hatten.

Manche Zugangsdaten waren jahrelang öffentlich zugänglich

Ein eindeutiges Zugangsdaten-Element war im Median 784 Tage lang öffentlich zugänglich. Rund 10 % der noch gültigen Zugangsdaten waren älter als 6,3 Jahre, ein Viertel der gefundenen Zugangsdaten älter als vier Jahre.

Manche waren noch deutlich älter. Truffle fand 2.636 aktive Zugangsdaten in Dateien, die zuletzt vor 2015 geändert worden waren. Das älteste Beispiel war laut SecurityWeek ein 2009 committeter AWS-Schlüssel, der danach nicht mehr angerührt wurde.

Diese Zahlen zeigen, dass historischer Code ein zentraler Teil des Problems ist. Truffle fand Zugangsdaten in mehr als 1,1 Millionen Dateien und Repositories, darunter auch Kopien in Forks. Ein Geheimnis aus der aktuellen Projektversion zu entfernen, beseitigt es daher nicht zwangsläufig an allen Stellen, an denen es auftauchte.

Auch durch das Löschen wird das zugrunde liegende Zugangsmittel nicht widerrufen. Akzeptiert der ausstellende Dienst weiterhin den ursprünglichen Wert, kann eine Kopie aus einer früher öffentlich zugänglichen Datei oder einem Repository nach wie vor funktionieren.

Die Dichte gültiger Zugangsdaten nahm im Untersuchungszeitraum zu. 2015 verzeichnete Truffle 3,72 aktive Zugangsdaten pro einer Million Dateien. 2025 erreichte die Zahl mit 11,62 pro einer Million Dateien ihren Höchststand.

Die Ergebnisse für GitHub übertrafen auch die einer früheren Analyse von Truffle zu Hugging Face. Bei diesem Scan wurden 221.303 noch gültige Zugangsdaten gefunden – weniger als die Hälfte der für den GitHub-Datensatz gemeldeten Zahl.

Die Gültigkeit variierte je nach Art der Zugangsdaten erheblich

Wie wahrscheinlich es war, dass ein offengelegtes Geheimnis noch funktionierte, hing stark von der Kategorie und dem ausstellenden Dienst ab.

Von 126.963 offengelegten Zugangsdaten für Google-Cloud-Dienstkonten waren 69.041 noch gültig. SecurityWeek bezeichnete dies als die größte aufgeführte Kategorie aktiver Zugangsdaten. Zu den weiteren gemeldeten Kategorien gehörten:

• 51.067 aktive MongoDB-Verbindungszeichenfolgen
• 33.343 gültige Google-API-Schlüssel
• Ein gültiges npm-Token von 101.886 committeten npm-Tokens

Die npm-Zahl steht in starkem Kontrast zu den übrigen Kategorien. Fast alle committeten npm-Tokens im Datensatz funktionierten nicht mehr. Zehntausende Zugangsdaten für Google Cloud, MongoDB-Verbindungszeichenfolgen und Google-API-Schlüssel wurden dagegen weiterhin akzeptiert.

Die Widerrufspraxis der Anbieter entscheidet mit darüber, wie lange eine Offenlegung gefährlich bleibt. GitHub kann bestimmte Geheimnisse erkennen oder melden, aber Zugangsdaten, die ein anderer Dienst ausgestellt hat, nicht selbstständig ungültig machen.

Die Berichte enthalten keine Angaben zu den Zugriffsrechten der einzelnen gültigen Zugangsdaten. Die Zahl von 543.699 lässt sich daher nicht mit der Anzahl kompromittierter Konten, Systeme oder Cloud-Umgebungen gleichsetzen. Jedes Geheimnis ermöglicht nur den Zugriff auf die Ressourcen und Berechtigungen, die ihm zugewiesen wurden – und diese können stark variieren.

Dennoch eröffnet die fortbestehende Gültigkeit die Möglichkeit eines unbefugten Zugriffs. Ein öffentlich zugängliches Zugangsmittel muss nicht technisch umgangen werden, wenn der entsprechende Dienst es weiterhin akzeptiert.

Push Protection verringerte die Offenlegung nur im abgedeckten Bereich

GitHubs Push Protection durchsucht eingehenden Code nach bekannten Mustern für Geheimnisse, etwa API-Schlüsseln und Zugriffstokens. Erkennt die Funktion ein unterstütztes Geheimnis, kann sie den Push blockieren, bevor die Zugangsdaten öffentlich werden.

BleepingComputer zufolge wurde die Funktion im April 2022 für Advanced-Security-Nutzer eingeführt und im Mai 2023 für öffentliche Repositories verfügbar gemacht. Außerdem heißt es dort, GitHub habe Push Protection im Februar 2024 für alle Nutzer aktiviert. Eine weitere Beschreibung der Einführung im selben Bericht stimmt mit diesen Zeitangaben nicht ganz überein.

Truffle teilte die aktiven Zugangsdaten in drei Gruppen ein:

• 245.959 waren bereits vor der Einführung kostenloser Warnungen zum Secret-Scanning vorhanden.
• 97.897 tauchten auf, als der Scan kostenlos war, Push Protection aber noch nicht standardmäßig aktiviert war.
• 199.843 wurden offengelegt, nachdem die Blockierung zum Standard geworden war.

Die letzte Gruppe machte rund 36,8 % aller aktiven Zugangsdaten aus. Fast 200.000 Zugangsdaten, die während des Zeitraums mit standardmäßiger Blockierung veröffentlicht wurden, wurden bei Truffles Tests folglich noch akzeptiert.

Das bedeutet nicht, dass die Schutzmaßnahme wirkungslos war. Bei den von Push Protection abgedeckten Kategorien sank die Offenlegungsrate um 53 %, nachdem die Funktion standardmäßig aktiviert worden war. Dieser Rückgang gilt nur für geschützte Kategorien, nicht für die Offenlegung von Zugangsdaten insgesamt.

Die Abdeckung ist eine wesentliche Einschränkung. BleepingComputer zufolge entfielen 51,8 % der gültigen Zugangsdaten auf Kategorien, die von GitHubs standardmäßiger Push Protection nicht blockiert wurden – darunter Datenbank-Verbindungszeichenfolgen und Google-API-Schlüssel.

Push Protection greift außerdem bei neuen Versuchen, unterstützte Geheimnisse zu veröffentlichen. Zugangsdaten, die bereits offengelegt wurden, bevor die Schutzmaßnahme eingriff, werden dadurch nicht widerrufen.

Warnungen zu Geheimnissen erfordern weiterhin Maßnahmen von Inhabern und Anbietern

GitHub betreibt ein Secret-Scanning-Programm, das offengelegte Tokens an die Dienste meldet, die sie ausgestellt haben. Die Anbieter sind jedoch nicht verpflichtet, die gemeldeten Zugangsdaten zu widerrufen.

Truffle führt die fortbestehende Offenlegung teilweise darauf zurück, dass manche Anbieter möglicherweise kein Verfahren zum Ungültigmachen geleakter Tokens haben. Wie SecurityWeek in seiner Berichterstattung zu den Ergebnissen beschreibt, hängen auch nachträgliche Warnungen davon ab, dass Repository-Inhaber sie aktivieren, die Ergebnisse prüfen und die betroffenen Zugangsdaten ändern.

Die Behebung kann an mehreren Stellen ins Stocken geraten:

1. GitHub oder ein anderer Scanner muss die Zugangsdaten erkennen.
2. Eine Warnung muss den Repository-Inhaber oder den ausstellenden Anbieter erreichen.
3. Jemand muss den Fund bewerten.
4. Die offengelegten Zugangsdaten müssen widerrufen oder geändert werden.

Die Erkennung allein macht Zugangsdaten nicht unbrauchbar. Die Zeichenfolge aus dem sichtbaren Code zu entfernen, ohne sie ungültig zu machen, hat dieselbe Einschränkung.

Auch die Ergebnisse selbst müssen sorgfältig eingeordnet werden. Truffle bestätigte, dass die Zugangsdaten offengelegt worden und noch gültig waren. Die Untersuchung stellte jedoch nicht fest, welcher Anteil gestohlen oder von Angreifern missbraucht worden war.

Zugangsdaten ändern und historische Inhalte durchsuchen hat Vorrang

Truffles Empfehlungen beginnen mit der sofortigen Änderung offengelegter Zugangsdaten. Unternehmen sollten eine Veröffentlichung im Internet als Vorfall im Lebenszyklus von Zugangsdaten behandeln – nicht nur als Aufgabe zur Bereinigung des Codes.

Betroffene Teams sollten:

1. Offengelegte Zugangsdaten sofort ändern. Der veröffentlichte Wert muss beim ausstellenden Dienst ungültig werden.
2. Geheimnisse aus Repositories entfernen. Dadurch wird ihre weitere Sichtbarkeit eingeschränkt, ein Widerruf ist damit aber nicht ersetzt.
3. Die Repository-Historie durchsuchen. Wer nur die aktuelle Version prüft, kann Zugangsdaten in älteren Dateien oder Commits übersehen.
4. Automatischen Ablauf einrichten. Zeitlich begrenzte Geheimnisse verkürzen den Zeitraum, in dem ein übersehenes Zugangsmittel verwendet werden kann.
5. Push Protection und Warnungen zum Secret-Scanning nutzen. Diese Maßnahmen können unterstützte Geheimnisse blockieren oder erkennen, müssen aber in einen funktionierenden Prozess zur Änderung von Zugangsdaten eingebunden sein.

Bei Repository-Prüfungen sollten Teams auch Forks und wiederholte Kopien berücksichtigen, die im Rahmen einer Untersuchung gefunden wurden. Zudem sollten sie die relevanten Anbieterprotokolle auf Aktivitäten mit den offengelegten Zugangsdaten untersuchen. Aus den aggregierten Untersuchungsergebnissen lässt sich nicht ableiten, ob Geheimnisse eines bestimmten Unternehmens missbraucht wurden.

In den beiden veröffentlichten Berichten sind weder die Werte der Zugangsdaten noch die URLs der betroffenen Repositories aufgeführt. Unternehmen müssen daher ihren eigenen öffentlichen Code, die Repository-Historie und ihre Verzeichnisse für Zugangsdaten prüfen, statt auf eine vollständige Liste offengelegter Geheimnisse zu warten.

Das zentrale Problem besteht nicht nur darin, dass Entwickler sensible Werte committet haben. Es besteht auch darin, dass Hunderttausende dieser Werte weiterhin gültig waren – teilweise noch Jahre, nachdem sie erstmals öffentlich zugänglich geworden waren.