Vibe Coding Sicherheitsrisiken: Was Entscheider wissen müssen

Vibe Coding Sicherheit ist das Thema, über das in Ihrem Unternehmen gerade niemand spricht. Dabei sollte es das sein. Eine Anwendung entsteht heute in wenigen Stunden. Ein Mitarbeiter beschreibt, was er braucht. Eine KI schreibt den Code. Es läuft. Alle sind zufrieden.

Die Frage nach der Sicherheit kommt später. Meistens dann, wenn schon etwas passiert ist.

Denn Code, den niemand geprüft hat, ist Code, dessen Risiken niemand kennt. Dieser Artikel zeigt, welche Lücken dabei typischerweise entstehen. Und was Sie tun können, bevor sie teuer werden.

Was Vibe Coding überhaupt bedeutet

Vibe Coding beschreibt eine neue Art, Software zu bauen. Ein Mensch beschreibt in normaler Sprache, was die Anwendung tun soll. Eine KI erzeugt daraus den Programmcode.

Der Entwickler prüft das Ergebnis nicht Zeile für Zeile. Er schaut, ob es funktioniert. Läuft es, ist es fertig.

Der Begriff stammt aus dem Jahr 2025 und hat sich schnell verbreitet. Wenn Sie tiefer einsteigen möchten, erklärt unser Artikel Was ist Vibe Coding die Grundlagen für Entscheider.

Wichtig ist eine Unterscheidung. Nicht jeder Einsatz von KI ist Vibe Coding. Ein erfahrener Entwickler, der KI-Vorschläge prüft und anpasst, arbeitet weiterhin professionell. Vibe Coding beginnt dort, wo diese Prüfung wegfällt.

Warum Vibe Coding Sicherheit ein reales Problem ist

Das Sicherheitsunternehmen Escape.tech hat über 5.600 Anwendungen untersucht, die per Vibe Coding entstanden sind. Das Ergebnis: mehr als 2.000 gefundene Sicherheitslücken.

Das ist keine theoretische Zahl. Das sind echte Anwendungen, die im Internet erreichbar waren.

Parallel dazu zeigen Entwicklerbefragungen ein zweites Muster. Rund 40 Prozent der Befragten setzen KI-generierten Code produktiv ein, ohne ihn vollständig zu verstehen.

Beides zusammen ergibt ein klares Bild. Es geht sehr viel Code in Betrieb, den niemand wirklich gelesen hat.

Warum KI-Code besonders anfällig ist

KI-Modelle lernen aus vorhandenem Code. Darunter ist viel guter Code. Und viel alter, unsicherer Code aus öffentlichen Quellen.

Ein Sprachmodell optimiert auf Plausibilität, nicht auf Sicherheit. Es liefert, was typisch aussieht. Typisch ist aber nicht dasselbe wie sicher.

Dazu kommt ein zweiter Punkt. Die KI kennt Ihren Kontext nicht. Sie weiß nicht, welche Daten schützenswert sind. Sie weiß nicht, wer auf welche Funktion zugreifen darf. Sie schreibt, was gefordert wurde. Nicht mehr.

Die häufigsten Sicherheitslücken in KI-generiertem Code

In der Praxis wiederholen sich bestimmte Muster. Diese fünf treten besonders oft auf.

Fehlende Zugriffskontrolle

Die Anwendung prüft, ob jemand eingeloggt ist. Sie prüft aber nicht, ob dieser Jemand die Daten sehen darf.

Ein Beispiel: Ein Nutzer ruft seine Rechnung über eine Adresse mit der Nummer 1042 auf. Er ändert die Nummer auf 1043. Und sieht die Rechnung eines fremden Kunden.

Diese Lücke gehört zu den häufigsten überhaupt. In KI-generiertem Code taucht sie besonders oft auf. Der Grund ist einfach: Berechtigungslogik steht selten in der Aufgabenbeschreibung.

Zugangsdaten direkt im Quelltext

