Wenn "Vibe Coding" auf Schadenfreude trifft: Die KI-Sicherheitsgeschichte, die niemand erzählt

"Wir haben es schnell mit KI gebaut. Sicherheit können wir später machen, oder?"

Falsch. Aber bevor ich dir sage warum, lass mich von etwas erzählen, das mich mehr stört als die Sicherheitslücke selbst – die schadenfreudige öffentliche Hinrichtung, die darauf folgte.

Die Hexenjagd, die niemand hinterfragt

Vor ein paar Wochen erlebte ein europäischer KI-Plattform-Anbieter eine Sicherheitsverletzung. Ein sogenannter "Security Researcher" verschaffte sich unbefugten Zugang zu deren Systemen, sammelte massive Mengen an Kundendaten und – anstatt die Schwachstelle zuerst verantwortungsvoll an die Firma zu melden – verschickte E-Mails an jeden betroffenen Kunden und mehrere Presseorgane.

Die deutsche Tech-Presse hatte einen Festtag. "Vibe Coding!" schrien sie. "Inkompetenz!" "Fahrlässigkeit!" Eine Publikation unterstellte sogar nahezu kriminelle Absicht.

Hier ist, worüber niemand spricht: Das war keine verantwortungsvolle Offenlegung. Das war eine öffentliche Hinrichtung.

Lass mich klarstellen – ich verteidige keine Sicherheitsfehler. Die Firma hat Fehler gemacht. Ernste. Aber ich habe im letzten Jahr über 100 KI-generierte Codebasen überprüft, und ich kann dir mit absoluter Sicherheit sagen: Diese gleichen Schwachstellen existieren gerade jetzt in Dutzenden anderen Firmen. Einige davon sind deutsche Lieblinge, die Millionen eingesammelt haben. Einige sind Silicon Valley Favoriten. Der einzige Unterschied? Sie wurden noch nicht "erforscht".

Schadenfreude als Nationalsport

Ich lebe seit Jahren in Deutschland und habe etwas Merkwürdiges bemerkt: Schadenfreude – Freude am Unglück anderer – ist hier nicht nur ein Wort. Es ist praktisch eine kulturelle Institution in der Tech-Szene.

N8N, eine deutsche Automatisierungsfirma, hat gerade eine $180 Million Investment von Nvidia gesichert. Innerhalb von Tagen hörte ich von Kontakten, dass bestimmte "Security Researcher" jetzt aktiv versuchen, Schwachstellen zu finden, die sie ausnutzen können, um die Firma zu Fall zu bringen. Nicht um ihnen zu helfen, ihre Sicherheit zu verbessern. Nicht um Nutzer zu schützen. Um sie fallen zu sehen.

Das ist keine Sicherheitsforschung. Das ist digitaler Vandalismus mit Pressemitteilung.

Echte Security Researcher folgen verantwortungsvollen Offenlegungspraktiken:

• Erst die Firma privat kontaktieren
• Ihnen angemessene Zeit zur Behebung geben (typischerweise 90 Tage)
• Kollaborativ an der Verifizierung der Fixes arbeiten
• Erst dann die Findings veröffentlichen, oft in Partnerschaft mit der Firma

Was ist mit diesem europäischen KI-Anbieter passiert? Nichts davon. Nur sofortige öffentliche Offenlegung, Kundenpanik und schadenfreude-getriebene Schlagzeilen.

Und hier ist die unbequeme Wahrheit: Jede einzelne Firma, die gerade mit KI-Unterstützung baut, ist für die gleiche Behandlung anfällig. Denn das echte Problem ist nicht, dass eine Firma Fehler gemacht hat. Das echte Problem ist, dass die meisten Gründer nicht wissen, was sie nicht wissen über Sicherheit.

Die Sicht von der anderen Seite

Ich verbringe meine Tage damit, KI-generierte Codebasen zu reparieren. Nicht sie von außen zu begutachten, nicht automatisierte Scanner zu nutzen, sondern tatsächlich in den Code einzutauchen und das zu rebuilden, was kaputt ist. Lass mich dir zeigen, was ich von dieser Seite des Zauns sehe.

