Ein Entwickler entfernt den API-Schlüssel aus einer Beispieldatei, der aktuelle Branch ist sauber, das Ticket wird geschlossen. Für das Unternehmen sollte das nicht als Sicherheitsnachweis reichen. Die entscheidende Frage lautet: Akzeptiert der betreffende Dienst den alten Schlüssel noch? Wer Repository-Bereinigung und Berechtigungsentzug verwechselt, beendet möglicherweise nur die sichtbare Spur des Problems.
Eine am 28. Oktober 2026 veröffentlichte Untersuchung liefert dafür einen aktuellen Anlass. Ben Zimmermann berichtet auf dem MongoDB-Blog über 26.400 unterschiedliche, beim Scan erfolgreich validierte Zugangsdaten in 7.256.531 öffentlichen Gitee-Repositories. The Hacker News griff die Ergebnisse am 29. Oktober auf. Es geht nicht um eine neu entdeckte Schwachstelle der Hosting-Plattform, sondern um öffentlich abgelegte Cloud- und KI-Zugänge. [1][2]
Was die Untersuchung tatsächlich zeigt
Zwei Scanner prüften die Git-Historie und validierten Kandidaten gegen Anbieter-APIs. Der etwa einmonatige Lauf ist nicht exakt datiert: Gültigkeit gilt für den Prüfzeitpunkt. MongoDB entwickelte den Gastbeitrag mit seinem Kingfisher-Team. [1]
Zu den gemeldeten Funden gehören 9.473 Alibaba-Cloud-Zugangspaare, 3.170 DeepSeek-Schlüssel und 1.348 OpenAI-Schlüssel. Die Widerrufung war bei Veröffentlichung nicht bestätigt. Der Forscher kontaktierte Anbieter mit besonders vielen Funden, jedoch nicht jeden betroffenen Entwickler. Ein erfolgreicher Zugriff durch unbefugte Dritte wird damit nicht nachgewiesen. [1][2]
Für Unternehmen ist die sinnvolle Reaktion daher weder Entwarnung noch die Annahme eines bereits bewiesenen Einbruchs. Ein zuordenbarer Fund sollte einen kontrollierten Identitätsvorfall auslösen: Verantwortlichkeit klären, Zugang entziehen, Auswirkungen untersuchen und den Abschluss belegen.
Technische Details: Erkennung, Gültigkeit und Reichweite trennen
Ein Secret-Scanner kann mehrere unterschiedliche Fragen beantworten. Zunächst erkennt er Zeichenfolgen und Kontext, die auf Zugangsdaten hindeuten. Eine anschließende Live-Prüfung untersucht, ob der Anbieter sie akzeptiert. Erst eine weitere Berechtigungsanalyse klärt, welche Identität und Ressourcen dahinterstehen. Kingfisher beschreibt diese Stufen ausdrücklich als Erkennen, Validieren, Reichweite zuordnen, Bewerten und Widerrufen. [3]
Diese Trennung sollte sich im internen Befundmodell wiederfinden. Ein Ticket braucht nicht nur Dateipfad und Trefferklasse, sondern auch Prüfstatus, Prüfzeitpunkt, zuständiges Team und identifizierte Umgebung. Ein ungeprüfter Kandidat ist kein bestätigter Zugang; ein bestätigter Zugang ist noch keine vollständige Aussage über administrative Rechte oder Datenabfluss.
Auch ein negativer Scan ist erklärungsbedürftig. Für die eigene Werkzeugauswahl empfiehlt sich eine Abdeckungsmatrix: Welche tatsächlich eingesetzten Cloud-, Modell- und Entwicklerdienste werden erkannt? Welche Tokenvarianten fehlen? Wird die Historie einbezogen? Die geringe Trefferüberschneidung in der Untersuchung unterstreicht diese Abdeckungsfrage. [1] Für die Beschaffung sollte deshalb ein Testkorpus aus eigenen, künstlichen Beispielen vorgesehen werden. Dessen Erfolgskriterium wäre nicht die größte Zahl an Warnungen, sondern nachvollziehbare Erkennung der relevanten Zugangsarten ohne echte Produktivschlüssel.
Live-Validierung sollte ausschließlich im freigegebenen Untersuchungsumfang erfolgen. Unternehmen sollten dafür dokumentieren, welche Anbieteranfragen erlaubt sind und welche Daten das Prüfverfahren verarbeitet. Fremde öffentliche Schlüssel eigenständig auszuprobieren, ist keine notwendige Voraussetzung für eine sichere interne Bestandsaufnahme.
Branchenkontext: Nicht die Plattform ist die Sicherheitsgrenze
Die praktische Lehre sollte nicht auf „Gitee vermeiden“ verkürzt werden. Entscheidend ist, ob das Unternehmen alle Orte kennt, an denen eigene Entwicklungsartefakte veröffentlicht werden dürfen. Dazu gehören aus Governance-Sicht auch Spiegel, Dienstleisterprojekte, ehemalige Demonstratoren und persönliche Konten mit dienstlichem Code.
Ein sinnvoller Inventarisierungsauftrag lautet deshalb: Jede produktive technische Identität muss einen Besitzer, einen Verwendungszweck und einen vorgesehenen Speicherort haben. Öffentliche Veröffentlichungsorte sollten diesem Inventar gegenübergestellt werden. Ohne diese Zuordnung landet ein Fund leicht beim falschen Team oder bleibt zwischen Entwicklung, Cloud-Betrieb und Security liegen.
OWASP empfiehlt zentralisiertes und standardisiertes Secrets-Management, fein abgestufte Zugriffsrechte sowie die Verwaltung des gesamten Lebenszyklus. Dazu gehören Rotation, Widerruf, Ablauf und Auditierung. Ein Tresor allein ersetzt diese Abläufe nicht: Auch sein Inhalt braucht begrenzte Zugriffsrechte und einen handhabbaren Notfallprozess. [4]
Konkrete Implikationen für Unternehmen
Erstens: Den betroffenen Zugang am Anbieter absichern. Bei einem glaubhaft zugeordneten öffentlichen Secret sollte Incident Response den Widerruf oder Austausch veranlassen. GitHub empfiehlt ausdrücklich, offengelegte Zugangsdaten zuerst zu widerrufen beziehungsweise zu rotieren. Das Umschreiben der Historie ist davon getrennt; Kopien und Forks können weiterhin alte Inhalte enthalten. [5]
Für den Betrieb empfiehlt sich eine vorbereitete Entscheidung zwischen sofortiger Sperre und eng koordiniertem Austausch. Der Plan sollte Abhängigkeiten, Ersatzversorgung und Verantwortliche nennen. Ein neues Secret ist erst dann eine abgeschlossene Maßnahme, wenn die Anwendung es verwendet und der alte Zugang nachweislich ungültig ist.
Zweitens: Die Untersuchung an der Identität ausrichten. Das Unternehmen sollte passende Audit- und Abrechnungsdaten sichern und auf unerwartete Nutzung prüfen. Der Untersuchungsumfang sollte aus den tatsächlichen Rechten folgen, nicht allein aus dem Dateinamen des Fundes. Bei einem Entwicklungszugang ist beispielsweise zu klären, ob produktive Ressourcen oder weitere Berechtigungen erreichbar waren.
Drittens: KI-Zugänge ausdrücklich einbeziehen. Für Modell-APIs empfiehlt sich ein eigenes Inventar pro Anwendung und Umgebung. Ein gemeinsam genutzter Team-Schlüssel erschwert die Zuordnung. Besser prüfbar sind getrennte technische Identitäten mit begrenzten Rechten und klaren Verantwortlichen. Kostenalarme sollten dabei als ergänzende Beobachtung geplant werden, nicht als Ersatz für den Entzug kompromittierter Zugänge.
Viertens: Den Abschluss unabhängig verifizieren. Ein zweites Teammitglied sollte anhand der Anbieteroberfläche oder eines freigegebenen Prüfverfahrens bestätigen, dass die alte Berechtigung nicht mehr gilt. Der Beleg gehört ins Incident-Ticket, ohne den Geheimniswert erneut in Kommentare, Chatnachrichten oder Screenshots zu kopieren.
Risiken und Grenzen der Bewertung
Die Zahlen erlauben keine belastbare Rangliste unsicherer Hosting-Plattformen. Der Primärbericht weist selbst auf unterschiedliche Scannerabdeckung bei früheren Vergleichsstudien hin. Ebenso wenig entsprechen gefundene Schlüssel automatisch einer identischen Zahl betroffener Firmen oder nachgewiesener Sicherheitsvorfälle. [1]
Für die Kommunikation nach innen empfiehlt sich deshalb eine klare Statussprache: öffentlich gefunden, dem Unternehmen zugeordnet, Gültigkeit bestätigt, Reichweite untersucht, Nutzung bewertet und Zugang entzogen. Diese Zustände sollten nicht zu einer einzigen roten oder grünen Ampel zusammenfallen. Eine unbekannte Nutzungshistorie bleibt unbekannt, auch wenn die anschließende Rotation erfolgreich war.
Prävention sollte anschließend mehrschichtig geplant werden: Prüfungen vor Veröffentlichung, regelmäßige Historien-Scans im autorisierten Bestand und ein getesteter Widerrufsablauf. Als operative Kennzahl eignet sich die Zeit vom bestätigten Fund bis zur nachgewiesenen Ungültigkeit besser als die bloße Anzahl geschlossener Scannerwarnungen.
Fazit
Der neue Gitee-Bericht ist vor allem ein Anlass, den Übergang von Code-Sicherheit zu Identitätssicherheit zu prüfen. Ein sauberer Branch beantwortet nicht, ob ein alter Zugang noch funktioniert. Unternehmen sollten deshalb nicht nur das Finden von Secrets testen, sondern die gesamte Reaktionskette bis zum verifizierten Berechtigungsentzug. Dort entscheidet sich, ob eine Warnung tatsächlich erledigt ist.
Quellen
[1] Ben Zimmermann / MongoDB, 28. Oktober 2026: Scanning 7.25 Million Public Repositories on China's Largest Git Platform for Secrets.
[2] The Hacker News, 29. Oktober 2026: 26,400 Valid Cloud and AI Credentials Found Exposed in Public Gitee Repositories.
[3] MongoDB: Kingfisher – Projekt und dokumentierte Arbeitsabläufe.
[4] OWASP: Secrets Management Cheat Sheet.
[5] GitHub Docs: Removing sensitive data from a repository.