API-Schlüssel, Datenbankpasswörter und Tokens landen oft direkt im Code. Eine API ist eine Schnittstelle, über die zwei Programme miteinander sprechen. Der zugehörige Schlüssel funktioniert wie ein Passwort.

Steht dieser Schlüssel im Quelltext, wandert er in jedes Backup und jede Kopie des Projekts. Automatisierte Scanner durchsuchen öffentliche Quellen rund um die Uhr nach genau solchen Zeichenfolgen.

Keine saubere Prüfung von Eingaben

Jede Eingabe eines Nutzers ist zunächst nicht vertrauenswürdig. Fehlt die Prüfung, entstehen klassische Angriffswege.

SQL Injection bedeutet: Ein Angreifer schleust über ein Eingabefeld eigene Datenbankbefehle ein. Cross Site Scripting bedeutet: Er platziert Schadcode, der im Browser anderer Nutzer ausgeführt wird.

Beide Lücken sind seit über zwanzig Jahren bekannt. Beide tauchen in KI-generiertem Code weiterhin regelmäßig auf.

Veraltete Abhängigkeiten

KI-Modelle schlagen häufig Bibliotheken in älteren Versionen vor. Eine Bibliothek ist fertiger Code von Dritten, den Ihre Anwendung mitnutzt.

Diese Versionen stammen aus den Trainingsdaten. Sie sind nicht zwingend aktuell. Manche enthalten dokumentierte Sicherheitslücken, sogenannte CVEs.

Wie Sie solche Lücken systematisch finden, beschreibt unser Beitrag zum CVE-Monitoring. Ein Blick lohnt sich, denn diese Lücken sind öffentlich dokumentiert. Auch für Angreifer.

Erfundene Pakete und Supply-Chain-Risiken

KI-Modelle schlagen gelegentlich Pakete vor, die es gar nicht gibt. Angreifer beobachten das und veröffentlichen genau diese Namen mit Schadcode.

Der Entwickler installiert das Paket. Der Schadcode läuft auf dem Firmenserver. Wie solche Angriffe im Detail ablaufen, zeigt unser Artikel zu Supply-Chain-Angriffen über npm und PHP.

Was passiert, wenn niemand hinschaut

Die Anwendung läuft weiter. Genau das ist das Problem.

Sicherheitslücken melden sich nicht von selbst. Sie warten. In dieser Zeit sammelt sich still an, was später auf einmal fällig wird.

Datenabfluss und Meldepflicht

Werden personenbezogene Daten abgegriffen, greift die DSGVO. Sie haben 72 Stunden Zeit für die Meldung an die Aufsichtsbehörde. Betroffene Kunden müssen ebenfalls informiert werden.

Die Behörde fragt dann nach Ihren technischen Schutzmaßnahmen. "Eine KI hat das geschrieben" ist keine belastbare Antwort.

Der Code, den niemand erklären kann

Nach sechs Monaten will jemand eine Funktion ändern. Niemand versteht die Struktur. Es gibt keine Tests und keine Dokumentation.

Damit landet die Anwendung genau dort, wo klassische Altsysteme nach zehn Jahren stehen. Nur deutlich schneller. Was das konkret bedeutet, erklärt unser Glossar zu technischen Schulden.

Wachsende Angriffsfläche

Jede unkontrolliert entstandene Anwendung vergrößert Ihre Angriffsfläche. Oft weiß die IT-Abteilung nicht einmal, dass es sie gibt.

Diese Dynamik kennen wir von gewachsenen Altsystemen. Warum das ein unterschätztes Risiko ist, zeigt unser Beitrag über alte Software als Sicherheitsrisiko.

Was Sie jetzt konkret tun können

Sie müssen KI nicht verbieten. Sie brauchen Regeln und einen Prüfschritt.

Schritt 1: Bestandsaufnahme

Klären Sie zuerst, was überhaupt existiert. Welche Anwendungen sind mit KI-Unterstützung entstanden? Wer hat sie gebaut? Welche Daten verarbeiten sie? Sind sie aus dem Internet erreichbar?