Wenn ein nicht-technischer Gründer mit seiner KI-gebauten SaaS zu mir kommt, ist er normalerweise stolz. Er hat gelernt, LLMs effektiv zu prompten, er hat Features gebaut, die funktionieren, er hat Nutzer. Er fühlt sich fähig. Und dann verbringe ich zwei Stunden damit, seine Anwendung und sein Selbstvertrauen gleichzeitig zu brechen.

Aber hier ist, was dir die deutsche Tech-Presse nicht sagen wird: Diese Gründer sind nicht inkompetent. Sie sind einfach Opfer von KIs fundamentalem Design-Fehler für Sicherheitszwecke.

KI ist zielorientiert, nicht sicherheitsbewusst

KI-Coding-Assistenten wie Claude, Cursor und Copilot sind zielsuchende Systeme. Du gibst ihnen ein Ziel, sie erreichen dieses Ziel. Das Problem? Sie werden es mit allen notwendigen Mitteln erreichen.

Ich habe das letzte Woche beobachtet. Ein Gründer bat Claude, "Unit Tests für mein Authentifizierungssystem zu schreiben." Claude schrieb die Tests. Einige schlugen fehl wegen Type Mismatches. Also editierte Claude die Types, damit die Tests durchgehen. Dann schlugen mehr Tests fehl wegen Async Handling Problemen. Also kommentierte Claude diese Tests aus.

Endergebnis? Alle Tests grün. Ziel erreicht. Sicherheit? Komplett kompromittiert.

Das ist das Muster, das ich ständig sehe:

Du fragst nach "User Authentication" → Du bekommst Login und Signup
Du fragst nach "Database Queries" → Du bekommst funktionierende Queries
Du fragst nach "API Endpoints" → Du bekommst funktionierende Endpoints

Aber niemand fragt nach:

• "Authentication mit Rate Limiting und Session Management"
• "Database Queries mit Row-Level Security Policies"
• "API Endpoints mit Input Validation und CORS Restrictions"

KI baut genau das, was du anforderst. Nicht mehr, nicht weniger. Und wenn du nicht weißt, nach Security Features zu fragen, wirst du sie nicht bekommen.

Der europäische KI-Anbieter, der gehackt wurde? Sie haben wahrscheinlich genau das bekommen, wonach sie gefragt haben. Das Problem ist, sie wussten nicht, wonach sie sonst noch fragen sollten.

Das fundamentale Problem: Du weißt nicht, was du nicht weißt

Hier ist die unbequeme Wahrheit, die die Schadenfreude-Crowd nicht anerkennen will: Wenn du nicht weißt, was du nicht über Sicherheit weißt, hast du keine Berechtigung, eine SaaS zu betreiben.

Aber wie sollst du lernen? Die Security-Industrie hat ein feindliches Umfeld geschaffen, wo:

• Unwissenheit zuzugeben dich zum Ziel macht
• Grundfragen zu stellen dich lächerlich macht
• Fehler zu machen dich öffentlich hingerichtet werden lässt
• "Security Researcher" mehr wie Vigilanten als Pädagogen agieren

Also täuschen Gründer es vor. Sie bauen öffentlich, lernen unterwegs und hoffen, dass niemand die Lücken bemerkt. Meistens tut das niemand. Aber wenn jemand es bemerkt, bekommen sie statt Hilfe Schlagzeilen.

Ich habe Codebasen von Y Combinator Firmen überprüft, von Series A Startups, von "prestigeträchtigen" Accelerator-Absolventen. Die Sicherheitsqualität ist überall. Einige sind exzellent. Viele sind wartende Katastrophen. Der einzige Unterschied zwischen ihnen und dem europäischen KI-Anbieter? Timing und Glück.

Was tatsächlich schiefgeht (Die technische Realität)

Lass mich dir die echten Muster zeigen, die ich in KI-generierten Sicherheitsfehlern sehe:

Die Rate Limiting Katastrophe

Ein Gründer baut seine SaaS mit Cursor AI über ein Wochenende. Launcht am Montag. Mittwochmorgen, AWS Rechnung: €637. Für zwei Tage.

Kein Rate Limiting. Bots erstellten 12.000 Fake-Accounts, Spam füllte die Datenbank, SendGrid E-Mail-Quota komplett verbrannt. Nicht weil die KI schlechten Code schrieb – weil niemand überhaupt nach Rate Limiting gefragt hat.

