Mit AI gebaut und startklar? Die Launch-Checkliste für produktionsreife Software

AI baut heute in Stunden ein funktionierendes Produkt, für das früher Wochen nötig waren. Der Engpass ist deshalb nicht mehr das Schreiben von Code, sondern das Verifizieren: Funktioniert ist nicht dasselbe wie produktionsreif, und genau dort entscheidet sich, ob ein Launch hält oder kippt.

Inhaltsverzeichnis

• Die Verification Gap
• Warum AI-Code an Production scheitert
• Die Launch-Checkliste
  • Repo & Code
  • Security (Zugriffskontrolle)
  • Dependencies & CVEs
  • Datenbank
  • Infrastruktur
• Tool-Review vs. menschlicher Blick
• So hilft Veriploy
• Fazit
• Quellen

Die Verification Gap

Die Geschwindigkeit, mit der AI-Tools Code produzieren, hat ein neues Problem geschaffen: Es wird mehr Code erzeugt, als sorgfältig geprüft wird. Sonars State of Code Developer Survey (Januar 2026, über 1.100 Entwickler) bringt diese Lücke auf den Punkt. 96 % der Entwickler vertrauen AI-generiertem Code nicht vollständig auf funktionale Korrektheit. Aber nur 48 % prüfen ihren AI-unterstützten Code immer vor dem Commit.[1]

Diese Diskrepanz ist die Verification Gap. Fast alle wissen, dass sie hinschauen müssten. Weniger als die Hälfte tut es konsequent. Sonar beschreibt es als neuen Engpass in der Verifizierungsphase der Softwareentwicklung: Der Wert entsteht nicht mehr durch das Tempo beim Schreiben, sondern durch das Vertrauen beim Deployen.[1]

Dass dieses Problem nicht theoretisch bleibt, zeigt der Blick in die Produktion. In CloudBees' 2026 State of Code Abundance (213 Enterprise-Tech-Leader) berichten 81 %, dass Produktionsprobleme zugenommen haben, die sich AI-generiertem Code zuschreiben lassen. Das Bemerkenswerte: In derselben Studie geben 92 % an, sie vertrauten auf die Produktionsreife von AI-Code.[2] Genau diese Überschätzung ist gefährlich. Wer dem Code mehr vertraut, als er verdient, prüft weniger, und merkt das Defizit erst, wenn es teuer wird.

Auch nationale Sicherheitsbehörden greifen das Thema auf. Der CEO des britischen NCSC, Dr Richard Horne, warnte im März 2026, dass ohne menschliche Prüfung erzeugte unsichere Software Schwachstellen verbreiten könne.[3] Die Konsequenz ist in allen drei Quellen dieselbe: Vor dem Go-live braucht es einen bewussten, menschlichen Verifizierungsschritt. Eine Launch-Checkliste ist genau das, in strukturierter Form.

Warum AI-Code an Production scheitert

AI-Generatoren sind gut darin, Code zu schreiben, der die offensichtliche Anforderung erfüllt. Sie sind schlecht darin, an das zu denken, was nicht im Prompt stand: Berechtigungen, Fehlerfälle, Missbrauch, Betrieb. Veracode hat Code von über 100 LLMs getestet und fand, dass rund 45 % der Code-Samples Security-Tests nicht bestanden und OWASP-Top-10-Schwachstellen einführten.[4] Auffällig dabei: Größere, neuere Modelle schrieben funktional besseren Code, aber nicht sichereren. Mehr Modell-Power schließt die Sicherheitslücke also nicht von selbst.

Die OWASP Top 10:2021 sind ein bewährtes Raster, um die typischen Fehlmuster einzuordnen.[5] Vier Kategorien tauchen bei AI-gebauten Apps besonders oft auf:

