Vibe Coding in Produktion bringen: Der Security- und DevOps-Check für KI-gebaute Software

Einer unserer neuen Kunden ist Geschäftsführer in der Ferienimmobilien-Branche. Kein Entwickler im Haus, kein Tech-Team. Trotzdem steht bei ihm ein Intranet mit Schichtplanung, Urlaubsverwaltung und internem Wiki, dazu mehrere Dashboards, die Daten aus über 20 Quellen zusammenziehen. Alles selbst gebaut, mit Claude, Supabase und Vercel. Ehrlich gesagt: Wir haben schon Projekte von echten Teams gesehen, die weniger durchdacht waren.

Und dann kam der Punkt, an dem er sich selbst gestoppt hat. Bevor knapp 30 Mitarbeitende Zugriff bekommen, wollte er es von jemandem prüfen lassen, der das jeden Tag macht: Sieht wirklich jeder nur seine eigenen Daten? Kommt jemand von außen rein, der da nichts zu suchen hat? Hängen Rollen und Rechte an einem sauberen Konzept – oder an ein paar Zeilen, die zufällig funktionieren?

Genau dieser Moment ist das Thema dieses Beitrags. Denn „Vibe Coding” – Software per KI-Prompt statt Zeile für Zeile – bringt tech- und KI-affine Menschen heute erstaunlich weit. Die Grenze liegt fast immer an derselben Stelle: beim Schritt in die Produktion. Sicherheit, Rollen und Rechte, Deployment, Back-ups, DevOps. Dieser Artikel zeigt mit belegten Zahlen, warum dieser Schritt der kritische ist, welche Schwachstellen wir am häufigsten finden, und wie ein sauberer Weg von der selbstgebauten App zum produktiven System aussieht.

Vibe Coding kommt weiter, als viele denken

Vorweg, weil es sonst zu einem billigen „KI-Code ist Müll”-Artikel würde: Was Nicht-Entwickler heute mit Tools wie Claude, Cursor, Lovable oder v0 bauen, ist beeindruckend. Funktionierende Intranets, interne Tools, Prototypen, die echte Prozesse abbilden – in Wochen statt Monaten. Das ist kein Spielzeug, das läuft im Alltag. Wir haben an anderer Stelle beschrieben, wie Nicht-Entwickler mit KI heute Produktivsoftware bauen und warum das ein echter Umbruch ist.

Das Problem ist nicht, dass diese Apps gebaut werden. Das Problem ist der stille Übergang von „läuft bei mir” zu „30 Leute arbeiten damit und es liegen personenbezogene Daten drin”. Genau dort verhält sich KI-generierter Code anders, als es sich anfühlt.

Wo es kippt: die Zahlen zu KI-generiertem Code

KI optimiert auf „funktioniert”, nicht auf „ist sicher”. Und funktionierender Code, der unsicher ist, sieht genauso fertig aus wie sicherer Code. Das ist die gefährlichste Sorte Fehler: die, die man auf den ersten Blick nicht sieht.

Die Datenlage ist inzwischen eindeutig:

• Der 2025 GenAI Code Security Report von Veracode hat 80 Coding-Aufgaben über mehr als 100 Sprachmodelle getestet. Ergebnis: 45 % des generierten Codes enthielt eine Schwachstelle aus den OWASP Top 10. Bei Cross-Site-Scripting lag die Fehlerquote sogar bei 86 %, bei Java über 70 %. KI-Code enthielt in dieser Untersuchung 2,74-mal mehr Schwachstellen als von Menschen geschriebener Code.
• Eine Studie der Carnegie Mellon University fand, dass zwar 61 % des KI-Codes funktional korrekt ist, aber nur 10,5 % einen Security-Review besteht.
• Laut einer Entwicklerbefragung von SonarSource haben 53 % der Entwickler, die KI-Code ausgeliefert haben, später Sicherheitsprobleme in der Produktion entdeckt – nicht im Review, sondern im Live-Betrieb.

Das sind keine Zahlen aus dem KI-Skeptiker-Lager, sondern von Application-Security-Anbietern und Universitäten. Und sie beschreiben Code, der von Profis mit KI geschrieben wird. Bei Vibe Coding ohne Security-Hintergrund fällt der entscheidende Schritt oft ganz weg: Sicherheitsanforderungen werden gar nicht erst formuliert.

Der Klassiker: die Datenbank, deren Türen nie abgeschlossen wurden

Das mit Abstand häufigste Muster, das wir bei KI- und No-Code-gebauten Apps sehen, betrifft die Datenbank. Moderne Stacks wie Supabase machen den Einstieg leicht: Tabelle anlegen, vom Frontend direkt abfragen, läuft. Was dabei gern übersehen wird, ist Row Level Security (RLS) – die Regel, die festlegt, wer welche Zeile lesen und schreiben darf. Ohne aktive RLS-Policies ist eine Tabelle, die vom Browser aus erreichbar ist, für jeden erreichbar.

