Montag, 8:47 Uhr. Das Sprint-Planning endet früher als erwartet.

Jonas, Lead Developer bei einem mittelständischen Maschinenbauunternehmen in Süddeutschland, klappt seinen Laptop zu und lächelt. Die Stimmung im Team ist gut – und das hat einen Grund. Seit drei Monaten arbeitet sein fünfköpfiges Entwicklungsteam mit KI-Coding-Assistenten. Cursor, GitHub Copilot, Claude als Code-Editor – die Tools sind in den täglichen Workflow integriert. Was früher zwei Sprints dauerte, ist jetzt in einem erledigt. Der Geschäftsführer ist begeistert. Die Feature-Roadmap rückt schneller als geplant voran.

Was Jonas nicht weiß: In der neuen REST-API, die das Team letzte Woche ausgeliefert hat, klafft eine SQL-Injection-Lücke. Der KI-generierte ORM-Wrapper serialisiert Benutzereingaben ohne ausreichende Parametervalidierung. In einem der React-Komponenten, entstanden in unter 20 Minuten per Prompt, steckt eine Cross-Site-Scripting-Schwachstelle. Und das Backend-Authentifizierungsmodul verwendet ein veraltetes JWT-Signaturverfahren, das ein gut ausgerüsteter Angreifer in Minuten brechen kann.

Jonas hat diese Teile des Codes nie wirklich gelesen. Er hat sie getestet – sie funktionieren. Sie tun, was sie tun sollen. Und genau das ist das Problem.

Was Jonas und sein Team erleben, hat in der Entwicklerszene einen Namen bekommen: Vibe Coding. Der Begriff, geprägt von KI-Forscher Andrej Karpathy, beschreibt eine Entwicklungsweise, bei der die KI den Code schreibt und der Entwickler primär beschreibt, überprüft und deployt – aber nicht mehr in jedem Detail versteht, was der Code wirklich tut. Vibe Coding ist prompt-gesteuertes Software Engineering: schnell, produktiv, manchmal atemberaubend effizient.

Und zunehmend ein ernsthaftes Sicherheitsrisiko für Unternehmen.

Was Vibe Coding wirklich bedeutet – und warum es sich verbreitet

Der Begriff klingt nach einer Nische für experimentierfreudige Einzelentwickler. Die Realität ist eine andere. Aktuelle Daten aus 2026 zeigen: 84 Prozent der Entwickler weltweit nutzen bereits KI-Coding-Tools oder planen deren Einsatz – mehr als die Hälfte täglich. In Unternehmen ab 100 Mitarbeitern ist der Einsatz von Copilot, Cursor, Codeium oder vergleichbaren Werkzeugen längst keine Ausnahme mehr, sondern Standard.

Die Leistungsversprechen sind real. KI-Assistenten beschleunigen die Entwicklung messbar: Routineaufgaben wie das Schreiben von Unit Tests, das Generieren von Boilerplate-Code, die Implementierung bekannter Algorithmen oder das Erstellen von API-Anbindungen – all das geht mit KI-Unterstützung deutlich schneller. Teams berichten von Produktivitätssteigerungen zwischen 30 und 60 Prozent bei bestimmten Aufgabentypen.

Diese Produktivität hat jedoch einen Preis, der nicht sofort auf der Rechnung erscheint. Er steht im nächsten Penetrationstest. Oder im nächsten Incident.

Die Sicherheitsdaten hinter dem Hype

Mehrere unabhängige Forschungsgruppen und Sicherheitsunternehmen haben in den letzten zwei Jahren systematisch untersucht, wie sicher KI-generierter Code wirklich ist. Die Ergebnisse sind konsistent – und ernüchternd.

Veracode und mehrere akademische Studien zeigen: Rund 24,7 bis fast 50 Prozent des von KI generierten Codes enthalten sicherheitsrelevante Schwachstellen. Zum Vergleich: Bei erfahrenen menschlichen Entwicklern liegt diese Rate bei 15 bis 20 Prozent. Das bedeutet, KI-generierter Code hat je nach Studie eine zwei- bis dreifach höhere Schwachstellendichte als manuell geschriebener Code von Senior Developers.

