Die Vibe-Code-Production-Readiness-Checkliste

Wenn du etwas mit Lovable, Cursor, Claude Code, Bolt, v0, Replit oder konventionellen Werkzeugen gebaut hast und echte Nutzer es gleich verwenden, nutze dies als Erstprüfung. Es ist kein vollständiger Produktionsreife- oder Sicherheitsstandard. Passe die Prüfungen an Architektur, Daten, Bedrohungsmodell, Regulierung und möglichen Schaden an. Eine Regel: Eine visuelle Kontrolle ist keine Autorisierungsgrenze; vertrauenswürdige Durchsetzung muss dort erfolgen, wo die geschützte Aktion oder die Daten kontrolliert werden.

Das ist kein Seitenhieb auf Vibe-Coding. KI-unterstützter und von Menschen geschriebener Code brauchen dieselben evidenzbasierten Engineering-Kontrollen. Die Checkliste wurde am 2. September 2026 gegen OWASP ASVS, die OWASP API Security Top 10 und das NIST SSDF geprüft.

Woran erkenne ich, ob meine vibe-codete App produktionsreif ist?

Nutze die zehn Prüfungen zur Triage und ergänze architekturspezifische Anforderungen. Eine Pass-Bedingung braucht Nachweise, aber auch zehn bestandene Prüfungen beweisen keine Produktionsreife. Risiko, Ausnutzbarkeit, Exposition und Auswirkung bestimmen die Priorität; die Nummerierung ist keine Rangfolge nach Incident-Häufigkeit.

Die Checkliste

1. Autorisierung auf dem Server. Prüft der Server bei jedem Endpoint und jedem Datenlesen, wer fragt und ob er darf? Eine Frontend-Prüfung zählt nicht. Pass: ändere eine User-ID in einem Request und bestätige, dass du eine Ablehnung bekommst, nicht die Daten von jemand anderem.
2. Tenant- und Row-Isolation. Wenn die App Multi-Tenant ist, kann ein Account physisch die Records eines anderen erreichen? Pass: Isolation wird auf Datenbank- oder Query-Ebene erzwungen, nicht in App-Logik, die du auf jedem Endpoint hinzufügen musst.
3. Keine vertraulichen Secrets auf dem Client. Stecken privilegierte API-Schlüssel, Zugangsdaten oder Bearer-Tokens in Client-Bundle, Logs, Build-Artefakten oder Repository-Historie? Manche öffentlichen Kennungen und veröffentlichbaren Schlüssel sind für Clients gedacht, brauchen aber Least Privilege und Autorisierung auf Server- oder Datenebene. Rotiere offengelegte vertrauliche Zugangsdaten und prüfe den Widerruf.
4. Input- und Output-Validierung an Vertrauensgrenzen. Erzwingen APIs, Queues, Webhooks, Datei-Parser und nachgelagerte Integrationen Schema, Größe, Typ, Encoding und Geschäftsregeln? Client-Validierung hilft der Bedienbarkeit, ist aber keine Sicherheitsgrenze. Teste malformierte, übergroße und feindselige Eingaben sowie unerwartete Upstream-Antworten.
5. Fehlerpfade abgedeckt. Wenn ein externer Call in einen Timeout läuft, fehlschlägt oder leer zurückkommt, degradiert die App kontrolliert? Pass: zwing jeden externen Call zum Fehlschlag und bestätige, dass der Screen nicht mit einer unbehandelten Exception weiß wird.
6. Queries, die skalieren. Werden Datenbank-Calls in einem Render geloopt oder ganze Tabellen geladen, nur um Zeilen zu zählen? Pass: unter realistischen Datenmengen profiliert, N+1-Queries und unbegrenzte Reads entfernt.
7. Concurrency, Replay und Idempotenz. Identifiziere Vorgänge, bei denen doppelte oder parallele Ausführung Schaden verursacht, etwa Zahlungen, Bestand, Berechtigungen, Jobs oder externe Nebenwirkungen. Nutze je nach Workflow Idempotency Keys, Uniqueness, Locks, Transaktionen, Reihenfolge oder Deduplizierung. Nicht jede Zustandsänderung sollte blind wiederholbar sein.
8. Wiederherstellbare Daten und Konfiguration. Definiere Recovery-Ziele für Datenbanken, Objektspeicher, Identity-Konfiguration, Secrets und Infrastrukturzustand. Versioniere Migrationen, automatisiere Backups, schütze sie vor derselben Fehlerdomäne und teste Wiederherstellung plus Abgleich.
9. Dependencies und Lizenzen verwaltet. Inventarisiere direkte und transitive Komponenten, Versionen, Herkunft, Supportstatus, Schwachstellen und Lizenzpflichten. Ein Scannerfund ist Input für Ausnutzbarkeits- und Geschäftsrisikoanalyse, kein automatisches Bestehen oder Durchfallen.
10. Angemessene Regressionsevidenz existiert. Führe bei jeder relevanten Änderung automatisierte Tests und weitere Prüfungen aus, die kritisches Verhalten, Autorisierung, Fehlerpfade, Migrationen und Integrationen abdecken. Keine Suite kann garantieren, dass die nächste Änderung nichts Funktionierendes bricht. Testgetriebene Entwicklung ist eine nützliche Praxis.

