Ich liebe es, wenn Dinge schneller gehen. Ein guter Shortcut, eine clevere Automatisierung, ein KI-Coding-Assistent, der funktionierenden Code baut – herrlich. Fast so schön wie ein Kaffee, der sich selbst nachfüllt.
Aber wie so oft in der IT gilt: Wenn etwas plötzlich sehr einfach wird, wird es manchmal auch sehr einfach gefährlich.
Denn während KI-Tools Entwicklerinnen und Entwickler beim Programmieren unterstützen, entsteht an anderer Stelle ein Problem, das weniger sexy klingt, aber ziemlich viel Schaden anrichten kann: Secrets Sprawl.
Also das unkontrollierte Verstreuen von Zugangsdaten, API-Keys, Tokens, Passwörtern und anderen digitalen Generalschlüsseln im Code, in Repositories, in Skripten oder in CI/CD-Pipelines.
Hier wird es für IT-Entscheider spannend, denn das Thema ist nicht nur ein Entwicklerproblem. Es ist ein Governance-Thema.
Was sind „Secrets“ überhaupt?
Mit „Secrets“ sind keine peinlichen Büro-Kühlschrankgeschichten gemeint. Obwohl auch die manchmal kritisch sind.
In der IT meint man damit vertrauliche Zugangsdaten, zum Beispiel:
- API-Keys für Cloud-Dienste
- Tokens für GitHub, Azure, Microsoft 365 oder andere Plattformen
- Datenbank-Zugangsdaten
- Zertifikate
- SSH-Keys
- Passwörter für Service Accounts
- Zugriffsschlüssel für Automatisierungen
Kurz gesagt: Secrets sind digitale Schlüssel. Und wie bei echten Schlüsseln ist es eher ungünstig, wenn sie unter der Fußmatte liegen. Noch ungünstiger ist es, wenn die Fußmatte öffentlich auf GitHub steht.
Warum KI-Coding das Problem verschärft
KI-Coding-Assistenten sind inzwischen in vielen Entwicklungsprozessen angekommen. Sie schreiben Code, vervollständigen Funktionen, erzeugen Skripte, schlagen Konfigurationen vor und helfen dabei, Dinge schneller produktiv zu bekommen.
Das ist großartig. Wirklich.
Aber: Geschwindigkeit ohne Leitplanken ist wie ein E-Scooter auf Kopfsteinpflaster. Man kommt voran, aber elegant ist anders.
Aktuelle Berichte zeigen, dass KI-gestützte Entwicklung die Menge an Code und damit auch die Menge potenzieller Lecks erhöht. GitGuardian berichtete für 2025 von rund 29 Millionen neu gefundenen Secrets in öffentlichen GitHub-Commits, ein Plus von 34 Prozent gegenüber dem Vorjahr. Außerdem lagen Secret-Leak-Raten in KI-unterstütztem Code im Jahresdurchschnitt etwa doppelt so hoch wie der GitHub-weite Durchschnitt.
Das Problem ist also nicht: „KI ist böse.“
Das Problem ist: KI macht Entwicklung schneller – und skaliert damit auch alte Fehler schneller.
Früher hat vielleicht ein Entwickler aus Versehen einen API-Key in eine Konfigurationsdatei geschrieben. Heute kann ein KI-Assistent in Sekunden Code erzeugen, der funktional aussieht, aber unsichere Muster übernimmt. Zum Beispiel:
Hier ist dein Beispielskript inklusive fest eingetragenem API-Key.
Aus Sicht der KI ist das praktisch. Aus Sicht der Security ist es ungefähr so charmant wie ein Haustürschlüssel mit Adressanhänger.
Das Problem: Nicht der einzelne Key, sondern fehlende Verantwortung
Viele Unternehmen behandeln Secrets-Sprawl noch wie ein reines Scan-Problem: Man sucht nach geleakten Zugangsdaten, löscht sie und hofft, dass niemand schneller war.
Das ist besser als nichts. Aber es reicht nicht.
CSO beschreibt genau diesen Punkt: CISOs sollten Secrets Sprawl nicht nur als technisches Detektionsproblem sehen, sondern als Ownership- und Governance-Problem für maschinelle Identitäten.
Ein geleakter Secret ist häufig nur ein Symptom dafür, dass nicht klar geregelt ist, welche nicht-menschliche Identität welchen Zugriff hat, wem sie gehört und wie sie kontrolliert wird.
Oder etwas weniger trocken formuliert:
Wenn niemand weiß, wem der Schlüssel gehört, wann er erstellt wurde und welche Türen er öffnet, dann ist nicht der verlorene Schlüssel das Hauptproblem. Dann ist der ganze Schlüsselbund außer Kontrolle.
Beispiele aus dem Alltag: So landet der Schlüssel im Code
Secrets Sprawl entsteht selten durch böse Absicht. Häufig passiert es aus Bequemlichkeit, Zeitdruck oder fehlenden Prozessen.
Ein paar typische Beispiele:
1. Der schnelle Test
Ein Entwickler möchte „nur kurz“ eine Schnittstelle testen und trägt den API-Key direkt in den Code ein. Der Test funktioniert. Der Code bleibt. Der Key auch. Klassiker.
2. Die KI schreibt ein Beispiel weiter
Ein KI-Assistent erzeugt Beispielcode mit Platzhaltern. Jemand ersetzt den Platzhalter durch echte Zugangsdaten. Danach wird der Code eingecheckt. Zack: Aus Demo wird Drama.
3. Das vergessene Nebenprojekt
Ein internes Tool wird gebaut, nie offiziell dokumentiert, aber irgendwie nutzt es plötzlich das halbe Team. Die Zugangsdaten liegen in einer .env-Datei, die eigentlich nie ins Repository sollte. Eigentlich.
4. Die Pipeline mit Superkräften
Ein CI/CD-Prozess bekommt umfangreiche Rechte, weil es schnell gehen muss. Später weiß niemand mehr genau, warum diese Pipeline Zugriff auf Produktivsysteme, und Cloud-Ressourcen hat.
5. Der Service Account ohne Besitzer
Ein Konto wurde vor Jahren für eine Automatisierung angelegt. Der Kollege ist weg, das System läuft weiter, der Zugriff bleibt bestehen. Das ist dann IT-Archäologie mit Sicherheitsrisiko.
Warum das für IT-Entscheider wichtig ist
Du musst nicht jede Zeile Code lesen können, um das Risiko zu verstehen.
Wenn Zugangsdaten unkontrolliert im Code landen, entstehen gleich mehrere Gefahren:
-
Ein Angreifer kann mit einem geleakten API-Key auf Cloud-Ressourcen zugreifen.
-
Ein kompromittierter Token kann genutzt werden, um Daten auszulesen, Systeme zu verändern oder weitere Zugänge zu erzeugen.
-
Und wenn ein Secret lange aktiv bleibt, kann daraus ein Dauerproblem werden.
GitGuardian hatte bereits im State of Secrets Sprawl 2025 berichtet, dass viele geleakte Secrets aus früheren Jahren weiterhin aktiv waren – ein klares Zeichen dafür, dass Erkennung allein nicht genügt.
Das Gemeine daran: Nach außen sieht oft alles normal aus. Kein rotes Warnlicht, kein dramatischer Alarmton, kein Hacker mit Kapuzenpulli auf dem Bildschirm. Nur ein legitimer Zugriff mit gültigem Schlüssel.
Genau deshalb ist Secrets Management so wichtig.
OWASP empfiehlt unter anderem, Secrets zentral zu speichern, Zugriffe zu kontrollieren, Secrets zu rotieren, Nutzung zu auditieren und den gesamten Lebenszyklus sauber zu verwalten.
Übersetzt in Alltagssprache:
Nicht überall Schlüssel herumliegen lassen. Wissen, wem welcher Schlüssel gehört. Regelmäßig Schlösser wechseln. Und nachsehen, wer wann welche Tür geöffnet hat.
KI verändert die Geschwindigkeit – Governance muss mithalten
Viele Unternehmen führen KI-Coding ein, bevor ihre Prozesse dafür bereit sind. Das ist menschlich. Neue Tools sind spannend, Teams wollen produktiver werden, Fachbereiche wollen Ergebnisse sehen.
Aber es braucht klare Leitplanken.
Die Cloud Security Alliance warnt, dass Unternehmen KI-generierten Code zunehmend produktiv einsetzen, während Governance-Frameworks und Entwicklertrainings für KI-Code oft noch am Anfang stehen. Bestehende Security-Tools müssen gezielt erweitert werden, um KI-spezifische Risiken abzudecken. (Lab Space)
Das heißt: Wer KI-Coding erlaubt, sollte nicht nur fragen:
„Wie viel schneller werden wir?“
Sondern auch:
„Welche Regeln gelten?“
„Welche Secrets dürfen wo verwendet werden?“
„Welche Tools prüfen Code vor dem Commit?“
„Wer ist für maschinelle Identitäten verantwortlich?“
„Wie schnell können wir Zugangsdaten rotieren, wenn etwas schiefgeht?“
Oder kurz: Mehr Tempo braucht mehr Geländer.
Was Unternehmen jetzt konkret tun sollten
Der erste Schritt ist nicht Panik. Panik ist selten ein guter Berater. Außer vielleicht bei der haarigen Spinnen im Kopfhörer.
Sinnvoller ist ein strukturierter Blick auf Governance, Prozesse und Werkzeuge.
1. Secrets nicht im Code speichern
Klingt banal, ist aber der Kern. Zugangsdaten gehören nicht hart in Quellcode, Skripte oder Konfigurationsdateien geschrieben. Stattdessen sollten zentrale Secrets-Manager genutzt werden, etwa in Cloud-Plattformen oder spezialisierten Security-Lösungen.
2. Scans früh im Entwicklungsprozess einbauen
Secrets sollten nicht erst gefunden werden, wenn sie bereits öffentlich oder produktiv sind. Besser sind Prüfungen direkt beim Commit, in Pull Requests und in CI/CD-Pipelines.
3. KI-Coding mit klaren Regeln nutzen
KI-Assistenten sollten nicht wild im Blindflug eingesetzt werden. Teams brauchen einfache Vorgaben: Welche Daten dürfen in Prompts? Welche Code-Vorschläge müssen geprüft werden? Welche Beispiele sind tabu? Wie wird mit generierten Konfigurationen umgegangen?
4. Maschinelle Identitäten inventarisieren
Viele Zugriffe erfolgen nicht durch Menschen, sondern durch Anwendungen, Dienste, Agenten, Pipelines und Automatisierungen. Diese Non-Human Identities brauchen Besitzer, Zweck, Ablaufdatum und passende Rechte.
5. Rechte begrenzen
Ein Secret sollte nicht mehr können als nötig. Ein Test-Key braucht keinen Zugriff auf produktive Kundendaten. Eine Build-Pipeline muss nicht der digitale König von allem sein.
6. Rotation und Notfallprozesse üben
Wenn ein Secret geleakt wird, muss klar sein, was passiert: sperren, rotieren, Auswirkungen prüfen, Logs auswerten, Kommunikation steuern. Das sollte kein Impro-Theater sein.
7. Awareness schaffen, ohne Entwickler zu nerven
Security darf nicht wie eine Bremse wirken, sondern ist ein Sicherheitsgurt. Niemand liebt ihn leidenschaftlich, aber alle sind froh, wenn er da ist. Gute Prozesse helfen Teams, sicher zu arbeiten, ohne ständig Formulare auszufüllen oder auf Freigaben aus dem Bermudadreieck zu warten.
Warum das besonders in der Cloud zählt
In der Cloud ist fast alles per API steuerbar. Das ist einer der großen Vorteile: Automatisierung, Skalierung, Geschwindigkeit. Deshalb sind Secrets aber so mächtig.
Ein einziger falsch behandelter Key kann Zugriff auf Ressourcen, Datenbanken, Storage, KI-Dienste oder ganze Workloads ermöglichen. Und weil Cloud-Umgebungen dynamisch sind, wächst die Zahl der Identitäten und Berechtigungen schnell mit.
Das heißt: Komplexität so beherrschbar machen, dass Sicherheit im Alltag funktioniert.
Nicht als theoretisches Konzept. Sondern praktisch. Verständlich. Und mit Menschen, die sich kümmern.
KI-Coding ist nicht das Problem – ungeregeltes KI-Coding schon
KI kann Entwicklung enorm beschleunigen. Sie kann Teams entlasten, Ideen schneller testbar machen und repetitive Aufgaben reduzieren. Das ist ein enormer Mehrwert.
Aber wenn dadurch mehr Zugangsdaten unkontrolliert im Code landen, wird Produktivität zum Sicherheitsrisiko.
Die gute Nachricht: Secrets Sprawl ist lösbar: Es braucht Governance, klare Zuständigkeiten, sauberes Secrets Management und eine Sicherheitskultur, die Entwickler unterstützt statt ausbremst.
Denn am Ende gilt:
KI darf gerne Code schreiben. Aber die Schlüssel zum Unternehmen sollte sie nicht einfach danebenlegen.