• A01 Broken Access Control ist seit 2021 die am häufigsten gefundene Kategorie und der Klassiker bei AI-Code. Generatoren bauen oft das Login (Authentifizierung), aber keine saubere Rollen- und Objektprüfung (Autorisierung). Die Folge: Eingeloggte Nutzer rufen fremde Datensätze über die ID auf (IDOR), Admin-Endpunkte sind ungeschützt erreichbar, oder schreibende API-Routen für POST, PUT und DELETE prüfen keine Berechtigung. Alles explizit von OWASP unter A01 genannt.[6]
• A03 Injection umfasst auch dynamische Queries, in denen Nutzereingaben nicht validiert, gefiltert oder kontextsicher behandelt werden. Der Schutz heißt: Daten von Befehlen trennen und parametrisierte APIs oder ORMs nutzen.[7]
• A05 Security Misconfiguration entsteht, wenn Framework-Defaults unverändert übernommen werden: Fehlerseiten mit Stacktraces, offene CORS, aktive Default-Konfigurationen, fehlendes Hardening, unnötige Features.[8]
• A06 Vulnerable and Outdated Components trifft Apps, deren Abhängigkeiten unbekannt, veraltet oder ungescannt sind. OWASP nennt es explizit verwundbar, wenn nicht regelmäßig gescannt und nicht zeitnah gepatcht wird.[9]
• A09 Security Logging and Monitoring Failures ist der blinde Fleck im Betrieb. AI-Apps protokollieren oft weder Logins noch fehlgeschlagene Logins noch sicherheitsrelevante Ereignisse, und es gibt keine Alarmierung. Angriffe bleiben so schlicht unsichtbar.[10]

Das Muster dahinter ist immer dasselbe: AI baut das Feature, nicht die Betriebsreife. Wer das vor dem Launch nicht aktiv prüft, verlässt sich darauf, dass der Generator an etwas gedacht hat, das nie Teil der Aufgabe war.

Die Launch-Checkliste

Die folgende Checkliste ist nach den fünf Säulen gegliedert, die wir bei Veriploy auch im laufenden Betrieb anschauen. Sie ist bewusst scannbar gehalten: Geh sie durch und markiere ehrlich, was offen ist.

Repo & Code

Security (Zugriffskontrolle)

Hier liegt das größte Risiko. Prüfe Autorisierung getrennt von Authentifizierung:

• Jede lesende und schreibende Route prüft, ob der eingeloggte Nutzer dieses konkrete Objekt sehen oder ändern darf. Nicht nur, ob er eingeloggt ist.
• Admin-Funktionen sind serverseitig gegen die Rolle geprüft, nicht nur im Frontend versteckt.
• IDs in URLs und API-Calls sind nicht durchzählbar nutzbar (Test: fremde ID einsetzen, sollte 403 liefern).

Supabase RLS als konkretes Beispiel: Row Level Security ist Postgres' Mechanismus für zeilenbasierte Zugriffskontrolle. Eine korrekte Policy begrenzt jeden Nutzer auf seine eigenen Zeilen, etwa using ( (select auth.uid()) = user_id ).[11] Der entscheidende Stolperstein: RLS ist nicht global an. Tabellen, die per Table Editor erstellt werden, haben RLS standardmäßig aktiviert, per rohem SQL oder SQL-Editor erstellte aber nicht.[11] Und ohne RLS ist eine im public-Schema exponierte Tabelle für jede Rolle mit passendem Grant, etwa anon, voll zugänglich, also für jeden mit dem öffentlichen Key.[12] Genau dieses Muster führte real zu CVE-2025-48757 (CVSS 9.3): In AI- und Low-Code-generierten Apps (Lovable) gaben Tabellen ohne korrekte RLS unauthentifiziert Daten preis, betroffen waren 303 Endpunkte über 170 Projekte.[13] Wichtig zur Einordnung: Das ist kein Supabase-Bug, sondern fehlende Konfiguration durch Entwickler oder Generator. Checklisten-Punkt: RLS auf allen exponierten Tabellen aktiviert, passende Policies vorhanden, und ein echter Multi-User-Test (Nutzer A darf Daten von Nutzer B nicht sehen).

