Ihre Engineers können heute Cloud-Infrastruktur schneller provisionieren, als Ihr Review-Prozess sie erfassen kann, und der Code sieht dabei nicht anders aus als das, was ein legitimes Deployment erzeugen würde.
Schatten-IT war früher ein SaaS-Problem. Jemand im Marketingteam meldete sich für ein Tool an, verbindet es mit Google Workspace, und Ihr erstes Signal war eine OAuth-Freigabe, die Sie nicht autorisiert hatten. Ärgerlich. Erkennbar. Eindämmbar.
Die neue Schatten-IT taucht nicht in Ihren OAuth-Logs auf. Sie taucht als Infrastruktur auf, die in Ihrem Cloud-Account läuft, gebaut von einem gut meinenden Engineer, der einen KI-Agenten gebeten hat, sie an einem Nachmittag aufzusetzen. Kein Ticket, kein Review, keine Beteiligung des Security-Teams. Nur jemand mit einer guten Idee und einem Tool, das die ganze Reibung entfernt hat, die früher gebremst hätte.
Diese Reibung war nicht nur Ineffizienz. Ein Teil davon leistete echte Security-Arbeit.
Das Problem mit guten Absichten
Klassische Schatten-IT hatte einen Beigeschmack davon, dass jemand die IT wissentlich umgangen hat. Ein Team, das nicht auf Procurement warten wollte. Die Security-Geschichte drehte sich zumindest teilweise um Policy Enforcement.
Darum geht es hier nicht.
Der Engineer, der ein internes Tool für sein Team per Vibe-Coding baut, versucht nicht, irgendetwas zu umgehen, er versucht zu helfen. Er hat Zugriff auf einen KI-Agenten, der Code schreiben, Pulumi generieren und Infrastruktur schneller aufsetzen kann, als jeder Review-Prozess dafür ausgelegt war. Und sofern er sich nicht mit Cloud-Security beschäftigt hat, hat er keinen Grund zu wissen, dass das, was er gerade veröffentlicht hat, ein Problem ist.
Das macht die Sache schwieriger: Man kann sich hier nicht durch Enforcement heraushelfen, man muss dem schnell zuvorkommen.
So sieht der schlechte Tag aus: Ein Engineer baut eine schlanke interne App, um etwas zu automatisieren, das sein Team bisher manuell macht. Er bittet den KI-Agenten, die Infrastruktur zu übernehmen. Der Agent provisioniert Ressourcen im AWS-Account des Teams, öffnet die nötigen Ports und deployt die App. Es funktioniert, und das Team liebt es. Niemand eröffnet ein Ticket, weil es nichts zu eröffnen gibt. Sechs Wochen später markiert Ihr CSPM einen öffentlich erreichbaren Endpunkt mit einer überberechtigten IAM-Rolle daran. Bis dahin läuft die App schon lange genug in Produktion, dass Lateral Movement ein realistisches Szenario ist, kein theoretisches.
Die Absicht war gut. Das Ergebnis hat einen Wirkungsradius.
Warum sich das von SaaS-Sprawl unterscheidet
Als Schatten-IT unautorisiertes SaaS bedeutete, war Ihre Detection-Fläche klar definiert. OAuth-Freigaben, Netzwerkverkehr, Spesenabrechnungen, SSO-Anomalien. Das Tool existierte außerhalb Ihrer Infrastruktur. Es war extern. Sie konnten es finden, Sie konnten es abschneiden, und der Schaden war meist begrenzt.
Von Agenten gebauter interner Tooling-Bestand lebt innerhalb Ihrer Infrastruktur. Er hat IAM-Rollen. Er kann direkten Zugriff auf Produktionsdaten, interne APIs oder sensible Systeme haben. Er wirkt legitim, weil er von einer legitimen Mitarbeiterin mit legitimem Tooling gebaut wurde. Es gibt keine offensichtliche Nahtstelle, an der man ansetzen könnte. Der Code kündigt sich nicht als ungoverned an. Er läuft einfach.
Das ist die Verschiebung, die man klar benennen sollte: Wir sind von SaaS-Sprawl zu Code-Sprawl übergegangen. Das Detection-Playbook für das eine lässt sich nicht auf das andere übertragen.
Eine Baseline, die man tatsächlich nutzt
Das Ziel hier ist nicht, Engineers zu bremsen. Es ist, den sicheren Weg zum einfachen Weg zu machen. Die Baseline, auf die wir bei Webflow hinarbeiten, hat zwei Schichten, und diese Unterscheidung ist wichtig.
Platform Controls sind Dinge, die Sie einmal auf Organisations- oder Account-Ebene konfigurieren und die es strukturell schwerer machen, versehentlich das Falsche zu tun.
IAM-Least-Privilege-Sicherheitsvorgaben. Die Berechtigungen, die für AWS-Accounts auf Team-Ebene verfügbar sind, sollten standardmäßig eng gefasst sein. Ein Engineer sollte nicht in der Lage sein, eine öffentlich erreichbare Ressource mit einer breit berechtigten Rolle zu provisionieren, ohne auf eine Sicherheitsvorgabe zu stoßen. Die Sicherheitsvorgabe stoppt nicht die Arbeit. Sie verhindert, dass die schlimmste Version der Arbeit stillschweigend live geht.
Secrets-Manager-Enforcement. Hartcodierte Zugangsdaten in per Vibe-Coding gebauten Apps sind keine Hypothese. Sie sind eine nahe Gewissheit, wenn Sie den richtigen Weg nicht offensichtlich machen. Die Nutzung eines Secrets Managers auf Infrastrukturebene zu erzwingen, nimmt dem einzelnen Engineer diese Entscheidung vollständig ab.
VPN-geschützte Deployment-Ziele. Internes Tooling sollte standardmäßig hinter Ihrem Firmen-VPN landen. Wenn etwas wirklich öffentlich erreichbar sein muss, sollte das eine bewusste Entscheidung erfordern, keinen versehentlichen Standard.
Process Controls sind das, was auf Tool-Ebene passieren muss, bevor irgendetwas live geht.
Automatisierter Baseline-Check. Bevor eine sicherheitskundige Person sich irgendetwas ansieht, prüfen Sie Code und Infrastrukturkonfiguration automatisch gegen Ihre Baseline. Markieren Sie Verstöße, staffeln Sie sie nach Schweregrad, und geben Sie dem Engineer konkrete Anleitung zur Behebung. Das ist die Schicht, die ein Claude Skill oder ähnliches Tooling übernehmen kann. Das menschliche Review konzentriert sich dann auf das, was der automatisierte Check aufgezeigt hat, statt von null zu starten.
Sicherheitskundiges Code Review mit Security-Eskalation. Jedes intern gebaute Tool, das Produktionsinfrastruktur berührt, braucht vor dem Livegang einen Menschen mit Sicherheitskontext, der es sich ansieht. Bei Tooling mit geringerem Risiko ist das ein Peer-Engineer, der den Wirkungsradius dessen versteht, was er reviewt. Bei allem mit Cloud-Infrastruktur, direktem Datenzugriff oder neuartigen IAM-Rollen eskaliert es zu einem formellen Security Review. Dieselbe Kontrolle, gestaffelt nach Risiko. Der entscheidende Punkt: Der Reviewer muss den Code tatsächlich verstehen. Bei per Vibe-Coding gebauten Tools versteht die Autorin womöglich nicht vollständig, was sie gebaut hat. Das macht das Review wichtiger, nicht zur Formalität. Es ist nicht nur ein Qualitätsgate. Es ist ein Verständnisgate.
Das Sicherheitsnetz
Die Baseline ist präventiv. Detection fängt auf, was durchschlüpft.
Ihr CSPM ist das richtige Tool, um Fehlkonfigurationen in dem zu finden, was schon existiert. Wiz und ähnliche Tools legen den öffentlich erreichbaren Endpunkt offen, die überberechtigte Rolle, den Storage-Bucket ohne passende Zugriffskontrollen.
Doch CSPM findet nur, was bereits deployt ist. Die Baseline und der Review-Prozess sind das, worauf Sie zählen, um das zu verhindern. Detection ist die Auffangschicht, nicht die erste Linie.
Das schwierigere Detection-Problem ist überhaupt zu wissen, dass etwas existiert. Ein per Vibe-Coding gebautes Tool, das lokal oder in einem Team-Account läuft, lässt möglicherweise keine Spur in Ihrer normalen Sichtbarkeitsschicht. Keine Deployment-Pipeline. Kein Change-Ticket. Kein Eintrag im Asset-Inventar.
Hier fangen behaviorale Signale in Ihrer Cloud-Telemetrie an, wichtig zu werden. IAM-Rollenerstellung außerhalb Ihrer normalen Pipeline-Aktivität. Neue öffentlich erreichbare Ressourcen, die ohne zugehörigen Change-Record auftauchen. API-Aufrufe, die von Entwicklermaschinen direkt in Produktionsaccounts gehen, statt über Ihr Standard-Tooling. Keines dieser Signale ist allein schon endgültig. In Kombination beginnen sie, wie etwas auszusehen, das einen genaueren Blick verdient.
Die meisten Teams suchen nicht gezielt nach diesen Signalen im Kontext von agentengebautem Tooling. Das ist die Lücke, die es zu schließen lohnt.
Die kodifizierte Baseline
Dokumentation, die in einem Wiki lebt, ist eine Baseline, die niemand in dem Moment nutzt, in dem er sie braucht. Der bessere Weg ist, die Baseline innerhalb der Tools verfügbar zu machen, die Engineers bereits nutzen, genau im Moment des Bauens.
Ein Claude Skill oder ähnliches KI-natives Tooling, das Architekturbeschreibungen oder generierte Infrastruktur gegen Ihre spezifische Security-Baseline prüft, ist nützlicher als eine Checkliste in Confluence. Der Engineer erhält konkretes, umsetzbares Feedback, bevor ein menschlicher Reviewer es überhaupt sieht. Das Security-Team erhält einen ersten Durchgang, der schon für die offensichtlichen Fehler gefiltert wurde. Das Review ist besser, weil es von einem vollständigeren Bild ausgeht.
All das funktioniert nicht, wenn Engineers nicht wissen, dass der Skill oder der Review-Prozess existiert. Awareness ist selbst eine Präventionsschicht. Beides beim Onboarding einzuführen macht den sicheren Weg sichtbar, und das Feedback des Skills gleichzeitig als Aufklärung darüber dienen zu lassen, warum jeder Check wichtig ist, ist das, was es verinnerlicht. Eine Sicherheitsvorgabe, die sich nicht ankündigt, ist nicht präventiv.
Dahin steuern wir intern. Dieser Blogbeitrag ist das Argument dafür, warum das wichtig ist. Der Skill ist das, was es operationalisiert.
Das Fazit
Per Vibe-Coding gebaute interne Tools verschwinden nicht. Die Reibung, die ungoverned Infrastruktur früher gebremst hat, ist weg, und sie kommt nicht zurück. Die Frage ist, ob Ihre Security-Baseline aufholt, bevor es Ihr CSPM tut.
Platform Controls machen den sicheren Weg zum Standard. Process Controls stellen sicher, dass ein Mensch mit Sicherheitskontext alles sieht, bevor es live geht. Detection gibt Ihnen eine Auffangschicht für das, was trotzdem durchschlüpft.
Nichts davon erfordert ein dediziertes AppSec-Team oder ein SOC. Es erfordert eine klare Baseline, das Tooling, um sie durchzusetzen, und Engineers, die verstehen, was sie reviewen. Das ist ein Problem, das ein kleines, gut strukturiertes Security-Team lösen kann. Platform Controls liegen auf Organisations- oder SecEng-Ebene, einmal festgelegt und überall angewendet. Process Controls sind verteilt: Ein Peer-Engineer mit Sicherheitskontext übernimmt Tooling mit geringerem Risiko, während alles mit Cloud-Infrastruktur, direktem Datenzugriff oder neuartigem IAM zu einem formellen Security Review eskaliert. Das ist verteilte Verantwortung mit einem klaren Eskalationspfad, nicht ein einziges Team, das alles reviewt.
Bauen Sie die Baseline, bevor Ihr CSPM sie für Sie findet.
