Audit von Vibe-Coded Software: Was vor dem Launch zu prüfen ist

Du hast dich per Prompt zu funktionierender Software gebracht. Sie meldet Nutzer an, zeigt die richtigen Screens und sieht in der Demo gut aus. Wenn aber niemand die Implementierung geprüft hat, bleiben wichtige Annahmen ungetestet. Bevor echtes Geld, personenbezogene Daten oder viele Nutzer davon abhängen, verdienen Code und Betriebsumgebung eine risikobasierte Prüfung.

Das ist kein Argument gegen das Bauen mit KI. KI-gestützte Werkzeuge können den Weg zum Prototyp verkürzen. Für Produktionsreife gelten trotzdem dieselben Praktiken sicherer Softwareentwicklung wie bei anderer Software. Das NIST Secure Software Development Framework ordnet diese in Vorbereitung, Schutz der Software, sichere Entwicklung und Reaktion auf Schwachstellen.

Was ist ein Vibe-Coded-Audit?

Ein Vibe-Coded-Audit ist eine strukturierte, risikobasierte Prüfung eines KI-gestützten Systems über seine sichtbaren Features hinaus. Ein Feature-Review fragt, ob das Produkt tut, was Nutzer erwarten. Ein Audit fragt außerdem, wer Datensätze lesen oder ändern darf, was beim Ausfall einer Abhängigkeit passiert, wo Zugangsdaten liegen, wie doppelte Requests behandelt werden und welche Nachweise einen sicheren Release stützen.

Manche Fehler erscheinen nicht im Happy Path. Beispiele sind ein Netzwerkausfall, ein wiederholter Zahlungs-Request oder eine geänderte Objekt-ID, mit der auf ein fremdes Konto zugegriffen wird. Code-, Konfigurations- und gezielte Testprüfungen helfen, solche Bedingungen vor dem Launch sichtbar zu machen. Der OWASP Application Security Verification Standard 5.0 bietet eine aktuelle Grundlage zum Prüfen technischer Sicherheitskontrollen von Webanwendungen.

Was sollte die Prüfung abdecken?

Der genaue Umfang hängt von Architektur und Risikoprofil ab. Das sind übliche Prüffelder, keine Behauptung, dass jede KI-gestützte Codebasis dieselben Defekte enthält.

• Authentifizierung und Autorisierung. Serverseitige Kontrollen müssen verhindern, dass ein Nutzer Ressourcen eines anderen liest oder ändert. Broken Access Control steht im OWASP Top 10:2025 weiterhin an erster Stelle. Das macht das Thema zu einer sinnvollen Priorität, belegt aber nicht, dass es in einem konkreten Audit das häufigste Finding ist.
• Datenintegrität. Transaktionsgrenzen, Constraints, Idempotenz und Wiederherstellung prüfen, damit Teil-Writes oder doppelte Requests keinen inkonsistenten Zustand hinterlassen.
• Zugangsdaten und Konfiguration. Nach Secrets in Client-Bundles, Repositories, Logs und Build-Ausgaben sowie nach zu breiten Runtime-Berechtigungen suchen.
• Fehler- und Recovery-Pfade. Timeouts, nicht verfügbare Abhängigkeiten, leere Ergebnisse, Retries und nutzerseitige Wiederherstellung testen, statt nur erfolgreiche Aufrufe abzudecken.
• Performance und Kapazität. Query-Muster prüfen und repräsentative Lasten messen. Ein Muster kann mit Demo-Daten funktionieren und bei größerem Umfang langsam oder teuer werden. Die Schwelle muss gemessen, nicht geraten werden.
• Abhängigkeiten und Lizenzen. Komponenten inventarisieren, bekannte Schwachstellen und Wartungsstatus prüfen sowie Lizenzpflichten mit Verteilung und Nutzung abgleichen. NIST SP 800-204D nennt ausdrücklich Dependency-Reviews und Kontrollen, die Secrets aus Commits fernhalten sollen.
• Testnachweise. Vorhandene Unit-, Integrations-, Security- und Acceptance-Tests bewerten. Die Abdeckung variiert je Projekt. Entscheidend sind Nachweise für das risikoreichste Verhalten, nicht ein angenommener Prozentsatz.