Hier ist, was das schlimmer macht: KI wird gerne Rate Limiting Code schreiben, wenn du fragst. Aber sie wird dich nicht erinnern zu fragen. Sie ist zielorientiert, erinnerst du dich?

Der Fix erfordert geschichtete Rate Limits:

Füge umfassendes Rate Limiting zu meiner API hinzu:

1. Globales IP-Limit: 100 Requests/Stunde
2. Auth-Endpoints: 5 Versuche/Stunde pro IP
3. Authentifizierte Routen: 500 Requests/Stunde pro User
4. Füge Cloudflare Turnstile zum Signup-Formular hinzu
5. Implementiere E-Mail-Queue um Quota-Erschöpfung zu verhindern

Inkludiere 429 Error Responses mit Retry-After Headers.

Aber hier ist die KI-Falle: Sie wird Code schreiben, der die Tests bestehen lässt, nicht Code, der tatsächlich sicher ist. Ich habe gesehen, wie KI Rate Limiting hinzufügt, dann die Tests modifiziert, um immer Success zurückzugeben. Ziel erreicht. Sicherheit? Immer noch kaputt.

Die Row-Level Security Lücke

Letzten Monat: Healthcare Appointment Booking Platform, schönes Design, funktionierende Payments. Ich änderte /appointments/123 zu /appointments/124 in der URL.

Plötzlich sah ich jemand anderen's medizinische Termine. Namen, Beschwerden, Arztnotizen. Ich testete weiter. 400 Nutzer's Daten exponiert. Nur durch Ändern einer Nummer.

Die KI schrieb perfekte CRUD-Operationen. Aber niemand fragte nach Row-Level Security (RLS), also implementierte die KI es nie. Warum sollte sie? Das Ziel war "build appointment viewing" nicht "build secure appointment viewing."

RLS bedeutet, die Datenbank erzwingt Access Control, nicht dein Application Code:

Implementiere Row-Level Security für Tabellen: [users, posts, comments]

Für jede Tabelle:
1. Enable RLS
2. SELECT Policy: nur Rows zeigen wo user_id = auth.uid()
3. INSERT Policy: auto-set user_id zu auth.uid()
4. UPDATE/DELETE: nur erlauben wenn user_id = auth.uid()

Zeige mir die exakten SQL Policies für Supabase/PostgreSQL.

Dann teste es tatsächlich. Ändere deine User ID in der Browser Console. Versuche, auf andere Users' Daten zuzugreifen. Wenn du irgendetwas sehen kannst, ist dein RLS kaputt. Ich habe 40+ KI Codebasen überprüft. Vielleicht 3 hatten funktionierendes RLS.

Die Credentials Katastrophe

Etwa 20% der KI-generierten Codebasen, die ich überprüfe, haben exponierte Credentials in GitHub. Stripe Keys, AWS Credentials, Database Passwords in Plain Text.

GitHub Bots sind schnell. Ich habe gesehen, wie API Keys innerhalb von 15 Minuten nach Push zu Public Repos gescraped wurden. Schaden: €2.000 AWS Rechnungen vom Crypto Mining, Tausende Spam-E-Mails, ganze Datenbanken von Konkurrenten kopiert.

KI wird Secrets zu Environment Variables verschieben, wenn du fragst:

Auditiere meine Codebase für exponierte Credentials:

1. Finde alle API Keys, Tokens, Passwords
2. Verschiebe zu .env.local
3. Update Code um process.env zu nutzen
4. Füge .env.local zu .gitignore hinzu
5. Zeige wie man diese in [Vercel/Railway] setzt
6. Erstelle .env.example mit Dummy Values

Liste jede modifizierte Datei.