Diese Liste fehlt in den meisten Unternehmen. Ohne sie ist jede weitere Maßnahme Rätselraten.

Schritt 2: Abhängigkeiten prüfen

Lassen Sie alle eingebundenen Bibliotheken gegen die CVE-Datenbank prüfen. Das dauert bei kleinen Anwendungen wenige Minuten und läuft automatisiert.

Prüfen Sie außerdem, ob jedes Paket wirklich existiert und aus einer bekannten Quelle stammt.

Schritt 3: Zugangsdaten aus dem Code entfernen

Suchen Sie im Quelltext nach Schlüsseln und Passwörtern. Verschieben Sie diese in Umgebungsvariablen oder einen Passwortspeicher.

Tauschen Sie jeden Schlüssel aus, der jemals im Code stand. Er gilt als kompromittiert.

Schritt 4: Sicherheits-Audit für kritische Anwendungen

Alles, was Kundendaten verarbeitet oder öffentlich erreichbar ist, gehört geprüft. Ein Sicherheits-Audit findet genau die Lücken, die im Alltag übersehen werden.

Der Aufwand dafür ist überschaubar. Ein Datenschutzvorfall ist es nicht.

Schritt 5: Regeln für den KI-Einsatz festlegen

Legen Sie schriftlich fest, wofür KI-generierter Code genutzt werden darf. Ein internes Auswertungsskript ist unkritisch. Ein Kundenportal ist es nicht.

Vier Punkte reichen als Basis. Erstens: Produktiver Code wird von einem Menschen geprüft. Zweitens: Anwendungen mit personenbezogenen Daten erhalten immer ein Audit. Drittens: Abhängigkeiten werden automatisch überwacht. Viertens: Jede Anwendung hat einen benannten Verantwortlichen.

Schritt 6: Wartung von Anfang an einplanen

Software, die läuft, braucht trotzdem Pflege. Updates, Patches, Überwachung. Wer das von Beginn an einplant, vermeidet den teuren Sanierungsfall in zwei Jahren.

Genau hier setzt unsere laufende Software-Wartung an.

Vibe Coding ist nicht das Problem

Ein Missverständnis vorweg: KI-gestützte Entwicklung ist nichts Schlechtes. Sie senkt Hürden und beschleunigt Prototypen erheblich.

Das Problem ist der fehlende Prüfschritt. Früher saß ein Entwickler dazwischen. Er hat Sicherheitsfragen mitgedacht, oft ohne darüber zu sprechen.

Fällt dieser Schritt weg, fällt auch die Sicherheitsprüfung weg. Nicht weil die KI schlecht arbeitet. Sondern weil niemand sie darum gebeten hat.

Die Antwort lautet also nicht weniger KI. Die Antwort ist ein bewusster Prüfschritt vor dem Produktivbetrieb.

Fazit: Prüfen Sie, bevor es jemand anderes tut

Vibe Coding Sicherheit ist ein Führungsthema, kein reines Entwicklerthema. Die Entscheidung, ob ungeprüfter Code produktiv geht, trifft am Ende die Geschäftsführung.

Die wichtigsten Punkte in Kürze:

• Über 2.000 Sicherheitslücken wurden in 5.600 untersuchten KI-Anwendungen gefunden
• Rund 40 Prozent der Entwickler setzen Code ein, den sie nicht vollständig verstehen
• Typische Lücken sind fehlende Zugriffskontrolle, Zugangsdaten im Code und veraltete Bibliotheken
• Eine Bestandsaufnahme ist der erste und wichtigste Schritt
• Anwendungen mit Kundendaten gehören immer geprüft

Sie wissen nicht, welche KI-generierten Anwendungen in Ihrem Unternehmen laufen? Dann fangen Sie genau dort an.

Wir schauen uns Ihre Anwendungen an und sagen Ihnen ehrlich, wo es kritisch wird. Ohne Fachchinesisch, dafür mit einer klaren Prioritätenliste.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.