Secure Vibe Coding: Kann es so etwas überhaupt geben?
Es beginnt meistens harmlos. Man beschreibt einem Coding Agent eine kleine Idee, lehnt sich kurz zurück und wenige Minuten später läuft da tatsächlich etwas. Ein Dashboard, ein Tool für die Reisekosten oder die längst überfällige interne Inventarverwaltung. Dazu gibt es Login, Datenbank, API und natürlich noch einen schicken Dark Mode. Letzteren hatte zwar niemand bestellt, aber er sieht gut aus.
Willkommen beim Vibe Coding. Das Tempo macht Spaß und senkt die Hürde, eigene Ideen auszuprobieren. Nur hat Software leider die unangenehme Eigenschaft, auch dann komplex zu sein, wenn sie sich besonders einfach erzeugen lässt. Spätestens wenn echte Nutzer, Passwörter oder Kundendaten ins Spiel kommen, bekommt der Vibe deshalb einen kleinen Beipackzettel.
Kann Vibe Coding überhaupt sicher sein?
Die kurze Antwort lautet: ja, aber nicht allein durch gute Laune und einen Prompt mit dem Zusatz „Bitte sicher programmieren“.
Coding Agents können bei den Grundlagen sogar ziemlich hilfreich sein. Sie verwenden etablierte Frameworks, greifen auf bekannte Bibliotheken zurück und bauen Standardmechanismen oft schneller ein, als man selbst die passende Dokumentation geöffnet hat. Eingabevalidierung, parametrisierte Datenbankabfragen, sichere Passwort Hashes oder vernünftige HTTP Header sind für aktuelle Modelle keine Fremdwörter.
Das ist ein echter Vorteil. Wiederkehrende Sicherheitsaufgaben lassen sich standardisieren und direkt beim Erzeugen des Codes berücksichtigen. Ein Agent vergisst auch nicht aus Langeweile die dritte fast identische Prüfung in einem Formular. Zumindest dann nicht, wenn seine Anweisungen und sein Kontext stimmen.
Genau dort liegt allerdings der Haken. Ein Coding Agent optimiert sehr gern auf das sichtbare Ziel: Die Funktion soll laufen, der Test soll grün werden und der Nutzer möchte möglichst schnell ein Ergebnis sehen. Sicherheit ist dagegen häufig unsichtbar. Eine fehlende Rechteprüfung fällt in der Demo nicht auf. Ein versehentlich öffentlich erreichbarer Debug Endpunkt funktioniert sogar hervorragend. Und ein fest im Code hinterlegter API Schlüssel verursacht zunächst einmal keinen Syntaxfehler.
Aus einer kleinen Idee wird schnell ein kleiner Konzern
Vibe Coding produziert nicht zwangsläufig unsicheren Code. Es produziert aber sehr leicht mehr Code und mehr Architektur, als für ein Problem eigentlich nötig wären.
Aus einem simplen Formular werden dann eine Single Page App, drei Services, eine Nachrichtenwarteschlange und 84 Pakete aus dem JavaScript Ökosystem. Alles sauber getrennt, theoretisch skalierbar und bereit für die ersten zehn Millionen Nutzer. Aktuelle Nutzerzahl: vier, davon zwei Testkonten.
Jede zusätzliche Komponente bringt eigene Einstellungen, Updates und Abhängigkeiten mit. Damit wächst nicht nur die Wartungsarbeit, sondern auch die Angriffsfläche. Ein verwundbares Paket, eine zu großzügige Cloud Rolle oder eine vergessene Administrationsroute genügt. Besonders die Supply Chain ist längst ein Dauerthema der Sicherheitsbranche. Wenn eine Anwendung aus Hunderten fremden Paketen besteht, vertraut man nicht mehr nur dem eigenen Code. Man vertraut einer ziemlich großen Wohngemeinschaft.
Aktuelle Untersuchungen zu agentengeneriertem Code zeigen genau dieses Spannungsfeld. Die Anwendungen funktionieren häufig, enthalten aber trotzdem wiederkehrende Probleme wie unzureichend geprüfte Eingaben, Platzhalterlogik oder offengelegte Geheimnisse. Bessere Modelle und bessere Prompts helfen, beseitigen das Problem jedoch nicht vollständig. „Läuft bei mir“ bleibt eben auch mit künstlicher Intelligenz kein Sicherheitsaudit.
Project CodeGuard: Sicherheitsregeln direkt im Agenten
Ein spannender Ansatz ist Project CodeGuard. Das ursprünglich von Cisco als offenes Framework vorgestellte Projekt liefert Sicherheitsregeln für verschiedene Coding Agents, darunter auch Codex, Claude Code, Cursor und GitHub Copilot.
Die Idee ist angenehm pragmatisch. Der Agent bekommt nicht nur den Auftrag, irgendeine funktionierende Lösung zu bauen. Er erhält konkrete Leitplanken für Themen wie Authentifizierung, Eingabevalidierung, Geheimnisse, Verschlüsselung und den sicheren Umgang mit Dateien. Allgemeine Regeln gelten immer, sprachspezifische Hinweise werden passend zur Aufgabe geladen.
Damit wird aus „Mach das bitte sicher“ eine wesentlich brauchbarere Arbeitsanweisung. CodeGuard erinnert den Agenten beispielsweise daran, keine Zugangsdaten fest einzubauen, Berechtigungen sparsam zu vergeben und Eingaben an der richtigen Vertrauensgrenze zu prüfen. Das klingt banal. In der Praxis sind es aber oft genau diese Banalitäten, aus denen später sehr interessante Freitage werden.
Für Codex, Claude Code un Co. gibt es CodeGuard als Skill beziehungsweise Plugin. Dabei ist wichtig, was das Werkzeug leisten kann und was nicht. Es verbessert die Entscheidungen während der Codeerzeugung und kann bei einer Prüfung auffällige Stellen markieren. Es ist aber kein mathematischer Beweis für sichere Software. Fehlerhafte Annahmen, Lücken in der Geschäftslogik oder eine unglückliche Architektur können weiterhin durchrutschen. CodeGuard ist eher ein erfahrener Kollege auf dem Beifahrersitz als eine unzerstörbare Leitplanke.
Aber Coding ist gerade mal die halbe Miete. Das finale Deployment ist dann besonders in Kombination mit komplexen Code noch einmal ein ganz anderes Spielbrett…
open-appsec: Schutz, wenn die Anwendung bereits draußen spielt
Während bspw. CodeGuard möglichst früh im Entwicklungsprozess ansetzt, kümmert sich open-appsec um eine andere Ebene. Das Open Source Projekt schützt Webanwendungen und APIs zur Laufzeit. Es lässt sich unter anderem mit NGINX, Kong, APISIX und Envoy sowie in Docker und Kubernetes Umgebungen einsetzen.
open-appsec nutzt maschinelles Lernen, um Angriffe und verdächtige Anfragen zu erkennen. Damit kann es eine sinnvolle zusätzliche Schicht gegen bekannte Webrisiken und neue Angriffsmuster bilden. Gerade bei schnell entstandenen Anwendungen ist das beruhigend.
Trotzdem gilt auch hier: Ein Laufzeitschutz repariert keinen unsicheren Code. Er ist der Airbag, nicht die Einladung, ohne Bremsen loszufahren. Gute Sicherheitsregeln beim Coding, Tests und Schutz im Betrieb ergänzen sich. Keines davon ersetzt die anderen.
Wer noch mitspielen darf
Secure Vibe Coding funktioniert am besten als kleines Team aus Werkzeugen. Es müssen nicht zwanzig sein. Einige gut gewählte Kontrollen bringen meist mehr als ein Sicherheitszoo, dessen Warnungen nach drei Tagen niemand mehr liest.
- Semgrep oder CodeQL untersuchen den eigenen Quellcode auf bekannte problematische Muster.
- Dependabot, OSV Scanner oder Trivy helfen dabei, verwundbare Bibliotheken und Containerbestandteile zu finden.
- OpenSSF Scorecard liefert Hinweise darauf, wie es um die Sicherheitspraktiken eines Open Source Projekts steht.
- Secret Scanner wie Gitleaks suchen nach Schlüsseln und Zugangsdaten, bevor diese im Repository ein dauerhaftes Zuhause finden.
Dazu gehören weiterhin die eher unglamourösen Dinge: wenige Abhängigkeiten, reproduzierbare Builds, Updates, Backups, getrennte Umgebungen und ein Mensch, der bei kritischen Änderungen noch einmal hinsieht. Besonders bei Anmeldung, Rechteverwaltung, Bezahlvorgängen und persönlichen Daten sollte der Agent nicht seine eigenen Hausaufgaben benoten.
Sicherheit kostet auch Tokens
Coding Skills und Sicherheitsplugins gibt es nicht zum Nulltarif – Wenngleich die Plugins selbst Quelloffen und kostenlos sind. Ihre Regeln landen je nach Integration im Kontext des Modells und verbrauchen damit zusätzliche Eingabetokens. Führt der Agent anschließend Scanner aus, bewertet deren Ergebnisse, bessert den Code nach und startet die Tests erneut, entstehen weitere Ausgaben und zusätzliche Iterationen.
Das ist zunächst kein Nachteil, sondern der Preis für gründlicheres Arbeiten. Ein zweiter Blick kostet auch bei menschlichen Entwicklern Zeit. Unpraktisch wird es, wenn fünf Werkzeuge dieselben Regeln in leicht unterschiedlichen Worten mitbringen. Dann wächst der Kontext, Warnungen wiederholen sich und der Agent diskutiert womöglich länger über die Lösung, als er an ihr arbeitet.
CodeGuard verfolgt bei seiner Skill Variante deshalb einen sinnvollen Ansatz: Es werden nur die zur Aufgabe passenden Regeln geladen. Solche progressive Auswahl spart Kontext gegenüber einem riesigen Regelwerk, das bei jeder kleinen Änderung komplett mitgeschickt wird. Trotzdem sollte man den Verbrauch beobachten und die Sicherheitskette passend zum Risiko wählen. Eine private Einkaufsliste braucht kein Raumfahrtprogramm. Ein öffentliches Kundenportal braucht mehr als Vertrauen in den Vibe.
Secure Vibe Coding ist ein Prozess, kein Modus
Secure Vibe Coding kann es also durchaus geben. Nur ist „secure“ kein Schalter im Chatfenster und auch kein einzelnes Plugin. Es entsteht aus klaren Anforderungen, möglichst einfacher Architektur, guten Agentenregeln, automatischen Prüfungen und Schutzmaßnahmen im laufenden Betrieb.
Für Prototypen bleibt Vibe Coding großartig. Ideen werden greifbar, kleine Werkzeuge entstehen schneller und auch Menschen ohne jahrelange Programmiererfahrung können Lösungen bauen. Sobald aus dem Experiment ein echtes Produkt wird, sollte allerdings jemand die Musik kurz leiser drehen und nachsehen, was da eigentlich alles mitgebaut wurde.
Der beste Vibe ist schließlich der, bei dem die Anwendung am Montag noch funktioniert und am Wochenende niemand wegen eines geleakten API Schlüssels angerufen wird.
Quellen und Projekte
A thoroughly well-researched and insightful analysis on „footballbros.us.com“. Thank you for sharing such a constructive piece—definitely a valuable reference for anyone following this field.