Zwei wiederkehrende Praxisfehler, die OWASP konzeptionell unter A05 (Hardening) und A04 Insecure Design (fehlende Anti-Automation) einordnet: Secrets im Client-Bundle und fehlende Rate Limits auf Login- und API-Endpunkten gehören vor dem Launch geschlossen.

Dependencies & CVEs

Dependencies scannen ist Pflicht, nicht Kür. Die Werkzeuge liefern in Sekunden eine Liste bekannter Schwachstellen:

Aber: Alerts sehen ist nicht dasselbe wie Risiko verstehen. Severity folgt CVSS,[18] doch ob eine Lücke real ausnutzbar ist, sagt erst der Kontext. Läuft das Paket in Production oder nur als Dev-Dependency? Ist es direkt eingebunden oder transitiv? GitHub liefert dafür Signale wie EPSS (Exploit-Wahrscheinlichkeit in den nächsten 30 Tagen, seit Februar 2025 allgemein verfügbar) und eine Most-important-Sortierung.[19] Und GitHub sagt selbst: „Alerts can't catch every security issue." Nur geprüfte Advisories lösen Alerts aus, und Manifest- sowie Lock-Files müssen aktuell sein.[16] Auto-Patches und Audits sind die Basis, ersetzen aber kein bewusstes Review vor dem Go-live. Genau diese Einordnung, aus 40 Alerts die drei zu machen, die wirklich blockieren, ist der Punkt, an dem ein menschlicher Blick zählt.

Datenbank

• RLS oder äquivalente serverseitige Zugriffskontrolle auf allen Tabellen mit Nutzerdaten (siehe oben).
• Migrations versioniert und reproduzierbar, nicht per Hand in der Konsole gepflegt.
• Indizes auf den Spalten, nach denen die App filtert. AI-Code generiert Queries, selten passende Indizes.
• Keine Produktionsdaten in Test- oder Staging-Umgebungen.

Infrastruktur

Tool-Review vs. menschlicher Blick

AI-Code-Review-Tools sind nützlich. Sie kommentieren Pull Requests, fangen offensichtliche Bugs und machen Stil-Vorschläge. Aber sie sehen genau das, was im PR steht: Code-Diffs. Sie sehen nicht, ob das Backup je wiederhergestellt wurde, ob die Secrets in der Produktionsumgebung korrekt und getrennt liegen, ob die RLS-Policy im echten Multi-User-Fall hält, oder ob ein gefundener Punkt für dein konkretes Geschäft kritisch oder irrelevant ist.

Das ist kein Versagen der Tools, sondern eine Grenze ihrer Bauart. Ein Review-Tool priorisiert Funde nach allgemeinen Heuristiken. Ein Mensch mit Senior-Erfahrung priorisiert nach Business-Risiko: Welcher der 40 Alerts blockiert wirklich den Launch, und welcher kann warten? Genau diese Übersetzung von Scanner-Output in Entscheidung ist das, was ein Tool allein nicht leistet, und worauf das NCSC mit der Forderung nach menschlicher Prüfung zielt.[3]

So hilft Veriploy

Veriploy ist genau dieser zweite, menschliche Blick, aber nicht als teures Einmal-Audit, das nach drei Wochen veraltet ist. AI-gebaute Software ändert sich wöchentlich; eine Momentaufnahme passt dazu nicht. Deshalb ist Veriploy laufende technische Aufsicht: regelmäßiger Blick auf Repo, CVEs und Infrastruktur, priorisierte Risiken und klare nächste Schritte statt einer Scanner-Wand.

Ein sinnvoller Einstieg ist der Preflight-Check: eine schnelle erste Einordnung deiner App. Wer die Tiefe einer initialen Bestandsaufnahme will, startet mit der Baseline und geht dann in laufende Pakete über, vom monatlichen Blick (Watch) über wöchentliches Sparring (Guard) bis zur engen Begleitung produktiver Produkte (Launch). Wie ein Befund konkret aussieht, zeigt der Beispielreport. Fragen vorab klärst du direkt über Kontakt.