Die häufigsten Schwachstellen in KI-generiertem Code:

  • Injection-Schwachstellen (SQL Injection, Command Injection, LDAP Injection) – KI-Modelle priorisieren Funktionalität über Eingabevalidierung
  • Unsichere Deserialisierung – automatisch generierte Parser-Logik vernachlässigt häufig Typprüfungen
  • Broken Authentication – JWT-Implementierungen, Session-Management und Passwort-Hashing folgen nicht immer aktuellen Best Practices
  • Sensitive Data Exposure – Secrets, API-Schlüssel und Konfigurationsdaten landen gelegentlich im generierten Code
  • Cross-Site Scripting (XSS) – UI-Komponenten ohne korrekte Output-Enkodierung
  • Veraltete oder verwundbare Abhängigkeiten – KI-Modelle greifen auf Trainingsdaten zurück, die nicht den aktuellen Stand der npm/PyPI-Registries widerspiegeln

Die Unit 42-Forschungsgruppe von Palo Alto Networks dokumentiert seit 2025 reale Vorfälle: Authentifizierungs-Bypasses in produktiven Web-Applikationen, Remote Code Execution durch unsichere Plattformlogik und Datenlecks durch fehlerhafte Zugriffskontrollen – alle direkt zurückzuführen auf nicht ausreichend überprüften KI-generierten Code.

Comprehension Debt: Das stille Risiko

Neben den direkten Schwachstellen entsteht durch Vibe Coding ein subtileres, langfristig gefährlicheres Problem: Comprehension Debt – die wachsende Lücke zwischen dem Code, den ein System enthält, und dem Code, den das Team wirklich versteht.

In traditionellen Entwicklungsprozessen entstand Code durch das Schreiben von Zeile zu Zeile. Entwickler verstanden nicht nur was der Code tut, sondern warum – welche Designentscheidungen dahinterstecken, welche Randfälle er behandelt, welche er ignoriert. Dieses implizite Wissen ist in Vibe-Coding-Umgebungen häufig nicht mehr vorhanden.

Die praktischen Konsequenzen:

  • Sicherheits-Reviews werden schwieriger: Wenn niemand im Team den Code wirklich verstanden hat, fällt es schwer zu beurteilen, ob eine Implementierung sicher ist.
  • Incident Response wird langsamer: Bei einem aktiven Sicherheitsvorfall müssen Responder verstehen, wie angegriffene Komponenten funktionieren. Wurde diese Logik von einer KI generiert und nie wirklich durchdrungen, verliert man wertvolle Zeit.
  • Technische Schulden häufen sich unsichtbar an: Veraltete Muster, deprecated APIs, ineffiziente Datenbankabfragen – KI-generierter Code enthält sie häufig, weil das Trainingsmodell nicht den neuesten Stand kennt.
  • Wissensverlust bei Personalwechsel: Verlässt ein Entwickler das Unternehmen, geht in klassischen Teams dessen implizites Code-Wissen verloren. Bei AI-generierten Codebasen war dieses Wissen oft gar nicht erst vorhanden.

User Story: Was passiert, wenn der Security Debt fällig wird

Zurück zu Jonas und seinem Team. Vier Monate nach dem erfolgreichen Sprint-Planning:

Es ist ein Dienstagnachmittag, als der erste Alert eintrifft. Das Monitoring-System meldet ungewöhnliche Datenbankabfragen. Ein Analyst schaut genauer hin – und findet Spuren von Exfiltration. Jemand hat sich Zugriff auf die Kundendatenbank verschafft. Etwa 12.000 Datensätze mit Namen, E-Mail-Adressen und verschlüsselten Bestelldaten wurden abgerufen.

Das Incident-Response-Team beginnt die Untersuchung. Die Quelle: die SQL-Injection-Lücke in dem KI-generierten ORM-Wrapper, den Jonas drei Monate zuvor deployed hatte. Der Angreifer hatte eine öffentliche API-Schnittstelle identifiziert, die Benutzereingaben ohne Parametervalidierung direkt in Datenbankabfragen einbaute. Eine klassische, seit den 1990er-Jahren bekannte Schwachstellenklasse.

Beim Review des Codes fragt das Team: Wer hat diese Funktion geschrieben? Die Antwort: Niemand wirklich. Die KI hat sie generiert. Jonas hat sie überflogen und festgestellt, dass sie den gewünschten Output liefert. Einen tiefen Security-Review hat niemand gemacht – dafür war im Sprint keine Zeit, und die Funktion "lief ja".

