Vibe Coding kennt keine Ortsgrenzen: Ein Prototyp entsteht in Leipzig, die Pilotkundin sitzt in Graz und die Entwicklerin arbeitet aus Basel. Damit aus diesem Prototyp eine sichere Anwendung wird, braucht es kein gemeinsames Büro, sondern eine klare Checkliste und jemanden, der den Code mit geschultem Blick prüft. Dieser Beitrag beschreibt, wie das Hardening remote gelingt und welche Schritte Sie dabei nicht auslassen sollten.
Warum ein Vibe-Coding-Prototyp noch kein Produkt ist
Beim Vibe Coding beschreiben Sie, was die Anwendung tun soll, und ein KI-Werkzeug wie Lovable, Bolt, Replit, Cursor oder Claude Code schreibt den Code. Das Ergebnis sieht oft beeindruckend fertig aus. Unter der Oberfläche fehlen jedoch häufig Dinge, die niemand ausdrücklich verlangt hat: Eingabevalidierung, Berechtigungsprüfungen auf dem Server, Fehlerbehandlung, Tests und eine nachvollziehbare Struktur.
Das ist kein Vorwurf an die Werkzeuge. Sprachmodelle optimieren auf das, was im Prompt steht, und im Prompt steht selten, dass ein fremder Nutzer keinen Zugriff auf die Rechnungen anderer Kunden haben darf. Wer einen Prototyp produktiv nutzen will, sollte ihn deshalb systematisch härten, statt auf Glück zu hoffen. Das bedeutet nicht, den Prototyp wegzuwerfen. Meist steckt in ihm bereits eine gute Produktidee, eine brauchbare Oberfläche und viel Wissen über die Bedürfnisse der Nutzer. Die Kunst besteht darin, dieses Fundament zu erhalten und gezielt dort nachzubessern, wo ein Fehler teuer würde.
Die häufigsten Schwachstellen in KI-generiertem Code
In Audits tauchen immer wieder dieselben Muster auf. API-Schlüssel landen im Frontend-Bundle und sind für jeden im Browser sichtbar. Row Level Security in Supabase ist deaktiviert oder so formuliert, dass sie alles erlaubt. Berechtigungen werden nur in der Oberfläche geprüft, nicht im Backend. Abhängigkeiten sind veraltet oder wurden von der KI frei erfunden, was Angreifern die Tür für untergeschobene Pakete öffnet.
Dazu kommen Betriebsprobleme: keine Trennung von Test- und Produktionsdaten, fehlende Backups, keine Protokollierung und keine automatisierten Tests. Bei Anwendungen mit personenbezogenen Daten stellen sich außerdem Fragen der DSGVO, etwa zu Auftragsverarbeitung, Speicherort und Löschkonzept. Werden Sprachmodelle in die App eingebunden, lohnt ein Blick auf die Transparenzpflichten des EU AI Act. Keines dieser Themen ist exotisch, aber in der Summe entscheiden sie darüber, ob eine Anwendung einen ersten Angriff, einen Datenbankfehler oder eine Datenschutzanfrage unbeschadet übersteht.
Hardening-Checkliste für den Weg in die Produktion
Die folgende Reihenfolge hat sich bewährt, weil sie zuerst die gravierendsten Risiken schließt und dann die Grundlage für sichere Weiterentwicklung legt:
- Ziehen Sie alle Geheimnisse aus dem Frontend, rotieren Sie bereits veröffentlichte Schlüssel und verwalten Sie sie künftig als Umgebungsvariablen.
- Aktivieren und testen Sie Row Level Security beziehungsweise serverseitige Berechtigungen für jede Tabelle und jeden Endpunkt mit mindestens zwei Testkonten.
- Validieren Sie alle Eingaben auf dem Server und begrenzen Sie Anfragen pro Nutzer, besonders bei teuren KI-Aufrufen.
- Prüfen Sie Abhängigkeiten auf Existenz, Lizenz und bekannte Sicherheitslücken und richten Sie automatische Updates ein.
- Ergänzen Sie automatisierte Tests für Login, Bezahlung und Datenzugriff und lassen Sie sie bei jedem Pull Request laufen.
- Trennen Sie Entwicklungs-, Staging- und Produktionsumgebung und aktivieren Sie Backups mit getesteter Wiederherstellung.
- Richten Sie Fehlertracking, Logs und Uptime-Monitoring ein und dokumentieren Sie Datenflüsse für die DSGVO.
Weiterentwickeln, ohne neue Lücken zu bauen
Nach dem Hardening geht die Arbeit mit KI-Werkzeugen weiter, aber mit Leitplanken. Eine CLAUDE.md oder AGENTS.md im Repository hält fest, welche Sicherheitsregeln, Architekturentscheidungen und Testpflichten für den Agenten gelten. Code-Reviews durch Menschen bleiben Pflicht, vor allem bei Änderungen an Berechtigungen und Datenmodellen.
neooutput unterstützt beides: mit einem Security-Audit und Production-Hardening Ihres KI-generierten Codes im Rahmen von Deploy, Convert und Scale und mit Agentic-Coding-Workshops, in denen Ihr Team lernt, solche Leitplanken selbst zu setzen. Ein kostenloses 15-Minuten-Erstgespräch klärt, welcher Einstieg zu Ihrem Prototyp passt.
Hardening remote begleiten, für verteilte Teams in DACH
Ein Security-Audit eignet sich hervorragend für die Remote-Arbeit. Sie geben uns Lesezugriff auf das Repository, wir analysieren Code, Konfiguration und Abhängigkeiten und stellen die Ergebnisse in einer Live-Session per Video vor. Die Aufzeichnung und ein schriftlicher Maßnahmenplan stehen danach allen Beteiligten zur Verfügung, auch denen, die beim Termin nicht dabei sein konnten.
Während Ihr Team die Maßnahmen umsetzt, begleiten wir asynchron: Wir prüfen Pull Requests, beantworten Rückfragen und helfen, Regeln in CLAUDE.md oder AGENTS.md so zu formulieren, dass Agenten sie zuverlässig befolgen. Für Teams, die über Deutschland, Österreich und die Schweiz verteilt sind, entsteht so ein gemeinsamer Standard, der unabhängig von Ort und Arbeitszeit funktioniert und neue Kolleginnen und Kollegen schnell abholt. Termine legen wir flexibel, damit sie zu Ihren Sprints passen.
Häufige Fragen
Ist Code von Lovable oder Cursor grundsätzlich unsicher?
Nein, die Werkzeuge erzeugen oft ordentlichen Code. Das Risiko entsteht, weil Sicherheitsanforderungen selten im Prompt stehen und niemand den Code gezielt prüft. Mit einem strukturierten Review und klaren Regeln für den Agenten lässt sich das Niveau deutlich anheben.
Muss ich meinen Prototyp für die Produktion neu schreiben?
In den meisten Fällen nicht. Häufig reichen gezielte Korrekturen an Berechtigungen, Geheimnissen, Tests und Infrastruktur. Ein Neuaufbau lohnt sich nur, wenn Architektur oder Datenmodell grundlegend nicht zum künftigen Einsatz passen.
Wie lange dauert das Hardening eines Vibe-Coding-Prototyps?
Das hängt von Umfang, Datenmodell und vorhandenen Tests ab. Ein erstes Audit zeigt schnell, welche Punkte kritisch sind und welche warten können. Danach lässt sich der Aufwand realistisch planen, oft in mehreren kleinen Etappen statt in einem großen Projekt.
Welche Zugänge brauchen Sie für ein Remote-Audit?
In der Regel genügt Lesezugriff auf das Repository und eine Übersicht über die eingesetzten Dienste wie Supabase oder Hosting. Zugriffe auf Produktionsdaten sind meist nicht nötig. Welche Rechte konkret sinnvoll sind, klären wir im Erstgespräch.