Claude und Gemini schreiben gleich unsicheren Code – was 63 % der KI-Entwickler übersehen

Die Frage, ob Claude 4.6 oder Gemini 2.5 Flash der sicherere Code-Generator ist, ist eigentlich falsch gestellt. Denn in einer aktuellen Analyse beider Modelle zeigten sich verblüffende Parallelen – und vor allem: beide generierten Funktionen mit vergleichbaren Sicherheitslücken. Die Studie, durchgeführt mit eigens entwickelten ESLint-Plugins, offenbart ein größeres Problem als die bloße Modellauswahl: 63 % der KI-generierten Codes enthalten potenziell kritische Sicherheitsfehler, die selbst erfahrene Entwickler oft übersehen.

Diese Zahlen sollten Entwickler alarmieren – unabhängig davon, welches Sprachmodell sie nutzen. Denn die Lücken sind kein Einzelfall, sondern ein systemisches Problem. Die Untersuchung analysierte 700 KI-generierte Funktionen in vier Sicherheitsdomänen und kam zu einem ernüchternden Ergebnis: Der Unterschied zwischen den Modellen war marginal, aber die gemeinsamen Schwachstellen waren es nicht.

Warum die Wahl des KI-Modells kaum eine Rolle spielt

Die Studie verglich Claude Sonnet 4.6 und Gemini 2.5 Flash – zwei der beliebtesten Modelle für Codegenerierung – in vier typischen Einsatzszenarien. Dabei wurden keine spezifischen Sicherheitsanweisungen gegeben, um die reale Nutzung widerzuspiegeln. Die Ergebnisse überraschen:

• Ein Sieg für Gemini in einem Bereich (NestJS-Service), aber
• Zwei Unentschieden in den Kategorien JWT und MongoDB, sowie
• Ein leichtes Übergewicht für Claude in der allgemeinen API-Codegenerierung.

Doch der eigentliche Fokus der Studie lag nicht auf der Modellauswahl, sondern auf den identischen Sicherheitslücken, die beide Modelle produzierten. Denn in einer Domäne – der JWT-Authentifizierung – wiesen beide Modelle exakt dieselben fünf Schwachstellen auf. Das ist kein Zufall, sondern ein Hinweis auf ein tieferliegendes Problem.

Die kritischen Lücken, die beide Modelle übersehen

1. JWT-Token: Fehlende Validierung trotz vermeintlich sicherer Implementierung

Beide Modelle generierten Code, der JWT-Tokens korrekt verifizierte – zumindest auf den ersten Blick. Doch die Analyse mit dem jwt-Plugin enthüllte fünf identische Sicherheitslücken in beiden Implementierungen:

• Keine Whitelist für Algorithmen (require-algorithm-whitelist – CWE-757)
• Fehlende Audience-Validierung (require-audience-validation – CWE-287)
• Keine Issuer-Prüfung (require-issuer-validation – CWE-287)
• Keine maximale Token-Alter-Prüfung (require-max-age – CWE-294)
• Keine Sensitivitätsprüfung des Payloads (no-sensitive-payload – CWE-359)

Das Problem: Ein Entwickler sieht jwt.verify(token, secret) und geht davon aus, dass der Token sicher ist. Doch ohne explizite Prüfung von Audience oder Issuer könnte ein Token, der für eine andere API generiert wurde, trotzdem akzeptiert werden. Diese Lücke wird in den meisten Code Reviews übersehen – und genau das passiert auch hier.

2. MongoDB-Abfragen: Passwort-Hashes in den Ergebnissen

In der MongoDB/Mongoose-Kategorie zeigten beide Modelle ein besonders gefährliches Muster: Sie gaben komplette Dokumente zurück, inklusive Passwort-Hashes.

// Beide Modelle generierten Code wie diesen:
const results = await User.find(filter);

// Korrekt wäre gewesen:
const results = await User.find(filter).select('-passwordHash').lean();

Diese Schwachstelle (require-projection und no-select-sensitive-fields – CWE-200) ist einfach zu beheben, wird aber trotzdem in 80 % der Fälle ignoriert. Noch überraschender: Keines der Modelle fiel in die klassische NoSQL-Injection-Falle – sie nutzten keine unsicheren Abfragen mit direktem Benutzereingaben. Das deutet darauf hin, dass moderne KI-Modelle zumindest einige grundlegende Sicherheitsprinzipien verinnerlicht haben – nur um dann bei offensichtlichen Fehlern wie der Herausgabe sensibler Daten zu scheitern.

3. NestJS-Services: Gemmis idiomatische Struktur vs. Claudes Minimalismus

Der einzige Bereich, in dem Gemini klar besser abschnitt, war die NestJS-Service-Generierung. Das Modell nutzte idiomatische NestJS-Konstrukte wie:

• Klasse-basierte Guards (@UseGuards)
• Exklusion von Passwortfeldern (@Exclude())
• Validierung von DTOs (class-validator)

Claude hingegen erzeugte funktional identischen Code, aber ohne diese Sicherheitsfeatures – und sammelte dafür sechs Sicherheitsmängel ein. Doch selbst hier gilt: Die architektonischen Unterschiede sind weniger relevant als die gemeinsamen Schwachstellen.

Was Entwickler jetzt tun müssen

Die Studie zeigt: Die Wahl des KI-Modells ist sekundär – das eigentliche Problem liegt in der fehlenden Sicherheitsprüfung bei KI-generiertem Code. Die identischen Lücken in beiden Modellen deuten darauf hin, dass diese Schwachstellen systemisch in den Trainingsdaten oder Prompt-Strukturen verankert sind.

Drei konkrete Schritte zur Risikominimierung:

• Nutze spezifische ESLint-Plugins für Sicherheitsprüfungen – wie die in der Studie verwendeten Tools für JWT, MongoDB oder NestJS.
• Erstelle automatisierte Sicherheits-Checks in deinem CI/CD-Pipeline – denn manuelle Reviews erfassen diese Lücken nicht.
• Erweitere deine Prompts um Sicherheitsanweisungen – z. B. durch Formulierungen wie „Erstelle sicheren Code nach OWASP-Standards“.

Die Modelle werden besser – aber sie sind noch lange nicht fehlerfrei. Wer heute KI-generierten Code ohne zusätzliche Sicherheitsprüfung einsetzt, handelt fahrlässig.

Fazit: KI-Codegenerierung braucht neue Sicherheitsstandards

Die Ergebnisse der Studie sind ernüchternd, aber notwendig. Sie zeigen, dass 63 % der KI-generierten Codes Sicherheitslücken enthalten – und dass sowohl Claude als auch Gemini dieselben Fehler machen. Das bedeutet nicht, dass eines der Modelle „besser“ ist, sondern dass die gesamte Branche ihre Sicherheitsstrategien anpassen muss.

Die Zukunft der KI-Codegenerierung liegt nicht darin, das „beste“ Modell zu finden, sondern bessere Sicherheitsmechanismen zu entwickeln – sowohl in den Modellen selbst als auch in den Prozessen, die ihren Einsatz begleiten. Entwickler müssen lernen, KI-generierten Code nicht als fertige Lösung zu betrachten, sondern als Entwurf, der zwingend überprüft und angepasst werden muss. Nur so lässt sich das volle Potenzial der KI nutzen – ohne neue Sicherheitsrisiken zu schaffen.