Leitfaden
Security-Checkliste vor dem Release einer per Vibe Coding gebauten App
Release an einen gescannten Commit binden, Zugriffsgrenzen und Browser-Assets prüfen, Fehlerfälle und Wiederherstellung testen, bevor Sie eine KI-gebaute App ausliefern.
· 6 Min. Lesezeit · Vom vetkit-Team
Bevor Sie eine per Vibe Coding gebaute App ausliefern, bestimmen Sie den genauen Release-Commit, scannen ihn und testen seine Zugriffsgrenzen, den Umgang mit Secrets und die Fehlerpfade in einer kontrollierten Umgebung. Nutzen Sie die Befunde von vetkit als Belege, die Sie zusammen mit Ihren Tests und Ihrer Deployment-Konfiguration prüfen. Ein bestandener Scan beweist nicht, dass die laufende App sicher oder bereit für das Release ist.
Diese Checkliste ist für die Release-Entscheidung nach dem Code-Review gedacht. Für das zeilenweise Review der Änderungen eines Assistenten beginnen Sie mit der Review-Checkliste für KI-generierten Code. Bewahren Sie die folgenden Belege zusammen mit dem Release auf, damit eine andere Person nachvollziehen kann, was geprüft wurde.
1. Belege an das Release binden
- Notieren Sie den Commit-SHA und das Build-Artefakt, das Sie deployen wollen.
- Prüfen Sie, ob der Audit-Bericht denselben Commit nennt. Ein Bericht für einen älteren Stand des Branches deckt spätere Fixes oder generierte Dateien nicht ab.
- Bauen Sie das Projekt aus dieser Version und führen Sie seine Tests mit einer kontrollierten Konfiguration und synthetischen Daten aus. Bewahren Sie die tatsächlichen Ergebnisse der Befehle auf, einschließlich Fehlschlägen und übersprungener Tests.
2. Prüfen, was tatsächlich gelaufen ist
Der Security Quick Scan umfasst Posture, Secret-Erkennung mit gitleaks und Abhängigkeitsprüfungen mit OSV. Umfassendere Audits können zusätzliche Checks enthalten, soweit Ihr Konto und der gewählte Umfang das zulassen. Die Release-Vorlage von vetkit wählt Checks für Bereiche wie statische Sicherheitsanalyse, Infrastruktur, Workflows und Betriebsfähigkeit aus, umfasst aber nicht jeden verfügbaren Analyzer. So sind etwa secrets-history und llm-app nicht Teil der Auswahl dieser Vorlage.
| Beleg | Was vor dem Release zu prüfen ist |
|---|---|
| Abgeschlossenes Audit | Lesen Sie die Analyzer-Ergebnisse und Warnungen zu Teilberichten, nicht nur den Gesamtscore. |
| Keine Befunde | Stellen Sie sicher, dass der relevante Check gelaufen ist und Ihre Sprache und Ihr Framework unterstützt. |
| Befund als behoben oder unterdrückt markiert | Prüfen Sie den Fix oder die Begründung anhand dieser Release-Version; legen Sie für Ausnahmen eine verantwortliche Person fest. |
| Konfiguration auf Quellcode-Ebene sieht korrekt aus | Prüfen Sie Einstellungen und Verhalten des vorgesehenen Deployments separat. |
Ein Teilbericht bedeutet, dass ein oder mehrere Analyzer nicht abgeschlossen wurden und betroffene Kategorien womöglich unvollständig erfasst sind. Schließen Sie relevante Lücken in der Abdeckung oder dokumentieren Sie die alternative Prüfung, bevor Sie sich auf das Ergebnis verlassen.
3. Zugriffsgrenzen testen
Legen Sie in einer Testumgebung zwei normale Konten und ein Konto mit erweiterten Rechten an. Versuchen Sie, als ein Konto die Datensätze des anderen zu lesen und zu ändern, und rufen Sie geschützte Endpunkte im abgemeldeten Zustand auf. Prüfen Sie, ob der Server nicht autorisierte Operationen ablehnt, auch wenn die Browser-Oberfläche den Button ausblendet. Beziehen Sie Dateidownloads, Exporte und Hintergrundoperationen ein, die dieselben Daten nutzen.
Bei einer App mit Supabase-Backend prüfen Sie die deployten Row-Level-Security- und Storage-Richtlinien mit synthetischen Datensätzen. Die vibe-stack-Regeln von vetkit können unterstützte Quellcodemuster melden, etwa fehlende oder zu freizügige Row-Level-Security-Richtlinien und öffentliche Storage-Buckets. Eine Prüfung des Quellcodes stellt weder die aktuelle Konfiguration Ihrer gehosteten Datenbank fest, noch beweist sie die Mandantentrennung.
4. Secrets und Browser-Assets prüfen
Prüfen Sie Secret-Befunde, öffentliche Präfixe von Umgebungsvariablen und die erzeugten Browser-Assets. Halten Sie Zugangsdaten von Anbietern und Service-Role-Keys auf dem Server. Ein Repository-Audit sieht kein Deployment-Secret, das in den gescannten Dateien nicht vorkommt, und prüft Ihr deploytes Browser-Bundle nicht automatisch. Wurden Zugangsdaten offengelegt, widerrufen oder rotieren Sie sie; die Zeile im Quellcode zu entfernen, genügt nicht. Der Leitfaden zu geleakten Secrets erklärt die getrennten Prüfungen für Repository, Historie und Browser.
5. Abhängigkeiten und KI-Funktionen prüfen
Verwenden Sie das für das Release vorgesehene Lockfile und prüfen Sie die Befunde zu Abhängigkeiten. Ein Abgleich mit bekannten Schwachstellen kann nicht feststellen, ob ein unbekanntes Paket vertrauenswürdig ist. Prüfen Sie neu hinzugekommene Paketnamen und ihre Herkunft; siehe den Leitfaden zu halluzinierten Paketen.
Wenn Ihre App ein LLM aufruft, testen Sie, was bei übergroßen Eingaben, Fehlern des Anbieters und Ausgaben passiert, die eine privilegierte Operation anfordern. Legen Sie serverseitige Nutzungslimits fest und verlangen Sie Autorisierung für Tools, die Daten ändern. Die llm-app-Regeln von vetkit erkennen unterstützte Muster wie Modellausgaben, die als Befehle oder SQL ausgeführt werden, und nutzergesteuerte Aufrufe ohne Limit für Ausgabe-Tokens. Sie belegen nicht, dass jeder Versuch einer Prompt Injection scheitert, und messen nicht Ihre Ausgabenkontrollen in der Produktion.
6. Fehlerpfade und Wiederherstellung testen
- Simulieren Sie einen Timeout einer Abhängigkeit und einen fehlgeschlagenen Schreibvorgang. Prüfen Sie, ob der Nutzer einen hilfreichen Fehlerzustand sieht und ob ein erneuter Versuch die Operation nicht stillschweigend doppelt ausführt.
- Prüfen Sie den Startbefehl für die Produktion, Health-Reporting und Fehlerberichte. Bestätigen Sie mit synthetischen Fehlern, dass die vorgesehene Betriebsperson ein kaputtes Release bemerken kann, ohne dass Zugangsdaten geloggt werden.
- Proben Sie das Rollback- oder Wiederherstellungsverfahren in einer Testumgebung. Wenn das Release gespeicherte Daten verändert, prüfen Sie den Wiederherstellungspfad separat; das Zurücksetzen des Anwendungscodes stellt diese Daten womöglich nicht wieder her.
vetkit enthält statische Regeln für Muster wie ausgehende Aufrufe ohne Timeouts, Entwicklungsserver in Startbefehlen für die Produktion und potenziell destruktive Schema-Synchronisierung. Diese Befunde können Ihr Review lenken, aber das Audit führt diese Fehlerprobe nicht durch und stellt kein Backup für Sie wieder her.
7. Die Release-Entscheidung dokumentieren
Halten Sie Commit, Build-Kennung, Audit-Umfang, Testergebnisse und Deployment-Prüfungen zusammen. Beheben Sie offengelegte Zugangsdaten und nachgewiesenen unautorisierten Zugriff vor dem Release. Für verbleibende Befunde dokumentieren Sie Beleg, Auswirkung, verantwortliche Person für die Entscheidung und Termin für die Nachverfolgung. Wenn ein relevanter Analyzer fehlgeschlagen ist oder ein kritisches Verhalten nie getestet wurde, machen Sie diese Lücke ausdrücklich sichtbar, statt Schweigen als Freigabe zu werten.
Quellen und Grenzen
Geprüft am 1. November 2026 anhand der Quick-Scan-Konfiguration von vetkit, der Audit-Vorlagen, des Berichtsformatierers und der Regeln für vibe-stack, llm-app, Resilienz, Datenzugriff und Betriebsfähigkeit. Der öffentliche Check-Katalog beschreibt die eigenen Regeln und ihre unterstützten Sprachen; die Dokumentation beschreibt die Einrichtung von Audits. Verfügbarkeit der Analyzer, unterstützte Muster, Scan-Limits und der gewählte Umfang beeinflussen die Abdeckung.
Die manuellen Prüfungen hier sind Arbeit für Ihr Team, keine Aussage, dass vetkit Live-Penetrationstests durchführt, die Testsuite Ihrer Anwendung ausführt oder ein Release zertifiziert. Ein Quellcode-Audit kann nicht jede Berechtigung in der Produktion, jede Deployment-Einstellung oder jede fachliche Anforderung verifizieren. Behalten Sie diese Prüfungen in Ihrem Release-Prozess bei, auch wenn der Bericht keine Befunde enthält.