Vom SaaS-Wildwuchs zum unkontrollierten Code
Klassische Schatten-IT bestand meist aus nicht freigegebenen SaaS-Diensten. Solche Anwendungen ließen sich über OAuth-Freigaben, SSO-Aktivitäten, Netzwerkverkehr oder Spesenabrechnungen erkennen und anschließend sperren.
Mit Vibe Coding verändert sich das Problem. Entwickler lassen KI-Agenten Anwendungscode, Pulumi-Skripte und Cloud-Ressourcen erzeugen. Ein internes Werkzeug kann dadurch innerhalb weniger Stunden im AWS-Konto des Unternehmens laufen, ohne Ticket, Sicherheitsprüfung oder Eintrag im Anlagenverzeichnis.
Sinngemäß lautet der entscheidende Befund: Die neue Schatten-IT taucht nicht in OAuth-Protokollen auf, sondern als laufende Infrastruktur im eigenen Cloud-Konto.
Dieser Wechsel lässt sich als Code Sprawl bezeichnen, also als unkontrollierte Verbreitung intern erzeugter Anwendungen und Infrastruktur. Wie häufig solche Systeme bereits in Unternehmen vorkommen, ist bislang nicht mit belastbaren Zahlen belegt.
Warum vibe-codierte Anwendungen schwerer zu erkennen sind
Die neue Schatten-IT wird meist nicht mit der Absicht aufgebaut, Regeln zu umgehen. Mitarbeiter wollen manuelle Prozesse automatisieren und nutzen dafür Werkzeuge, die technische Hürden stark reduzieren. Das Problem liegt darin, dass der erzeugte Code funktioniert, obwohl seine Sicherheitsdetails nicht vollständig verstanden werden.
Eine Anwendung kann direkt auf Produktionsdaten, interne Programmierschnittstellen oder sensible Systeme zugreifen. Ihre IAM-Rollen, also die über das Identitäts- und Zugriffsmanagement vergebenen Rechte, sind häufig zu weit gefasst. Hinzu kommen fest einprogrammierte Zugangsdaten und versehentlich öffentlich erreichbare Endpunkte.
| Merkmal | Klassische SaaS-Schatten-IT | Vibe-codierte Schatten-IT |
|---|---|---|
| Betriebsort | Externer SaaS-Anbieter | Eigenes Cloud-Konto oder lokales System |
| Typische Erkennung | OAuth, SSO, Netzwerkverkehr, Abrechnung | Cloud-Telemetrie, IAM-Änderungen, CSPM |
| Zugriff | Über freigegebene Schnittstellen | Potenziell direkt auf Produktivdaten und interne Dienste |
| Zentrales Risiko | Unkontrollierter externer Dienst | Ungeprüfter Code mit internen Berechtigungen |
KI-generierter Code bringt dabei nicht nur klassische Fehlkonfigurationen mit sich. Auch manipulierte Eingaben und externe Abhängigkeiten können zum Einfallstor werden. Beispiele dafür sind Schadcode durch Prompt Injection in Claude Code und Fremdcode, den Coding-Agenten aus llms.txt installieren.
Sichere Standards müssen technisch erzwungen werden
Richtlinien in einem Wiki reichen für diese Entwicklung nicht aus. Sicherheitsvorgaben müssen dort greifen, wo Anwendungen und Infrastruktur entstehen. Ziel ist nicht, interne Entwicklung zu verhindern, sondern den sicheren Bereitstellungsweg zum einfachsten Standard zu machen.
Restriktive IAM-Rollen
Cloud-Konten für Teams sollten standardmäßig nach dem Least-Privilege-Prinzip arbeiten. Dabei erhält eine Anwendung nur die Rechte, die sie tatsächlich benötigt. Öffentliche Ressourcen oder neue Rollen mit weitreichenden Berechtigungen sollten eine zusätzliche Freigabe erfordern.
Zugangsdaten aus dem Quellcode halten
Passwörter, API-Schlüssel und andere Geheimnisse gehören in einen zentralen Secrets Manager. Dessen Nutzung sollte auf Infrastrukturebene vorgeschrieben werden. Das reduziert die Wahrscheinlichkeit, dass ein KI-Agent sensible Zugangsdaten direkt in Code oder Konfigurationsdateien schreibt.
Interne Anwendungen hinter dem VPN betreiben
Neue interne Werkzeuge sollten standardmäßig nur über das Unternehmens-VPN erreichbar sein. Ein öffentlich zugänglicher Endpunkt muss eine bewusste und geprüfte Entscheidung sein. Damit wird eine häufige Fehlkonfiguration bereits vor der Bereitstellung verhindert.
Automatisierte Prüfung ersetzt kein Code-Review
Vor der Bereitstellung können automatisierte Prüfungen den Code und die Infrastrukturkonfiguration gegen unternehmenseigene Vorgaben testen. Dafür lassen sich auch KI-basierte Prüffunktionen wie Claude Skills einsetzen. Erkannte Verstöße sollten nach Risiko sortiert und mit konkreten Korrekturhinweisen versehen werden.
Die letzte Kontrolle bleibt eine menschliche Sicherheitsprüfung. Bei risikoarmen Anwendungen kann ein entsprechend qualifizierter Entwickler ausreichen. Systeme mit Produktivzugriff, neuer Cloud-Infrastruktur oder ungewöhnlichen IAM-Rollen benötigen dagegen ein formales Security Code Review.
Diese Prüfung ist zugleich eine Verständniskontrolle. Wenn ein KI-Agent wesentliche Teile der Anwendung erzeugt hat, kennt der ursprüngliche Autor möglicherweise nicht jede Abhängigkeit und Berechtigung. Die Risiken autonomer Werkzeuge zeigen sich auch daran, dass KI-Agenten isolierte Sandboxes umgehen können.
CSPM erkennt nur bereits vorhandene Risiken
Cloud Security Posture Management, kurz CSPM, überwacht Cloud-Umgebungen auf Fehlkonfigurationen und riskante Ressourcen. Systeme wie Wiz können öffentlich erreichbare Endpunkte, überprivilegierte Rollen oder falsch konfigurierte Speicher erkennen. Zu diesem Zeitpunkt ist die problematische Anwendung jedoch bereits bereitgestellt.
Zusätzlich braucht es Verhaltensanalysen in den Cloud-Telemetriedaten. Verdächtig sind etwa IAM-Rollen, die außerhalb regulärer CI/CD-Pipelines erstellt werden, neue öffentliche Ressourcen ohne passenden Änderungsvorgang oder direkte API-Aufrufe von Entwicklerrechnern in Produktionskonten. Ein einzelnes Signal beweist keine unautorisierte Anwendung, mehrere Auffälligkeiten rechtfertigen jedoch eine Prüfung.
Eigenentwicklung spart Abos, nicht Governance
Vibe Coding kann teure SaaS-Abonnements durch kleine, passgenaue Anwendungen ersetzen. Das ist wirtschaftlich attraktiv und reduziert die Abhängigkeit von externen Anbietern. Die eingesparten Lizenzkosten beseitigen jedoch nicht den Aufwand für Betrieb, Zugriffskontrolle, Datenschutz und Sicherheitsprüfungen.
Für Unternehmen im DACH-Raum ist dieser Punkt besonders relevant. Wenn intern entwickelte Werkzeuge ungeprüft auf personenbezogene Daten oder Produktionssysteme zugreifen, können etablierte Prozesse für DSGVO, ISO 27001 und NIS-2 umgangen werden. Die Eigenentwicklung bleibt eine reale SaaS-Alternative, benötigt aber verbindliche Plattform-Leitplanken, Secrets-Management, automatisierte Kontrollen und risikobasierte Code-Reviews.