KI-generierte Software vor dem Produktivbetrieb prüfen

Ihre KI-generierte Anwendung soll echte Nutzer oder produktive Daten erhalten? Der Production Readiness Audit schafft eine priorisierte Baseline. Soll Ihr Team danach weiter mit KI entwickeln, kann der AI Code Review Retainer die relevanten Änderungen laufend prüfen.

Eine Anwendung kann im Demo-Modus vollständig wirken und trotzdem noch nicht produktionsreif sein. Das gilt für Software aus Lovable, Cursor, Claude Code, Bolt, Replit, v0 und anderen KI-gestützten Entwicklungswegen ebenso wie für klassisch entwickelten Code.

Der Unterschied wird sichtbar, sobald echte Nutzer, getrennte Mandanten, Kundendaten, Zahlungen oder verbindliche Verfügbarkeitsanforderungen hinzukommen. Dann muss nicht nur der gewünschte Ablauf funktionieren. Auch unerlaubte Abläufe, Ausfälle, Fehlkonfigurationen und Wiederherstellung müssen beherrscht werden.

1. Repository und Ausgangsstand sichern

Die Prüfung beginnt nicht mit einem Scanner, sondern mit einem vollständigen und reproduzierbaren Ausgangsstand.

Zu klären sind:

• Liegt der vollständige Code in einem Repository?
• Kann die Anwendung außerhalb des ursprünglichen KI-Builders gebaut werden?
• Sind Lockfiles, Runtime-Versionen und Startkommandos vorhanden?
• Welche Branches und Deployments sind tatsächlich produktiv?
• Gibt es generierte Dateien oder manuelle Änderungen außerhalb von Git?
• Welche bekannten Fehler, Workarounds und offenen Prompts beeinflussen den Stand?

Ein Repository ist nur dann eine verlässliche Quelle, wenn Build und Deployment daraus reproduzierbar entstehen. Läuft die Anwendung nur im Workspace des Builders oder durch undokumentierte Änderungen in einer Plattformoberfläche, ist bereits die Übernahmefähigkeit ungeklärt.

Der Audit sollte auf einem benannten Commit oder Tag arbeiten. So bleibt später nachvollziehbar, auf welchen Stand sich Findings beziehen.

2. System- und Datenwege modellieren

KI-generierter Code wird häufig komponentenweise erstellt. Für den Produktivbetrieb muss daraus ein Systembild entstehen.

Das Systembild enthält mindestens:

• Browser, mobile Clients und administrative Oberflächen
• Frontend, Backend, API-Routen und Serverfunktionen
• Datenbanken, Object Storage und Caches
• Authentifizierungs- und Identitätsanbieter
• Hintergrundjobs, Queues, Cronjobs und Webhooks
• Zahlungsanbieter, E-Mail, Analytics und weitere externe Dienste
• LLM-APIs, Vektordatenbanken und RAG-Datenwege
• Staging-, Produktions- und lokale Umgebungen

Für jeden Datenweg werden Quelle, Ziel, Berechtigung und Datenklasse festgehalten. Das ist besonders wichtig, wenn ein Frontend direkt auf Supabase oder Firebase zugreift. In diesem Modell liegen wesentliche Sicherheitsgrenzen in RLS, Storage Policies, Claims und service-seitigen Rollen, nicht nur in sichtbarem Anwendungscode.

Ein sauberer Review betrachtet außerdem, welche Daten an externe KI-Dienste, Logginganbieter oder Fehleranalysewerkzeuge gesendet werden. Technische Telemetrie kann unerwartet Nutzdaten, Prompts oder Identifikatoren enthalten.

3. Authentifizierung und Autorisierung getrennt prüfen

Ein funktionierender Login beweist nur, dass eine Identität erkannt wird. Er beweist nicht, dass diese Identität nur erlaubte Aktionen ausführen kann.

Die Prüfung muss reale Rollen und negative Nutzerwege abdecken:

1. Kann ein normaler Nutzer administrative Endpunkte direkt aufrufen?
2. Kann eine Objekt-ID geändert werden, um fremde Datensätze zu lesen oder zu bearbeiten?
3. Trennen RLS-Regeln Mandanten auch bei direktem API-Zugriff?
4. Sind Storage-Buckets und Download-URLs passend geschützt?
5. Werden Rollen serverseitig geprüft oder nur im Frontend verborgen?
6. Was passiert mit Sessions nach Passwortwechsel, Rollenentzug oder Deaktivierung?
7. Sind Einladungen, Passwort-Reset und OAuth-Redirects begrenzt?

Bei Multi-Tenant-Produkten werden mindestens zwei Testmandanten und mehrere Rollen benötigt. Nur so lässt sich prüfen, ob Datenzugriff nicht bloß im normalen Happy Path korrekt aussieht.

OWASP ASVS bietet hierfür eine strukturierte Verifikationsgrundlage. Die konkrete Auswahl der Anforderungen richtet sich nach Anwendung und Risiko, nicht nach der Tatsache, dass KI am Code beteiligt war.

4. Dependencies, CVEs und Secrets bewerten

KI-Werkzeuge ergänzen Bibliotheken schnell. Dadurch entstehen häufig doppelte Pakete, unnötige SDKs, veraltete Beispiele oder Abhängigkeiten, deren Funktion niemand im Team erklären kann.

Die Inventur umfasst:

• direkte und transitive Dependencies
• Lockfiles und tatsächlich installierte Versionen
• bekannte CVEs und Herstellerhinweise
• EOL-Versionen von Runtime, Framework und Datenbanktreibern
• ungenutzte oder austauschbare Pakete
• Container-Basisimages und Betriebssystempakete
• Secrets in Git-Historie, Konfiguration und Buildlogs

Eine CVE-Liste ist noch keine Priorisierung. Entscheidend sind eingesetzte Version, erreichbarer Codepfad, Exposition, vorhandene Schutzmaßnahmen und mögliche Auswirkungen. Ein kritischer CVSS-Wert kann in einer nicht verwendeten Funktion liegen; eine niedriger bewertete Schwachstelle kann für einen öffentlich erreichbaren Geschäftsprozess trotzdem dringlich sein.

Offengelegte Secrets werden nicht nur aus der aktuellen Datei entfernt. Sie müssen widerrufen oder rotiert werden, weil sie in Git-Historie, Logs oder Artefakten weiter vorhanden sein können.

5. Geschäftslogik und Schnittstellen testen

Statische Analyse erkennt nur einen Teil der produktrelevanten Fehler. Besonders wichtig sind Abläufe, die Geld, Berechtigungen oder dauerhafte Daten verändern.

Typische Prüffelder sind:

• serverseitige Validierung aller externen Eingaben
• Idempotenz von Webhooks und Zahlungsereignissen
• Signaturprüfung bei eingehenden Webhooks
• Upload-Größe, Dateityp, Dateiname und Malware-Risiko
• Race Conditions bei Buchung, Kontingent oder Statuswechsel
• Fehlerbehandlung und Wiederholung von Hintergrundjobs
• Timeout, Rate Limit und Kostenkontrolle externer APIs
• Prompt Injection und Tool-Berechtigungen bei KI-Funktionen
• sichere administrative Massenaktionen und Exporte

Für kritische Nutzerwege sollten nachvollziehbare Tests existieren. Das müssen nicht sofort hunderte Unit Tests sein. Wichtiger ist, dass Login, Rollenwechsel, Datenzugriff, Zahlung, Export, Löschung und zentrale Geschäftsregeln vor jedem Release überprüfbar sind.

6. CI/CD, Staging, Produktion und Rollback absichern

Ein Produktivsystem darf nicht davon abhängen, dass eine Person den richtigen Button im KI-Builder drückt.

Ein belastbarer Delivery-Weg trennt:

• Entwicklungs-, Staging- und Produktionswerte
• Secrets und Service-Konten je Umgebung
• Datenbankmigrationen und Anwendungsdeployment
• automatische Prüfungen und bewusste Freigaben
• Vorschauumgebungen und produktive Daten

Jeder Release braucht eine eindeutige Version, sichtbare Prüfergebnisse und einen Rückfallweg. Rollback bedeutet nicht immer, nur das alte Image zu starten. Nicht rückwärtskompatible Datenbankmigrationen, neue Queue-Nachrichten oder geänderte Storage-Strukturen benötigen einen eigenen Plan.

Das Team sollte außerdem testen, ob ein neues System aus Repository, Konfiguration und Sicherungen wiederaufgebaut werden kann. Ein Deployment, das nur auf einer gewachsenen Umgebung funktioniert, ist nicht reproduzierbar.

7. Logging, Monitoring, Backup und Restore validieren

Produktionsreife endet nicht beim erfolgreichen Deploy.

Die Betriebsprüfung beantwortet:

• Welche technischen Fehler und Geschäftsereignisse werden protokolliert?
• Werden Secrets oder sensible Daten aus Logs herausgehalten?
• Welche Kernfunktionen werden aktiv überwacht?
• Wer erhält einen Alarm und wer reagiert darauf?
• Welche Daten und Konfigurationen werden gesichert?
• Wie lange werden Sicherungen aufbewahrt?
• Wurde eine Wiederherstellung tatsächlich getestet?
• Welche Ausfall- und Datenverlustziele gelten?

Ein Backup ohne Restore-Test ist nur eine Annahme. Für kleine Anwendungen kann ein dokumentierter Stichprobentest genügen. Für geschäftskritische Systeme braucht es regelmäßige, zum Recovery-Ziel passende Nachweise.

Monitoring muss außerdem mehr als die Startseite prüfen. Eine HTTP-200-Antwort sagt wenig darüber aus, ob Login, Datenbank, Jobs, E-Mail oder Storage funktionieren.

8. Findings priorisieren, beheben und nachtesten

Ein Audit sollte keine ungeordnete Scannerwand liefern. Sinnvoll sind mindestens vier Kategorien:

Zu jedem Finding gehören betroffene Komponente, nachvollziehbares Risiko, empfohlene Maßnahme und Zuständigkeit. Kritische Korrekturen werden nachgetestet. Erst danach ergibt eine Go-live-Entscheidung Sinn.

Der Audit selbst behebt die Probleme nicht automatisch. Soll WZ-IT die Umsetzung übernehmen, lässt sich Software-Wartung oder laufende Weiterentwicklung als separater Korridor ergänzen. Infrastruktur, Monitoring, Backups und Incident-Reaktion werden über Managed Operations abgegrenzt.

Nach dem Go-live weiter mit KI entwickeln

Kontrollierte Entwicklung bedeutet nicht, KI-Werkzeuge zu verbieten. Das Team kann weiterhin Prompts, Agenten und Code-Assistenten nutzen. Die Arbeitsstrecke sollte aber ab dann nachvollziehbar sein:

1. Änderungen landen im Repository.
2. Automatische Tests und Scanner liefern technische Signale.
3. Risikorelevante Änderungen erhalten menschliches Review.
4. Freigegebene Versionen werden reproduzierbar nach Staging ausgerollt.
5. Kritische Nutzerwege werden geprüft.
6. Produktion wird kontrolliert aktualisiert und beobachtet.

Für aktive Produkte kann ein monatlicher oder wöchentlicher Reviewrhythmus verhindern, dass die Baseline innerhalb weniger Releases wieder veraltet. Umsetzung und Betrieb bleiben trotzdem klar getrennte Verantwortungsbereiche.

Quellen

• NIST Secure Software Development Framework, SP 800-218
• OWASP Application Security Verification Standard
• OWASP Top 10
• GitHub: About secret scanning
• UK NCSC: The vibe coding spectrum