Was folgt: drei Wochen Incident Response, DSGVO-Meldepflicht, Benachrichtigung der betroffenen Kunden, externer Forensik-Dienstleister, juristischer Beistand, Reputationsschäden. Die Kosten übersteigen schnell die Produktivitätsgewinne der vergangenen Monate.

Dies ist kein hypothetisches Szenario. Unit 42 dokumentiert vergleichbare Fälle seit 2025 in wachsender Zahl.

Die strukturelle Herausforderung: DevSecOps war nicht für diese Geschwindigkeit gebaut

Das Problem liegt nicht allein beim einzelnen Entwickler oder Team. Es ist strukturell: DevSecOps-Prozesse wurden für menschliche Entwicklungsgeschwindigkeit konzipiert. Code-Reviews, SAST-Scans, manuelle Sicherheitstests, Threat Modeling – all diese Prozesse setzen voraus, dass ein menschlicher Experte Zeit hat, Code zu lesen, zu verstehen und zu bewerten.

Wenn ein KI-Assistent in einer Stunde das schreibt, wofür ein Entwickler früher zwei Tage brauchte, multipliziert sich die Codemenge. SAST-Tools (Static Application Security Testing) können zwar automatisiert scannen – aber sie haben Grenzen bei Kontextverständnis und Logikfehlern. Manuelle Code-Reviews können nicht mit der KI-Geschwindigkeit Schritt halten, wenn Teams nicht explizit gegensteuern.

Das Ergebnis: Ein wachsender Stapel von Code, der funktioniert – aber dessen Sicherheitsqualität systematisch hinter die Produktion läuft. Security Debt, der sich sammelt, bis ein Vorfall ihn schlagartig sichtbar macht.

Unternehmensrisiken im Überblick

Für IT-Verantwortliche und Geschäftsführer lassen sich die Risiken des unkontrollierten Vibe-Coding-Einsatzes in vier Kategorien zusammenfassen:

1. Direkte Sicherheitsrisiken

Schwachstellen in KI-generiertem Code, die – wenn unentdeckt – zu Datenlecks, unbefugtem Zugriff, Ransomware-Infektionen oder Compliance-Verstößen führen können. Diese Risiken sind quantifizierbar und betreffen direkt Kunden, Geschäftspartner und den Geschäftsbetrieb.

2. IP-Leakage und Datenschutz

Viele KI-Coding-Tools senden Code-Snippets zur Verarbeitung an externe Server. Internes Know-how, proprietäre Algorithmen oder Geschäftsgeheimnisse können so unbeabsichtigt in die Trainingsdaten eines Cloud-Dienstleisters fließen. Für Unternehmen mit F&E-Intensität oder streng vertraulichen Prozessen ist dies ein unterschätztes Risiko. DSGVO-Compliance bezüglich personenbezogener Daten im Code (z.B. Testkonfigurationen mit echten Kundendaten) ist ein weiteres Problemfeld.

3. Regulatorische Haftung

Unter NIS2 sind betroffene Unternehmen verpflichtet, "geeignete technische und organisatorische Maßnahmen" zur Cybersicherheit zu treffen. Dazu gehört explizit auch Secure Software Development. Wer AI-Code ohne ausreichende Sicherheitsüberprüfung in produktive Systeme deployt, hat schlechte Karten, wenn nach einem Vorfall die BSI-Prüfer auf den Entwicklungsprozess schauen. Ähnliches gilt für DORA im Finanzsektor und den EU Cyber Resilience Act, der 2026 für Produkthersteller schärfer greift. Mehr zu den aktuellen Compliance-Anforderungen lesen Sie auf unserer Seite.

4. Technische Langzeitrisiken

Comprehension Debt, Shadow Dependencies und "Haunted Codebases" – Codebasen, in denen Teile existieren, die niemand mehr wirklich versteht und die deshalb nicht angefasst werden – reduzieren langfristig die Agilität des Unternehmens. Was kurzfristig Geschwindigkeit bringt, kann mittelfristig zu einem Entwicklungs-Stillstand führen, weil Änderungen zu riskant erscheinen.

