Vibe Coding Security Audit, und laufende Kontrolle, wenn der Code weiterwächst
Vibe Coding bringt Features in Tagen, aber die Sicherheitsentscheidungen treffen die KI-Tools selten mit. Ich mache ein Vibe Coding Security Audit von Auth, RLS, Secrets, Dependencies und Infrastruktur und behalte den Code danach laufend technisch im Blick, statt es bei einem Einmal-Audit zu belassen.
- Baseline ab 790 €
- Feste Monatsabos
- Auth + RLS + CVEs
- Deutscher Ansprechpartner
Direkter Ansprechpartner
Timo Wevelsiep
Softwareentwickler, Cloud-Architekt, Gründer & Geschäftsführer
Ich prüfe Code, Security und Infrastruktur und mache sichtbar, was vor Launch, Kundeneinsatz oder Due Diligence technisch riskant ist.
Ich habe produktive Software-, Infrastruktur- und Cloud-Systeme für Kunden weltweit begleitet, darunter Europa, VAE, Asien, Australien und Amerika: von automatisierten Standortplattformen über Cloud-Migrationen bis zu Remote-Access-Systemen für Industrieanlagen.
Für Fragen wie:
- Ist dieser Release produktionsreif?
- Welche CVEs sind wirklich kritisch?
- Sind Auth, Datenzugriff und Tenant-Isolation sauber?
Was ist ein Vibe Coding Security Audit
Beim Vibe Coding entsteht Code im Dialog mit der KI: Das Team beschreibt, das Tool baut. Das Ergebnis läuft, aber niemand hat bewusst über Zugriffsschutz, Datentrennung oder Abhängigkeiten entschieden. Ein Vibe Coding Security Audit schaut genau auf die Vibe Coding Sicherheit:
Typische Vibe Coding Risiken in KI-gebautem Code
KI-Tools liefern schnell lauffähigen Code, treffen aber selten die Sicherheits- und Betriebsentscheidungen, die eine echte Produktion braucht. Diese Vibe Coding Risiken sehe ich am häufigsten:
- Authentifizierung ohne Rollen- und Rechtekonzept
- Supabase-RLS nicht aktiv oder unvollständig, fremde Daten sichtbar
- API-Endpunkte ohne serverseitige Autorisierung
- Secrets und API-Keys im Frontend oder im Repository
- ungeprüfte Dependencies mit bekannten CVEs
- fehlende oder oberflächliche Tests, Regressionen fallen nicht auf
- kein Monitoring und kein Logging im Fehlerfall
- fehlendes Rate Limiting an offenen Endpunkten
Warum ein einmaliger Audit schnell veraltet
Ein Vibe Coding Security Audit beschreibt einen Zustand zu einem Stichtag. Beim Vibe Coding bewegt sich der Code aber schneller als bei klassischer Entwicklung: Es wird täglich iteriert, jeder Prompt verändert Logik, und Features entstehen in Stunden statt Wochen. Was gestern sauber war, kann morgen schon anders aussehen.
Mit jeder neuen Funktion kommen neue Abhängigkeiten ins Projekt, und in diesen Paketen tauchen laufend neue CVEs auf. Gleichzeitig driftet die Architektur: Eine schnell ergänzte Route umgeht plötzlich die Auth, eine neue Tabelle hat keine RLS-Policy, ein Key landet beim Debuggen im Client. Ein Maßnahmenplan, der vier Wochen alt ist, deckt diese Bewegung nicht mehr ab.
Ein Einmal-Audit ist ein sinnvoller Startpunkt, kein Dauerschutz. Genau danach setze ich an: prüfen, dann den Code laufend technisch im Blick behalten, statt nach jedem größeren Schritt ein neues Gutachten zu beauftragen.
Das Veriploy-Modell: Baseline, Monitoring, Reviews
Statt eines Einmal-Audits arbeite ich in drei Schritten, damit die Sicherheitslage zur Geschwindigkeit des Vibe-Coding-Projekts passt:
- Baseline: einmalige Tiefenprüfung von Auth, RLS, Secrets, Dependencies und Config als Referenzpunkt
- Monitoring: laufende Beobachtung neuer Dependencies und CVEs mit zeitnahem Hinweis bei kritischen Funden
- Reviews: wöchentliche oder monatliche menschliche Durchsicht der Änderungen, je nach Paket
- Risikoampel: ein aktueller Überblick statt eines vier Wochen alten PDFs
- Release-Check: menschliche Einschätzung vor größeren Releases statt eines automatischen Scores
- Async Sparring: direkter Kanal für Fragen zwischen den Reviews
Abgrenzung zum Penetrationstest
Ein Penetrationstest simuliert gezielte Angriffe von außen und sucht ausnutzbare Schwachstellen in einer laufenden Anwendung. Das ist wertvoll, beantwortet aber eine andere Frage als Veriploy.
In einem Vibe Coding Security Audit schaue ich in den Code und die Infrastruktur: Ist die Auth sauber, greifen die RLS-Policies, liegen Secrets offen, sind die Dependencies aktuell. Ich prüfe also die Substanz, nicht nur die Angriffsfläche von außen, und ich tue das laufend statt einmalig.
Beides ergänzt sich gut. Wenn gezielt Angriffe simuliert werden sollen, ist ein Pentest der richtige Baustein. Wenn die Frage ist, ob der schnell wachsende KI-Code dauerhaft tragfähig bleibt, ist Veriploy die laufende technische Aufsicht dafür.
Pakete: Oversight, Guard, Launch
Es startet mit einer einmaligen Baseline, danach wird entschieden, wie eng die laufende Kontrolle sein soll. Die Preise sind fest und transparent.
| Oversight 990 €/Mon | Guard 1.950 €/Mon | Launch 3.900 €/Mon | |
|---|---|---|---|
| Reviews | Monatliche Durchsicht der Änderungen | Häufigere Reviews mit tieferer Einordnung | Wöchentliche Reviews, eng am Release-Takt |
| CVEs und Dependencies | Laufendes Monitoring mit Hinweis bei kritischen Funden | Monitoring plus priorisierte Handlungsempfehlung | Monitoring plus Release-Check vor größeren Deployments |
| Sparring | Async Kanal für Rückfragen | Async Sparring mit kürzerer Reaktionszeit | Enger Austausch, fast wie ein Teil des Teams |
| Passt für | Frühe Produkte mit überschaubarem Tempo | Aktiv genutzte Apps mit echten Nutzern | Schnell wachsende Produkte vor und nach dem Launch |
So läuft der Vibe-Coding-Security-Audit ab
- 01
01 Kostenloser Fit-Check
Kurzes Gespräch, ob die laufende Kontrolle zum Projekt passt: Stack, Tempo der KI-Entwicklung und die größten Sorgen. Ohne Kosten und ohne Verpflichtung.
- 02
02 Scope und Zugänge
Festlegen, was geprüft wird: Repository, Hosting, Datenbank und Auth-Kontext. Read-only-Zugriff reicht, sensible Daten bleiben im eigenen System.
- 03
03 Technische Analyse
Tiefenprüfung von Auth und Rechtekonzept, Datentrennung und RLS, Secrets im Frontend oder Repo, Dependencies mit bekannten CVEs sowie Deployment und Infrastruktur. Bewusst eine Code- und Substanzprüfung, kein Penetrationstest von außen.
- 04
04 Report und Handlungsempfehlungen
Verständlicher Report mit Risikoampel, priorisierten Findings und konkreten Empfehlungen. Klar getrennt, was sofort, was vor dem Launch und was später dran ist.
- 05
05 Nächster Schritt
Baseline als Referenzpunkt, danach optional laufende Kontrolle mit Oversight, Guard oder Launch, damit neue CVEs und Architektur-Drift nicht unbemerkt bleiben.
Viele Projekte starten mit einem Baseline-Review. Wird das Produkt danach weiter mit AI entwickelt, kann ich es laufend begleiten.
Was ich für den Review brauche
- Read-only-Zugriff auf das Repository
- kurze Beschreibung von Stack, Tool und Ziel
- Infos zu Hosting und Deployment
- Datenbank- und Auth-Kontext
- Hinweise auf sensible Daten oder Nutzerrollen
- offene Fragen oder konkrete Sorgen
Was der Review liefert
- verständliche Risikoampel
- Top-Risiken auf einen Blick
- priorisierte Findings
- konkrete Handlungsempfehlungen
- Einordnung: jetzt fixen, vor Launch fixen, später einplanen
- optionale Empfehlung für Oversight, Guard oder Launch
So sieht ein Befund aus
Neue API-Route /api/admin prüft die Rolle nur im Frontend, der Endpunkt selbst ist offen. Empfehlung: serverseitige Autorisierung erzwingen.
Einmaliger Audit oder laufende Kontrolle?
| Einmaliger Audit | Veriploy laufend | |
|---|---|---|
| Zeitpunkt | Momentaufnahme zu einem Stichtag | Fortlaufend, mit jeder neuen Änderung |
| CVEs und Dependencies | Stand des Audit-Tags | Laufendes Monitoring mit Hinweisen |
| Architektur-Drift | Nicht abgedeckt | Riskante Änderungen werden früh kommentiert |
| Vor dem Release | Erneuter Audit nötig | Menschliche Einschätzung im Paket enthalten |
| Einordnung | Maßnahmenplan zum Abschluss | Menschliche Priorisierung statt nur Score |
Häufige Fragen
Was ist ein Vibe Coding Security Audit?
Eine technische Prüfung von KI-gebautem Code und der zugehörigen Infrastruktur: Auth, RLS und Datentrennung, Secrets, Dependencies mit bekannten CVEs sowie Deployment und Monitoring. Ich mache diese Prüfung nicht nur einmal, sondern behalte den Code danach laufend im Blick, weil Vibe-Coding-Projekte sich schnell verändern.
Reicht ein einmaliger Audit nicht aus?
Als Startpunkt ja, als Dauerschutz nein. Beim Vibe Coding kommen mit jedem Feature neue Abhängigkeiten dazu, neue CVEs tauchen laufend auf und die Architektur driftet. Ein Audit beschreibt den Stand von gestern. Ich halte die Risikoampel mit Monitoring und regelmäßigen Reviews aktuell.
Ist das ein Penetrationstest?
Nein. Ich prüfe Repo, Security, RLS, CVEs und Infrastruktur und behalte sie laufend im Blick, statt gezielt Angriffe von außen zu simulieren. Ein Pentest kann das sinnvoll ergänzen. Ich prüfe die Substanz des Codes und ob er produktionsreif bleibt.
Welche Tools deckt ihr ab?
Ich prüfe das Ergebnis, nicht das Tool. Code aus Lovable, Cursor, Claude Code, Bolt, Replit, v0 oder GitHub Copilot lässt sich genauso prüfen wie handgeschriebener Code. Entscheidend ist das Repository, nicht der Generator.
Macht ihr auch die Fixes?
Im Abo nicht. Ich prüfe, priorisiere und erkläre, was zu tun ist. Die Umsetzung läuft separat über Wevelsiep Advisory bzw. WZ-IT oder das eigene Team. So bleibt die Prüfung unabhängig von der Umsetzung.
Was kostet das?
Der Einstieg ist fest kalkuliert: Baseline 790 € einmalig. Laufende Kontrolle startet bei 990 € pro Monat (Oversight), weiter mit Guard 1.950 € und Launch 3.900 € pro Monat. Alle Preise netto zzgl. USt. Laufende Pakete starten mit 3 Monaten Mindestlaufzeit, danach monatlich kündbar, sofern nicht anders vereinbart.
- Supabase RLS prüfen lassen, bevor Nutzerdaten über falsche Policies offenliegen
- KI-App prüfen lassen, mit laufender technischer Aufsicht statt einmaligem Bauchgefühl
- CVE-Monitoring für SaaS und AI-gebaute Software, mit menschlicher Priorisierung
- AI-App production-ready machen, technische Risiken vor dem Kundeneinsatz erkennen
Erkennst du diese Risiken in der eigenen App?
Der AI-App Risiko-Self-Check ordnet Produktstatus, Stack, Auth, Datenzugriff, Infrastruktur, CVEs und deinen technischen Kenntnisstand ein und zeigt, ob ein Review sinnvoll ist.
Vibe Coding Security Audit, und danach laufend im Blick.
Der Einstieg erfolgt mit der Baseline, danach laufende Kontrolle im passenden Paket.
Repo-Fit prüfen
Kurz das Projekt beschreiben.
Direkter Kontakt zu mir, kein anonymes Ticket-System. Ich melde mich mit einer ersten Einschätzung und dem passenden Einstieg.
Timo Wevelsiep
Softwareentwickler, Cloud-Architekt, Gründer & Geschäftsführer