Die Menge an unkontrolliert verteilten Geheimnissen in Softwareentwicklung ist zum Kernproblem der Cybersicherheit geworden. Während seit 2021 die Zahl geleakter Secrets um 152 Prozent gestiegen ist, wuchs die Developer-Community auf GitHub nur um 98 Prozent. Das bedeutet: Mehr Menschen und KI-gestützte Code-Generierung führen zu exponentiell mehr Credentials in Umlauf — schneller, als Sicherheitsteams sie aufspüren können.
KI als Sicherheitsrisiko
Das größte Phänomen ist die AI-Revolution. GitGuardian registrierte 2025 über 1,2 Millionen geleakte Secrets von AI-Diensten — ein Anstieg von 81 Prozent gegenüber 2024. Acht der zehn am schnellsten wachsenden Kategorien geleakter Secrets sind KI-bezogen. Besonders besorgniserregend: Die größten Sprünge finden sich bei LLM-Infrastruktur-Services wie Brave Search API (+1.255 Prozent), dem Orchestrierungstool Firecrawler (+796 Prozent) und dem Backend Supabase (+992 Prozent). Jede neue KI-Integration bedeutet eine neue Machine-Identity und eine erweiterte Angriffsfläche.
Das unterschätzte interne Risiko
Während die Öffentlichkeit auf GitHub-Lecks fokussiert, zeigt sich das eigentliche Problem intern: 32,2 Prozent der Repositories in Unternehmensnetzen enthalten mindestens ein Hardcoded Secret — gegenüber nur 5,6 Prozent bei öffentlichen Repos. Diese sind keine Test-Keys, sondern echte CI/CD-Token, Cloud-Zugangsdaten und Datenbankpasswörter — genau das, worauf Angreifer nach dem Eindringen zielen.
Überraschungsvektor: Collaboration-Tools
Eine besonders unterschätzte Gefahr: 28 Prozent aller Incidents 2025 stammten nicht aus Quellcode, sondern aus Collaboration-Tools wie Slack, Jira und Confluence. Das Tückische: 56,7 Prozent dieser Secrets waren kritisch bewertet, gegenüber nur 43,7 Prozent bei Code-Leaks. Teams teilen Credentials während Incident Response, Troubleshooting und Onboarding — und viele Sicherheitsteams scannen diese Kanäle gar nicht systematisch.
Vergessene Docker-Container und GitLab-Instanzen
GitGuardian fand tausende unbeabsichtigt freigegebene selbstgehostete GitLab-Instanzen und Docker-Registries. In Docker-Images waren sogar 18 Prozent mit Secrets versehen, davon 15 Prozent noch gültig. Diese Secrets sind oft noch produktionsnäher als der Code selbst.
Das Remediations-Versprechen bleibt aus
Das zentrale Problem: Detection ist nicht gleich Remediation. GitGuardian testete Secrets aus 2022 erneut — 64 Prozent waren vier Jahre später immer noch exploitierbar. Das ist keine Ausreißer, sondern Beweis dafür, dass Rotation und Revokation in den meisten Organisationen nicht automatisiert sind. Viele Teams verzichten bewusst auf Rotation, um Production-Breaks zu vermeiden — und überlassen Angreifern dadurch langfristige Zugriffswege.
Supply-Chain-Realität
Die jüngsten Shai-Hulud-2- und LiteLLM-Supply-Chain-Attacken zeigen: Auf kompromittierten Developer-Machines fanden sich durchschnittlich acht Kopien desselben Secrets — verteilt über .env-Dateien, Shell-History, IDE-Konfigurationen und Build-Artefakte. Besonders beunruhigend: 59 Prozent der kompromittierten Systeme waren CI/CD-Runner, nicht private Laptops. Das ist ein organisationales Sicherheitsproblem, keine individuelle Hygiene-Frage.
Forderung an deutsche Sicherheitsteams
Die alte Strategie — öffentliche Repos scannen und auf Compliance hoffen — funktioniert nicht mehr. Unternehmen müssen drei Fragen beantworten können: Welche nicht-menschlichen Identitäten existieren? Wer ist verantwortlich? Was können sie zugreifen? Das erfordert kontinuierliches Governance für Machine Identities, Elimination von statischen Long-Lived-Credentials und Implementierung von Secrets-Vaulting als Standard-Workflow. Nur so entsteht echte Kontrolle über das unkontrollierte Secrets-Chaos.