Sichere KI-gestützte Entwicklung: Ein praxisorientierter Ansatz

Die Antwort auf diese Herausforderungen ist nicht, KI-Coding-Tools zu verbieten. Das wäre unrealistisch und würde die Wettbewerbsnachteile gegenüber Unternehmen, die diese Tools bewusst und sicher einsetzen, erheblich vergrößern. Die Antwort ist ein strukturierter Ansatz, der die Produktivitätsgewinne behält und die Sicherheitsrisiken systematisch adressiert.

Schritt 1: Security Review als fester Bestandteil der Definition of Done

KI-generierter Code darf nicht als "reviewed" gelten, nur weil er vom Entwickler überflogen wurde. Die Definition of Done in Scrum oder die entsprechenden Merge-Anforderungen sollten explizit einen Security-Review für alle AI-generierten Komponenten enthalten. Das bedeutet nicht zwangsläufig eine stundenlange manuelle Prüfung – aber ein gezielter Blick auf die sicherheitskritischen Teile: Eingabevalidierung, Authentifizierung, Datenbankzugriffe, Session-Handling.

Schritt 2: Automatisierte SAST- und DAST-Integration in die CI/CD-Pipeline

Statische Code-Analyse (SAST) sollte für jeden Commit automatisch laufen. Tools wie Semgrep, Checkmarx, SonarQube oder Snyk lassen sich in moderne CI/CD-Pipelines integrieren und können viele der häufigsten Schwachstellenklassen in KI-generiertem Code automatisch erkennen:

# Beispiel: Semgrep in GitHub Actions
- name: Run Semgrep
  uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/default
      p/owasp-top-ten
      p/r2c-security-audit
  env:
    SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

Dynamisches Application Security Testing (DAST) in Staging-Umgebungen ergänzt die statische Analyse um Laufzeit-Tests, die Schwachstellen wie XSS oder SQL Injection unter realen Bedingungen erkennen.

Schritt 3: Prompt Engineering für sicherheitsbewusste Code-Generierung

Die Qualität des KI-generierten Codes hängt stark von der Qualität der Prompts ab. Entwickler sollten angewiesen werden, Sicherheitsanforderungen explizit in ihre Prompts einzubauen:

// Unsicherer Prompt (Beispiel):
"Schreib mir eine Funktion, die Benutzerdaten aus der Datenbank lädt"

// Sicherheitsbewusster Prompt (Beispiel):
"Schreib mir eine Funktion in Node.js mit parameterisierten Prepared Statements
(pg-Bibliothek), die Benutzerdaten anhand einer validierten userId aus PostgreSQL
lädt. Verwende input validation mit zod, handle Datenbankfehler sicher ohne
Stack Traces nach außen zu geben, und kommentiere die Sicherheitsmaßnahmen."

Dies klingt nach Mehraufwand – ist aber bei komplexen, sicherheitskritischen Funktionen ein lohnender Investment. Viele Teams entwickeln hausinterne Prompt-Templates für typische Aufgaben wie Authentifizierung, Datenbankzugriff oder API-Endpunkte.

Schritt 4: Dependency-Scanning und Supply Chain Security

KI-Assistenten empfehlen regelmäßig Bibliotheken und Pakete, die Teil des Trainingsdatensatzes waren – aber nicht immer den aktuellen Sicherheitsstand widerspiegeln. Eine automatisierte Dependency-Überwachung mit Tools wie Dependabot, Snyk oder npm audit in der Pipeline ist Pflicht:

# package.json scripts
{
  "scripts": {
    "audit": "npm audit --audit-level=high",
    "audit:fix": "npm audit fix"
  }
}

Darüber hinaus sollten Entwickler angewiesen werden, empfohlene Pakete vor der Übernahme kurz auf Aktualität und bekannte CVEs zu prüfen – ein 30-sekündiger Check bei snyk.io oder dem GitHub Advisory Database kann erhebliche Probleme verhindern.

Schritt 5: Governance-Richtlinien für KI-Tools