Klar abgegrenzt: Veriploy macht deine App nicht „sicher", gibt keine Garantie und ist kein Penetrationstest-Ersatz. Es ist auch keine Feature-Entwicklung. Veriploy schafft Sichtbarkeit und Priorisierung, damit du fundiert entscheidest, was vor dem Launch wirklich erledigt sein muss.

Fazit

Der Engpass beim Bauen mit AI ist nicht mehr das Schreiben, sondern das Verifizieren. 96 % misstrauen dem Code, nur 48 % prüfen ihn konsequent, und 81 % der Tech-Leader sehen mehr Produktionsprobleme durch AI-Code. Eine Launch-Checkliste schließt genau diese Lücke: Zugriffskontrolle vor Login-Glanz, RLS plus echter Multi-User-Test, Dependency-Scan mit kontextbewusster Priorisierung, Secrets aus dem Repo, getestete Backups und Monitoring, das vor dem Kunden alarmiert. AI baut das Feature schnell. Ob es den ersten echten Nutzeransturm übersteht, entscheidet die Verifizierung davor, und die ist menschliche Arbeit, kein Prompt.

Quellen

1. Sonar, „Sonar Data Reveals Critical Verification Gap in AI Coding" (Pressemitteilung, 08.01.2026): https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/
2. CloudBees, „Enterprise Technology Leaders Report Production Failures from AI-Generated Code" (2026 State of Code Abundance, 19.05.2026): https://www.cloudbees.com/newsroom/enterprise-technology-leaders-report-production-failures-from-ai-generated-code
3. NCSC, Dr Richard Horne, „Seize disruptive vibe coding opportunity to make software more secure" (24.03.2026): https://www.ncsc.gov.uk/news/ncsc-ceo-seize-disruptive-vibe-coding-opportunity-to-make-software-more-secure
4. Veracode, „2025 GenAI Code Security Report" (Blog, 30.07.2025): https://www.veracode.com/blog/genai-code-security-report/
5. OWASP Top 10:2021 (Übersicht): https://owasp.org/Top10/2021/
6. OWASP A01:2021 Broken Access Control: https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
7. OWASP A03:2021 Injection: https://owasp.org/Top10/2021/A03_2021-Injection/
8. OWASP A05:2021 Security Misconfiguration: https://owasp.org/Top10/2021/A05_2021-Security_Misconfiguration/
9. OWASP A06:2021 Vulnerable and Outdated Components: https://owasp.org/Top10/2021/A06_2021-Vulnerable_and_Outdated_Components/
10. OWASP A09:2021 Security Logging and Monitoring Failures: https://owasp.org/Top10/2021/A09_2021-Security_Logging_and_Monitoring_Failures/
11. Supabase Docs, Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
12. Supabase Docs, Securing your API: https://supabase.com/docs/guides/api/securing-your-api
13. Matt Palmer, CVE-2025-48757 (Disclosure): https://mattpalmer.io/posts/2025/05/CVE-2025-48757/
14. npm Docs, npm audit (CLI v10): https://docs.npmjs.com/cli/v10/commands/npm-audit
15. Composer Docs, composer audit: https://getcomposer.org/doc/03-cli.md
16. GitHub Docs, About Dependabot alerts: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
17. GitHub Docs, About Dependabot security updates: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
18. GitHub Docs, About the GitHub Advisory Database: https://docs.github.com/en/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/about-the-github-advisory-database
19. GitHub Docs, Prioritizing Dependabot alerts using metrics (EPSS): https://docs.github.com/en/code-security/tutorials/manage-security-alerts/prioritizing-dependabot-alerts-using-metrics
20. OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
21. OWASP CI/CD Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html