"Eine polierte Demo zeigt sinnvoll, dass der Happy Path funktioniert. Für einen Launch braucht es zusätzlich Nachweise zu Zugriffskontrolle, Fehlerbehandlung, Datenintegrität und Wiederherstellung."

Welche Findings blockieren den Launch und welche können warten?

Die Severity sollte Auswirkung, Wahrscheinlichkeit, Exposition und vorhandene Schutzmaßnahmen berücksichtigen. Wir nutzen drei praktische Planungskategorien und dokumentieren die Begründung jedes Findings.

• Blocker. Ein glaubhafter Pfad zu offengelegten Kundendaten, unautorisierten Geldbewegungen, nicht wiederherstellbarer Korruption oder einem ähnlich schweren Ergebnis kann rechtfertigen, den Launch bis zur Behebung oder Eindämmung zu verschieben.
• Hoch. Eine folgenreiche Schwäche mit relevanter Exposition sollte oft vor einem breiteren Rollout behoben werden, auch wenn sie noch keinen Incident verursacht hat.
• Cleanup. Wartbarkeits- oder Konsistenzarbeit mit geringerem Risiko lässt sich meist planen, solange sie sich nicht mit anderen Schwächen zu einem größeren Risiko verbindet.

Die Einstufung hängt vom Kontext ab. Derselbe Defekt kann in einem internen Read-only-Tool anders priorisiert werden als in einem öffentlich erreichbaren Zahlungsprodukt.

Was bekommst du tatsächlich aus dem Audit?

Das vereinbarte Statement of Work sollte die Deliverables festlegen. Wavect schlägt typischerweise einen Findings-Report mit Problem, Severity, Nachweis und empfohlener Maßnahme vor. Ist Remediation enthalten, kann der Scope auch einen reparierten Branch und fokussierte Regressionstests umfassen. Dass jedes Finding oder jeder Refactor enthalten ist, sollte ohne entsprechende Zusage im Angebot nicht angenommen werden. Die Mechanik eines Hardening-Durchgangs erklären wir in QA für KI-generierten Code.

Audit, volles QA oder Rebuild: Was brauchst du?

Das sind verschiedene Aufträge. Die passende Wahl folgt aus Zustand und Geschäftsrisiko des Systems.

Bewegt das geprüfte Produkt Geld, geht es als Nächstes um die Reihenfolge der Fixes bei kontrollierten Live-Payment-Pfaden. Unsere anonymisierte Fallstudie zur Fintech-Architektursanierung zeigt eine projektspezifische Reihenfolge für typisierte Grundlagen, Autorisierung, Idempotenz, Webhooks und Release-Gates ohne automatischen Komplett-Rebuild.

• Audit. Passend, wenn das Produkt weitgehend funktioniert und vor Launch, Wachstum oder Zahlungsverarbeitung zunächst eine begrenzte Risikobewertung gebraucht wird.
• Volles QA. Passend, wenn das Produkt einen laufenden Prozess aus Tests, Reviews, Release-Prüfungen und Hardening über mehrere Änderungen hinweg braucht.
• Rebuild. Zu prüfen, wenn Nachweise zeigen, dass Kern-Constraints, Architektur oder wiederholte Muster eine gezielte Sanierung unverhältnismäßig riskant oder teuer machen. Der Vergleich sollte Migrationsrisiko und den Erhalt funktionierenden Verhaltens einbeziehen. Ein Rebuild ist nicht automatisch billiger.

Was kostet ein Vibe-Coded-Audit und wie lange dauert es?

Mit Stand 2. September 2026 nutzt Wavect für diesen Service eine Planungsspanne von einigen Arbeitstagen bis ungefähr zwei Wochen. Das ist eine eigene Planungsspanne, kein Branchenbenchmark und kein fixes Versprechen. Größe, Architektur, Dokumentation, Deployment-Zugriff und Sensibilität von Daten- und Geldflüssen können den Scope verändern. Deliverables, Preis und Zeitplan bestätigen wir nach einem ersten Blick im Angebot. Das Audit ist ein Einstieg in unseren Software-QA-Service.