Geheime Zugangsdaten – kurz Secrets, etwa API-Keys, Tokens oder Datenbank-Passwörter – entwickeln sich zur zentralen Schwachstelle moderner IT-Landschaften. Der aktuelle Bericht GitGuardian State of Secrets Sprawl 2026 zeigt, dass das Problem nicht unter Kontrolle ist, sondern eskaliert: Allein 2025 wurden auf öffentlichem GitHub 29 Millionen neue Secrets entdeckt, ein Anstieg um 34 % und der stärkste Zuwachs seit Beginn der Messungen.
Explosion hardcodierter Secrets in Open Source und KI-Projekten
Seit 2021 ist die Zahl der gefundenen Secrets um 152 % gestiegen, während die Zahl der öffentlichen GitHub-Entwickelnden „nur“ um 98 % zulegte. Das deutet auf einen klaren Trend: Mehr Personen schreiben Code, gleichzeitig entstehen mit Cloud, DevOps und KI immer mehr technische Identitäten, die mit Zugangsdaten ausgestattet werden – häufig hardcodiert im Quelltext oder in Konfigurationsdateien.
KI-spezifische Zugangsdaten als neuer Risikotreiber
Besonders dynamisch wächst der Bereich AI Security. 2025 registrierte GitGuardian 1 275 105 Secrets mit KI-Bezug – ein Plus von 81 % gegenüber 2024. Acht der zehn am schnellsten wachsenden Schlüssel-Kategorien stammen aus dem KI-Ökosystem: etwa Retrieval-APIs wie Brave Search (+1255 %), Orchestrierungstools wie Firecrawl (+796 %) oder gemanagte Backends wie Supabase (+992 %). Jeder zusätzliche Integrationslayer für LLMs schafft eine neue machine identity und erweitert die potenzielle Angriffsfläche.
Interne Repositories und Kollaborations-Tools als blinde Flecken
Während viele Sicherheitsprogramme den Fokus auf öffentliche GitHub-Repositories legen, liegen die wertvollsten Secrets typischerweise in internen Repos. Laut GitGuardian enthalten 32,2 % interner Repositories mindestens ein hart codiertes Secret – gegenüber 5,6 % bei öffentlichen Projekten. In diesen internen Repos dominieren produktive Assets wie CI/CD-Tokens, Cloud-Credentials und Datenbank-Passwörter, also genau jene Zugangsdaten, die Angreifende nach einem ersten Eindringen ausnutzen.
Slack, Jira & Co.: kritische Secrets im Chat statt im Tresor
2025 entfielen 28 % aller beobachteten Zwischenfälle ausschließlich auf Kollaborationsplattformen wie Slack, Jira oder Confluence – ohne Beteiligung von Code-Repositories. Bemerkenswert: 56,7 % der dort gefundenen Secrets wurden als kritisch eingestuft, verglichen mit 43,7 % bei reinen Repository-Leaks. In der Praxis tauschen Teams Zugangsdaten häufig ad hoc im Chat, bei Incident-Debugging oder Onboarding – oft ohne technische Schutzmechanismen oder Löschroutinen.
Exponierte GitLab-Instanzen, Container-Registries und der aufgelöste Perimeter
GitGuardian stieß 2025 auf tausende unbeabsichtigt öffentlich erreichbare self-hosted GitLab-Server und Docker-Registries. Beim Scan fanden sich rund 80 000 Secrets, davon 10 000 weiterhin gültig. In Container-Images waren die Ergebnisse besonders kritisch: 18 % der untersuchten Docker-Images enthielten Secrets, wovon 15 % noch gültig waren. In GitLab-Repositories wurden in 12 % der Fälle Secrets identifiziert – und ebenfalls 12 % dieser Funde waren noch nutzbar. Container-Secrets sind deshalb so gefährlich, weil sie typischerweise dicht an der Produktionsumgebung liegen und oft „einmal eingebrannt“ und dann jahrelang unverändert ausgerollt werden. Fehlkonfigurationen verwandeln vermeintlich private Registries und Repos so in ein faktisch öffentliches Angriffsziel.
Warum Geheimnisse über Jahre überleben: Rotation als strukturelles Defizit
Die Entdeckung eines geleakten Secrets bedeutet nicht automatisch Entschärfung. Bei einer erneuten Prüfung der bereits 2022 als valide eingestuften Zugangsdaten stellten die Forschenden fest, dass 64 % auch vier Jahre später noch ausnutzbar waren. Damit kollidiert die Praxis deutlich mit Empfehlungen aus Frameworks wie NIST SP 800-207 (Zero Trust) oder dem OWASP Secrets Management Cheat Sheet, die regelmäßige Rotation und automatisierte Revocation fordern. In Realität sind Secrets tief in Build-Pipelines, CI-Variablen, Container-Images oder Drittanbieter-Integrationen verankert; viele Teams scheuen das Risiko von Ausfällen durch fehlerhafte Schlüsselrotation – und akzeptieren damit unbewusst ein dauerhaft erhöhtes Cyberrisiko.
Software-Supply-Chain, CI/CD-Runners und AI-Agents als neue Angriffsoberfläche
Supply-Chain-Angriffe illustrieren, wie weit Secrets auf Entwickler- und Build-Systemen verteilt sind. Im Zuge der Kampagne Shai-Hulud 2 wurden auf 6 943 kompromittierten Systemen insgesamt 294 842 Secret-Vorkommen identifiziert, entsprechend 33 185 eindeutigen Werten. Ein einzelnes aktives Secret tauchte im Schnitt in acht verschiedenen Dateien oder Artefakten pro Maschine auf – etwa in .env-Dateien, Shell-Historien, IDE-Konfigurationen, gecachten Tokens und Build-Artefakten. Auffällig: 59 % der betroffenen Systeme waren CI/CD-Runners, nicht Entwickler-Laptops. Ähnlich zeigte die Attacke auf das Paket LiteLLM, wie Schadcode SSH-Keys, Cloud-Zugangsdaten und API-Tokens direkt von Entwicklerrechnern erntet, auf denen heute verstärkt KI-Toolchains laufen.
Model Context Protocol (MCP) und Agenten-Ökosysteme als Risiko-Multiplikator
Mit Frameworks wie dem Model Context Protocol (MCP) entstehen Ökosysteme aus spezialisierten AI-Agents, die eigenständig auf APIs, Datenbanken und interne Services zugreifen. 2025 wurden in öffentlichen MCP-Konfigurationen auf GitHub 24 008 eindeutige Secrets gefunden, davon 2 117 bestätigte valide. Typischerweise werden Zugangsdaten hier in Konfigurationsdateien, Start-Flags oder lokalen JSON-Files hinterlegt. Je stärker Organisationen solche Agenten produktiv einsetzen, desto wichtiger wird ein robustes, zentrales Secrets Management für diese neuen, nicht-menschlichen Identitäten.
Von Secret-Scanning zu ganzheitlichem Management Non-Human Identities
Die Daten belegen, dass punktuelles Secret-Scanning öffentlicher Repositories nicht mehr ausreicht. Strategisch entscheidend sind drei Fragen: Wie viele Non-Human Identities (NHI) existieren in der eigenen Infrastruktur, wer verantwortet sie und auf welche Ressourcen greifen sie zu? Moderne Sicherheitsarchitekturen – im Einklang mit Zero-Trust-Prinzipien und gängigen Cloud-Best-Practices – verschieben den Fokus hin zu kontinuierlichem Identity-basiertem Zugriff. Zentrale Bausteine sind: weitgehender Verzicht auf langlebige statische Secrets, Einführung kurzlebiger, dynamisch ausgestellter Tokens (z. B. via OIDC oder Cloud STS), Nutzung von Secrets-Vaults als Standard-Pattern im Development sowie ein vollständiges Lifecycle-Management für jede Service-Identity – von CI-Jobs über Microservices bis zu KI-Agenten.
Organisationen, die Secrets noch als Einzelfälle betrachten, laufen Gefahr, in kommenden Angriffswellen systematisch über ihre Non-Human Identities kompromittiert zu werden. Wer dagegen frühzeitig Inventarisierung, automatisiertes Scanning, zentrale Vaults, erzwungene Rotation und klar definierte Owners für jede technische Identität etabliert, senkt nicht nur das unmittelbare Angriffsrisiko. Er schafft zugleich eine Grundlage für belastbare Governance im IAM-Bereich – und damit für eine Sicherheitsstrategie, die DevOps-Geschwindigkeit, KI-Innovationen und regulatorische Anforderungen langfristig in Einklang bringt.