"KI-generierter Code ändert nicht, welche Produktionsnachweise du brauchst. Beginne mit Autorisierung, Isolation, Secrets, Validierung, Recovery und Verifikation und erweitere die Prüfung dann um die tatsächlichen Bedrohungen und Pflichten des Systems."

Welche Punkte blockieren einen Launch?

Nicht alle zehn sind gleich. Sortiere deine Fehlschläge in drei Buckets, damit du das Richtige zuerst behebst, statt an der ganzen Liste zu erstarren.

• Blocker. Ein plausibler Pfad zu inakzeptablem Schaden ohne wirksame Kontrolle oder Recovery, etwa unbefugter Zugriff auf sensible Daten, unsichere privilegierte Aktionen, doppelte Abbuchungen oder nicht wiederherstellbare Korruption.
• High. Eine wesentliche Schwäche, deren Wahrscheinlichkeit oder Auswirkung vor der geplanten Exposition behandelt werden muss, etwa ausnutzbare anfällige Komponenten oder ungetestete kritische Fehlerpfade.
• Geplante Behandlung. Geringere Restrisiken mit Verantwortlichem, Frist, Monitoring und ausdrücklicher Akzeptanz durch die verantwortliche Entscheidungsperson. Fehlende Tests oder Recovery-Nachweise können bei kritischen Funktionen trotzdem Blocker sein.

Der Sinn der Aufteilung ist Ehrlichkeit über Dringlichkeit. Verkleide keine planbare Wartungsaufgabe als Blocker, und lass keinen echten Blocker in einer langen Liste verschwinden.

Kann ich die KI nicht einfach bitten, das zu beheben?

KI kann Code prüfen, Tests erzeugen, Datenflüsse verfolgen und Fixes vorschlagen. Ihre Funde hängen jedoch von Repository-Zugriff, Werkzeugen, Prompts, Modellverhalten und Spezifikationsqualität ab. Sie kann systemübergreifende Annahmen übersehen und zugleich False Positives oder unsichere Patches erzeugen. Nutze sie als einen Reviewer neben Threat Modeling, automatisierter Analyse, Dependency-Inventar, dynamischen Tests und qualifizierter menschlicher Prüfung. So betreiben wir individuelle Softwareentwicklung.

Was kostet es, die ganze Liste abzuarbeiten?

Das hängt davon ab, was fehlschlägt und wie viel Geld oder sensible Daten das Produkt berührt. Wir brechen die typischen Aufwandsspannen und wo die Zeit tatsächlich hingeht in was es kostet, eine vibe-codete App produktionsreif zu machen auf. Die Kurzfassung: das Audit, das diese Checkliste durchläuft, ist der günstige Teil, und es sagt dir die Größe des Hardenings, bevor du dich darauf festlegst. Das ist das Front-End unseres Software-Quality-Assurance-Service.