Viele Unternehmen haben noch keine klaren Richtlinien, welche KI-Coding-Tools unter welchen Bedingungen eingesetzt werden dürfen. Empfehlenswert ist eine AI Tool Policy, die mindestens folgende Punkte regelt:

  • Welche Tools sind freigegeben (Self-hosted vs. Cloud, Datenschutzeinstufung)?
  • Darf produktiver Kundencode in Cloud-KI-Dienste übertragen werden?
  • Gibt es Klassifikationen für besonders sensiblen Code (Authentifizierung, Kryptographie, PII-Verarbeitung), bei dem KI-Unterstützung eingeschränkt oder untersagt ist?
  • Wie werden KI-generierte Anteile im Code dokumentiert (z.B. Kommentare, Commit-Messages)?
  • Welche Schulungen sind Voraussetzung für den produktiven Einsatz von KI-Coding-Tools?

Schritt 6: Security-Training für den KI-Zeitalter

Entwickler brauchen kein neues Grundlagenwissen in Cybersecurity – sie brauchen eine Anpassung ihrer Fähigkeiten an die neue Realität. Wichtig ist vor allem: die Fähigkeit, KI-generierten Code kritisch zu lesen und sicherheitsrelevante Muster zu erkennen, auch wenn man den Code nicht selbst geschrieben hat. Secure Code Review ist eine Fähigkeit, die heute wichtiger ist denn je. Wer sie ins Team bringt, schützt die gesamte Codebasis – egal ob von Menschen oder KI geschrieben.

Einordnung: Vibe Coding und die Zukunft der Softwareentwicklung

Vibe Coding ist keine kurzfristige Modeerscheinung. Mit der Weiterentwicklung von KI-Modellen werden die generierten Codequalitäten steigen – aber das Grundproblem, dass KI für Funktionalität und nicht für Sicherheit optimiert, bleibt eine inhärente Herausforderung, solange nicht explizit dagegen gesteuert wird.

Die Entwicklung geht gerade in Richtung Agentic AI: KI-Systeme, die nicht mehr nur einzelne Funktionen generieren, sondern eigenständig Features planen, implementieren, testen und in Pull Requests packen. Das Tempo wird weiter steigen. Der Comprehension Debt auch – es sei denn, Unternehmen bauen schon jetzt die strukturellen Sicherheitskontrollen ein, die für diese neue Realität nötig sind.

Für IT-Verantwortliche im Mittelstand bedeutet das: Die Investition in sichere Entwicklungsprozesse, SAST/DAST-Tooling und Security-Kompetenz im Entwicklungsteam ist heute keine optionale Best Practice mehr. Sie ist Teil der Risikosteuerung – und unter NIS2 für viele Unternehmen auch eine regulatorische Pflicht.

pleXtec unterstützt Unternehmen dabei, ihre Softwareentwicklungsprozesse für den KI-Zeitalter sicher aufzustellen – von der Auswahl geeigneter Tools über die Integration von Security-Scanning in die CI/CD-Pipeline bis zur Schulung von Entwicklungsteams. Wenn Sie wissen möchten, wie Ihr aktueller Entwicklungsprozess im KI-Zeitalter aufgestellt ist, sprechen Sie uns an. Jetzt Kontakt aufnehmen.

Zusammenfassung: Was Unternehmen jetzt tun sollten

Der Einsatz von KI-Coding-Tools ist ein Wettbewerbsvorteil – aber nur, wenn er mit den richtigen Sicherheitsstrukturen begleitet wird. Konkret empfehlen wir:

  • Bestandsaufnahme: Welche KI-Tools werden im Entwicklungsteam eingesetzt? Mit welchen Richtlinien?
  • SAST-Tool in die CI/CD-Pipeline integrieren (Semgrep, SonarQube, Checkmarx)
  • Dependency-Scanning aktivieren (Dependabot, Snyk)
  • AI Tool Policy definieren und kommunizieren
  • Definition of Done um Security-Review-Pflicht erweitern
  • Entwickler in Secure Code Review schulen
  • Besonders sicherheitskritische Bereiche (Auth, Crypto, DB-Access) identifizieren und mit erhöhtem Review-Aufwand belegen
  • Regelmäßige Penetrationstests für KI-intensiv entwickelte Applikationen einplanen

Mehr zur sicheren Integration von KI in Ihre IT-Strategie finden Sie auf unserer Seite zur KI-Strategie und -Integration sowie im Bereich Informationssicherheit.