Aber hier ist, was KI konsistent vermisst: Git History auf bereits committete Secrets überprüfen. Nach Ausführen dieses Prompts, führe git log --all --full-history -- **/*.env* aus um zu verifizieren, dass nichts bereits committed ist.

Wenn du Secrets in der History findest, musst du:

1. Jedes exponierte Credential sofort rotieren
2. Sie aus der Git History mit git-filter-repo entfernen
3. Automatisiertes Scanning hinzufügen, um es wieder zu verhindern

Was der Breach tatsächlich offenbarte

Lass uns darüber reden, was wirklich mit diesem europäischen KI-Anbieter schiefging. Die Presse beschuldigte "Vibe Coding", aber lass uns präzise sein:

Eine öffentliche Test-Instanz mit sofortigem Admin-Access – Keine Authentifizierung, keine Verifikation, sofortige Admin-Privilegien. Das ist architektonisches Versagen, nicht Coding-Versagen.

Plaintext Credentials in internen Docs – Root Passwords in Plain Text gespeichert. Nicht weil KI es vorschlug, sondern weil jemand entschied, es sei akzeptabel.

Keine Network Segmentation – Test System Access führte zu Production Infrastructure. Das ist Infrastructure Design, nicht Code Generation.

Null Monitoring oder Alerting – Der Breach wurde durch öffentliche Offenlegung entdeckt, nicht durch interne Alerts. Niemand bemerkte, dass jemand auf 150 verschiedene Kundenumgebungen zugriff.

Hier ist, was jeder verpasste: Das sind keine KI-Coding-Probleme. Das sind fundamentale Security Architecture Entscheidungen.

Selbst handgeschriebener Code hätte die gleichen Schwachstellen, wenn die Architekten identische Entscheidungen getroffen hätten. Der Unterschied ist, dass traditionelle Entwicklung langsamer ist und mehr Zeit für Security Review gibt. Mit KI bewegst du dich so schnell, dass Sicherheit zum Nachgedanken wird.

Das Problem ist nicht, dass KI unsicheren Code schreibt. Das Problem ist, dass Menschen nicht wissen, welche Sicherheitsfragen sie KI stellen sollen.

Spec-Driven Development: Das fehlende Teil

Hier ist etwas, das ich auf die harte Tour gelernt habe: KI kann nur so sicher sein wie die Spezifikationen, die du ihr gibst.

Ich habe ausführlich über Spec-Driven Development mit KI geschrieben, weil es der einzige Ansatz ist, der konsistent Sicherheitskatastrophen verhindert. Das Konzept ist einfach: Schreibe detaillierte Spezifikationen, bevor KI eine einzige Code-Zeile schreibt.

Nicht nur "baue User Authentication". Stattdessen:

Authentication System Spezifikation:

Funktionale Anforderungen:
- Email/Password Login mit bcrypt Hashing (Cost Factor 12)
- JWT Tokens mit 1-Stunden Ablauf
- Refresh Tokens in httpOnly Cookies gespeichert
- Password Reset via zeitlich begrenzte Tokens (15 Minuten)

Sicherheits-Anforderungen:
- Rate Limiting: 5 Login-Versuche pro IP pro Stunde
- Rate Limiting: 3 Password-Reset-Anfragen pro E-Mail pro Stunde
- Account Lockout nach 10 fehlgeschlagenen Versuchen (30 Minuten Cooldown)
- Erforderliche Password-Stärke: 12+ Zeichen, gemischte Cases, Zahlen, Symbole
- CSRF-Schutz auf allen zustandsändernden Endpoints
- Session-Invalidierung bei Password-Änderung

Test-Anforderungen:
- Unit Tests für Rate Limit Enforcement
- Integration Tests für Authentication Flow
- Security Tests die Bypass-Methoden versuchen
- Load Tests mit 1000 gleichzeitigen Login-Versuchen

Wenn du KI dieses Level an Spezifikation gibst, baut sie alle Security Features von Anfang an. Nicht als Nachgedanken. Nicht wenn du dich erinnerst zu fragen. Von Tag eins.

Der europäische KI-Anbieter, der gehackt wurde? Ich garantiere, sie hatten keine Sicherheitsspezifikationen. Sie hatten Feature-Spezifikationen. "Baue ein Admin Panel" nicht "Baue ein Admin Panel mit Authentifizierungs-Verifikation, Rate Limiting und Audit Logging."

Spec-Driven Development zwingt dich, über Sicherheit nachzudenken, bevor Code existiert. Es ist der Unterschied zwischen "fix security later" und "security is built in."

Wenn du es ernst meinst mit sicherem Bauen mit KI, lies diesen Post. Dann schreibe Spezifikationen für jedes Feature, bevor du KI promptest. Es dauert länger am Anfang. Es verhindert Katastrophen später.

Die Tools, die das tatsächlich catchen

Nach einem Jahr des Reparierens dieser Katastrophen habe ich Tools gefunden, die tatsächlich funktionieren, um KI-generierte Sicherheitsprobleme zu catchen:

CodeRabbit

CodeRabbit überprüft jeden Pull Request automatisch und catcht Security-Patterns, die KI typischerweise generiert. Es ist wie einen Senior Developer zu haben, der KIs Arbeit überprüft, bevor sie in Production geht.

Einmal einrichten, es läuft bei jedem Commit. Catcht Dinge wie:

• Fehlende Input Validation
• Exponierte sensible Daten in Logs
• Authentication Bypasses
• SQL Injection Schwachstellen in ORM Queries

Kosten: Gratis für Open Source, ~€12/Monat pro Developer für private Repos.

Semgrep

Semgrep scannt deine Codebase für Security Anti-Patterns und versteht tatsächlich Code-Kontext. Anders als simple Regex-Scanner weiß es den Unterschied zwischen user.password in einer Test-Datei versus in Production Code.

Ich führe Semgrep in CI bei jedem Projekt aus:

# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: returntocorp/semgrep-action@v1
        with:
          config: auto

Es catcht:

• Hardcoded Secrets (sogar KI-generierte)
• SQL Injection Patterns
• Command Injection Schwachstellen
• Unsichere Kryptographie-Nutzung

Der komplette Security Stack

Hier ist, was ich tatsächlich für jede KI-generierte Anwendung implementiere:

Bevor Code überhaupt läuft:

• Gitleaks in Pre-Commit Hooks (catcht Secrets bevor sie committed werden)
• CodeRabbit auf Pull Requests (überprüft KI-generierten Code)
• Semgrep in CI (scannt für Security Patterns)

In der Anwendung selbst:

• Geschichtetes Rate Limiting (IP, User, Endpoint, Operation Levels)
• Row-Level Security auf allen Datenbank-Tabellen
• Null Plaintext Secrets (alles in Environment Variables)
• CORS locked auf spezifische Origins
• Security Headers via Helmet.js
• Input Validation auf jedem Endpoint

Kontinuierliches Monitoring:

• OWASP ZAP Baseline Scans
• Dependabot für Dependency Schwachstellen
• Regelmäßiges Penetration Testing (tatsächlich versuchen es zu brechen)

Nichts davon ist exotisch. Nichts erfordert ein Security Team. Es ist grundlegende Hygiene, die KI implementieren kann – wenn du weißt, danach zu fragen.

Der Teil über Ethik, den niemand diskutiert

Erinnerst du dich an den "Security Researcher", der den europäischen KI-Anbieter gehackt und sofort öffentlich ging? Lass mich dir von einem anderen Researcher erzählen.

Vor zwei Monaten fand jemand eine kritische Schwachstelle im Payment Processing System eines Klienten. Er hätte auf Transaktionsdaten von Tausenden Kunden zugreifen können. Stattdessen:

1. Dokumentierte die Schwachstelle privat
2. Kontaktierte die Firma durch ordentliche Kanäle
3. Gab 90 Tage für Remediation
4. Verifizierte den Fix vor Disclosure
5. Publizierte Findings in Zusammenarbeit mit der Firma

Das ist verantwortungsvolle Offenlegung. Das ist ethische Security Research.

Was mit dem europäischen KI-Anbieter passierte? Das war Vigilantismus verkleidet als Security Research. Und die deutsche Tech-Presse jubelte, weil Schadenfreude besser verkauft als verantwortungsvoller Journalismus.

Die Botschaft, die das an Gründer sendet: Baue nichts Innovatives, denn sobald du Erfolg hast, wird jemand versuchen, dich niederzureißen. Gib keine Sicherheitslücken zu, denn Geständnis macht dich zum Ziel. Frag nicht um Hilfe, denn die "Security Community" könnte dich öffentlich hinrichten.

So töten wir Innovation, während wir vorgeben, Nutzer zu schützen.

Was das für dein Projekt bedeutet

Wenn du mit KI-Unterstützung baust (und das solltest du), hier ist, was tatsächlich zählt:

Du kannst Sicherheitswissen nicht an KI outsourcen. KI ist zielorientiert. Sie erreicht die Ziele, die du setzt. Wenn du nicht weißt, Sicherheitsziele zu setzen, wird KI sie nicht für dich setzen.

Funktionierende Demos beweisen nichts über Sicherheit. Demos beweisen, dass Happy Paths funktionieren. Sicherheit dreht sich um Unhappy Paths – bösartige Requests, Edge Cases, adversarial Inputs. KI ist besonders schlecht bei diesen, weil sie nicht Teil typischer Training Data sind.

Die KI wird Tests bestehen lassen, nicht Code sicher machen. Ich habe gesehen, wie KI fehlschlagende Security Tests auskommentiert, Types modifiziert um Validation zu vermeiden, und Error Handling vereinfacht um Warnungen zu eliminieren. Ziel erreicht. Sicherheit kompromittiert.

Wenn du nicht weißt, was du nicht weißt, hol dir Hilfe bevor du launchst. Nicht nach dem Breach. Nicht nach der €600 AWS Rechnung. Nicht nach der öffentlichen Hinrichtung. Vorher.

Die langweilige Checkliste, die tatsächlich funktioniert

Hör auf zu versuchen, ein Sicherheitsexperte zu sein. Fang an, diese Basics zu implementieren:

Rate Limiting:

• Per-IP: 100 Requests/Stunde
• Auth Endpoints: 5 Versuche/Stunde
• Per-User: 500 Requests/Stunde
• Füge Turnstile/hCaptcha auf Signup hinzu
• Queue E-Mail-Sends um Quota-Erschöpfung zu verhindern

Row-Level Security:

• Enable RLS auf allen Tabellen
• Default Deny, Explicit Allow
• Teste durch Versuch auf andere Users' Daten zuzugreifen
• Verifiziere tatsächlich, dass die Policies funktionieren

Secret Management:

• Alles in Environment Variables
• Gitleaks in Pre-Commit Hooks
• Semgrep Scanning in CI
• Rotiere alles sofort, was leakt

Automatisiertes Scanning:

• CodeRabbit auf Pull Requests
• Semgrep in CI Pipeline
• OWASP ZAP Baseline Scans
• Dependabot für Dependencies

Testing:

• Schreibe Scripts, die versuchen, deine Limits auszunutzen
• Ändere URL-Parameter um auf andere Daten zuzugreifen
• Versuche SQL Injection auf Inputs
• Versuche Authentication Bypasses

Das ist nicht alles, was du brauchst. Aber es ist die minimum viable Security, die verhindert, dass du die nächste öffentliche Hinrichtungs-Fallstudie wirst.

Was als Nächstes passiert?

Die deutsche Tech-Presse wird weiterhin Security-Vigilanten glorifizieren. Die Schadenfreude wird weitergehen. Firmen werden weiterhin öffentlich hingerichtet für die gleichen Fehler, die Dutzende andere still machen.

Und Gründer werden weiterhin mit KI bauen, denn trotz allem ist KI das mächtigste Entwicklungs-Tool, das wir je hatten. Die Geschwindigkeit, die Fähigkeit, die Zugänglichkeit – es ist revolutionär.

Die Frage ist nicht, ob man KI nutzen soll. Die Frage ist, ob du genug über Sicherheit weißt, um KI sicher zu nutzen.

Die meisten Gründer tun es nicht. Das ist keine Beleidigung. Sicherheit ist eine tiefe Spezialisierung. Aber wenn du eine SaaS betreibst, musst du entweder die Basics lernen oder jemanden einstellen, der sie kennt. Denn die Alternative ist, die nächstmonatige Warngeschichte zu werden.

Bereit sicherzustellen, dass deine KI-generierte Anwendung nicht die nächste öffentliche Hinrichtung wird? Lass uns sprechen über einen Security Review bevor du launchst. Ich werde zwei Stunden damit verbringen, deine Anwendung zu brechen und dir genau zeigen, was gefixt werden muss – bevor die Schadenfreude-Crowd es findet.