Wie real das ist, zeigt CVE-2025-48757: Im Mai 2025 fand der Sicherheitsforscher Matt Palmer bei mit Lovable gebauten Apps 303 Endpunkte über 170 Projekte hinweg, deren Datenbanktabellen sich ohne Login allein mit dem öffentlichen Anon-Key auslesen ließen. Abgegriffen wurden E-Mail-Adressen, Telefonnummern, Zahlungsdaten und API-Keys. Und das ist kein Einzelfall: Nach Auswertungen aus dem Umfeld dieser Vorfälle gehen 83 % der Supabase-Datenlecks auf RLS-Fehlkonfigurationen zurück. Eine Analyse von Escape.tech über 5.600 Anwendungen fand über 2.000 ausnutzbare Schwachstellen, darunter 400+ offengelegte Secrets und 175 Fälle mit exponierten personenbezogenen Daten.

Der Kern des Problems ist immer derselbe: eine Datenbank, die funktioniert, weil ihre Zugriffsregeln nie eingeschaltet wurden.

Die sechs Schwachstellen, die wir am häufigsten finden

Über die Datenbank hinaus wiederholen sich bei KI-gebauten Anwendungen dieselben Muster. Diese sechs prüfen wir zuerst:

Das Tückische: Jede dieser Lücken lässt sich mit ein bis zwei Sätzen im Prompt vermeiden – „keine Secrets im Code, alle Keys aus Umgebungsvariablen; prüfe bei jeder Route, ob der eingeloggte Nutzer auf genau diese Daten zugreifen darf”. Nur weiß man das eben, wenn man es weiß. Wer nie eine Anwendung produktiv abgesichert hat, formuliert diese Sätze nicht – und die KI schlägt sie von sich aus meist nicht vor.

Der DACH-Faktor: DSGVO macht aus einem Bug ein meldepflichtiges Ereignis

In Deutschland, Österreich und der Schweiz hat eine offene Datenbank eine zweite Dimension. Sobald personenbezogene Daten – Mitarbeitende, Kund:innen, Gäste – ohne Berechtigung abgreifbar sind, ist das nicht nur ein technischer Fehler, sondern potenziell eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO, zu melden binnen 72 Stunden. Der Bußgeldrahmen reicht bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes.

Dazu kommen die Fragen, die bei mit KI oder No-Code gebauten Apps gern untergehen: Wo stehen die Server? Gibt es einen Auftragsverarbeitungsvertrag (AVV) mit dem Plattformbetreiber? Lassen sich Auskunfts- und Löschansprüche technisch überhaupt erfüllen? Das ist kein Grund, nicht mit KI zu bauen – aber ein starkes Argument dafür, vor dem Rollout jemanden draufschauen zu lassen, der diese Kette kennt. Wie wir Datenschutz und Architektur zusammendenken, zeigt auch unser Beitrag zu KI-Readiness im Unternehmen.

Von der App zum produktiven System: das DevOps-Handwerk

Sicherheit ist die eine Hälfte. Die andere ist der laufende Betrieb. Denn nach dem Rollout ist die Anwendung nicht fertig – sie fängt an zu leben. Neue Features, neue Schnittstellen, Schema-Änderungen. Wer dann alles direkt auf die Hauptumgebung pusht, hat ein Problem, besonders bei der Datenbank. „Claude, sei vorsichtig” ist keine Strategie für ein Produktivsystem, mit dem 50 Leute täglich arbeiten.

Die gute Nachricht: Die Softwarewelt hat das längst gelöst. DevOps als Disziplin gibt es seit 2009, und die Prinzipien sind unabhängig davon, ob ein Mensch oder eine KI den Code schreibt. Was bei uns Standard ist, wenn aus einem MVP ein Produktivsystem wird:

• Branches und Worktrees – die Basis, die selbst Vibe-Coder hinbekommen.
• CI/CD: Änderungen werden automatisch gebaut und getestet, bevor sie live gehen.
• Getrennte Umgebungen: erst Staging, befüllt mit einem aktuellen Dump aus der Produktion, dann Produktion.
• Automatische DB-Backups vor jedem größeren Deployment, damit Rollbacks in Minuten statt Stunden gehen.
• Saubere Architektur ab Tag 1, API-first, klar getrennte Domänen.
• Logs und Monitoring, die auch wirklich jemand anschaut.
• Kleine Pieces deployen statt des großen Rundum-Features: eine Änderung nach der anderen, deployen, testen, weiter. Geht etwas schief, ist der Schaden klein und der Rollback so schnell, dass es im laufenden Betrieb niemand merkt.

Bei Tests lohnt sich Augenmaß: Tausend Unit-Tests für jede Kleinigkeit bringen wenig, End-to-End-Tests vor dem Rollout dagegen viel – und danach selbst durchklicken, denn Edge Cases sieht man erst da. Ein Punkt, der bei KI-Entwicklung gern vergessen wird: die CLAUDE.md bzw. AGENTS.md pflegen, Learnings und Post-Mortems eintragen. Dann macht das Projekt die gleichen Fehler nicht zweimal. Dieses Vorgehen ist Teil dessen, was wir als Forward Deployed Engineering verstehen: nah an der Codebase des Kunden, mit dem Handwerk, das ein System auch in sechs Monaten noch am Laufen hält.

Wie produktionsreif ist deine Anwendung?

Bevor du entscheidest, ob deine selbstgebaute Anwendung bereit für den Rollout ist, mach den schnellen Selbstcheck. Er ersetzt keinen Audit, gibt dir aber ein ehrliches Gefühl dafür, wo du stehst:

Wo die Grenze verläuft – und warum sie kein Widerspruch ist

Nichts an diesem Artikel spricht gegen Vibe Coding. Im Gegenteil: Wer tech- und KI-affin ist, sollte bauen. Der Kunde aus dem Einstieg hat genau das Richtige getan – er hat den Punkt selbst erkannt, statt live zu schalten, zu hoffen und erst zu kommen, wenn es brennt. Die eigentliche Kompetenz ist nicht „alles selbst können”, sondern zu wissen, wo die eigene Kompetenz endet.

Grob gesagt verläuft die Grenze dort, wo aus einem persönlichen Tool ein System mit mehreren Nutzern, echten Daten und Verantwortung wird. Ab da lohnt es sich, jemanden reinzuholen – für den einmaligen Security- und Produktions-Check, oder für die Begleitung beim Schritt in den stabilen Betrieb.

Genau das machen wir bei TAISC: Wir prüfen mit KI gebaute Anwendungen auf Datenbank-Zugriffe, Login, Rollen und Rechte sowie die kritischen Schnittstellen, und begleiten den Weg vom MVP zum produktionsreifen System mit Security, DevOps und sauberer Architektur. Nicht, um das Selbstgebaute zu ersetzen, sondern um es tragfähig zu machen.

Häufige Fragen

Häufige Fragen

Ist mit KI oder No-Code gebaute Software grundsätzlich unsicher?

Nein. Unsicher ist nicht die Methode, sondern der fehlende Schritt: Sicherheitsanforderungen werden beim Vibe Coding oft gar nicht erst formuliert. Studien zeigen, dass rund 45 % des KI-generierten Codes eine OWASP-Top-10-Schwachstelle enthält – das lässt sich mit den richtigen Vorgaben und einem Review vor dem Rollout aber gezielt beheben.

Was ist die häufigste Sicherheitslücke bei mit KI gebauten Apps?

Eine offene Datenbank durch fehlende Row Level Security (RLS). Ist die Tabelle vom Browser aus erreichbar, aber ohne aktive Zugriffsregel, kann sie praktisch jeder auslesen. Beim Lovable-Vorfall (CVE-2025-48757) waren so Daten aus über 170 Projekten ohne Login abgreifbar, und rund 83 % der Supabase-Datenlecks gehen auf RLS-Fehler zurück.

Woran erkenne ich, dass meine Anwendung einen professionellen Check braucht?

Sobald mehrere Personen darauf zugreifen, personenbezogene Daten verarbeitet werden oder die App geschäftskritisch wird. Spätestens dann sind Rollen und Rechte, Datenbank-Zugriffe, Secrets-Handling und DevOps-Grundlagen relevant – also genau vor dem Rollout an ein ganzes Team.

Muss ich meine mit KI gebaute App wegwerfen und neu bauen lassen?

In den seltensten Fällen. Meist geht es darum, das Bestehende abzusichern und produktionsreif zu machen: RLS und Autorisierung nachziehen, Secrets sauber trennen, Staging- und Backup-Prozesse einrichten. Das ist deutlich günstiger als ein Neubau und erhält die Arbeit, die schon drinsteckt.

Was kostet ein Security- und Produktions-Check bei TAISC?

Das hängt vom Umfang der Anwendung und der Kritikalität ab. Im kostenlosen Erstgespräch schauen wir uns den konkreten Stand an und sagen, welche Punkte vor einem Rollout zwingend sind und welche später kommen können.

Fazit

Vibe Coding hat die Frage verschoben. Sie lautet nicht mehr „kann ich das selbst bauen?”, sondern „ist das, was ich gebaut habe, bereit für echte Nutzer und echte Daten?”. Die Zahlen sind deutlich: KI-Code ist funktional stark, aber sicherheitstechnisch unzuverlässig, und die häufigste Lücke – die offene Datenbank – kostet im DACH-Raum schnell mehr als nur Nerven. Der Weg ist nicht, weniger mit KI zu bauen, sondern den letzten Schritt bewusst zu gehen: Security, Rollen und Rechte, DevOps.

Du hast selbst etwas gebaut und willst wissen, ob es den Weg in die Produktion überlebt? Buche ein unverbindliches Erstgespräch – wir schauen gemeinsam drauf, bevor 30 Leute Zugriff bekommen.