Jedes vierte Code-Beispiel hat eine Sicherheitslücke: Warum KI-generierter Code zum Risiko wird

Die unbequeme Wahrheit über KI-generierten Code

Wir alle nutzen es täglich: Cursor schlägt uns Code-Snippets vor, Claude Code generiert ganze Funktionen, GitHub Copilot vervollständigt unsere Statements. Es fühlt sich produktiv an. Es ist produktiv. Aber eine wachsende Zahl von Studien zeigt eine unbequeme Realität — ein erheblicher Teil des von KI-Modellen generierten Codes enthält Sicherheitslücken.

Die Zahlen, die 2026 aus verschiedenen Forschungsgruppen kommen, sind eindeutig und besorgniserregend. Dieser Artikel fasst die wichtigsten Erkenntnisse zusammen und zeigt, was Entwickelnde konkret tun können.

Was die Studien sagen: Ein Überblick

AppSec Santa 2026: 25% bestätigte Schwachstellen

Die AppSec-Santa-Studie testete 534 Code-Samples über sechs führende LLMs: GPT-5.2, Claude Opus 4.6, Gemini 2.5 Pro, DeepSeek V3, Llama 4 Maverick und Grok 4. Das Ergebnis: 25,1% aller generierten Codebeispiele enthielten bestätigte OWASP-Top-10-Schwachstellen.

Interessant ist die Streuung zwischen den Modellen:

| Modell | Schwachstellenrate |

|--------|-------------------|

| GPT-5.2 | 19,1% |

| Gemini 2.5 Pro | 22,3% |

| Grok 4 | 25,0% |

| DeepSeek V3 | 29,2% |

| Claude Opus 4.6 | 29,2% |

| Llama 4 Maverick | 29,2% |

GPT-5.2 schneidet am besten ab — aber selbst hier ist fast jedes fünfte Code-Beispiel anfechtbar. Die häufigsten Schwachstellenkategorien:

• SSRF (Server-Side Request Forgery, CWE-918): 32 Funde
• Injection-Schwachstellen (CWE-78/89/94): 30 Funde
• Insgesamt machen Injection-Klassen 33,1% aller bestätigten Schwachstellen aus

Cobalt AI „Broken by Default": 55,8% mit formal bewiesenen Lücken

Noch dramatischer fallen die Ergebnisse der Cobalt-AI-Studie aus, die im April 2026 veröffentlicht wurde. Sie untersuchte 3.500 Code-Artefakte von sieben LLMs mit einer bemerkenswerten methodischen Neuerung: Statt sich auf statische Analyse zu verlassen, nutzten die Forschenden Z3-SMT-Solver — Werkzeuge der formalen Verifikation, die mathematisch beweisen, dass eine Schwachstelle ausnutzbar ist.

Das Ergebnis: 55,8% aller Artefakte enthielten mindestens eine formal bewiesene, ausnutzbare Sicherheitslücke. Das beste Modell (Gemini 2.5 Flash) erreichte eine Fehlerquote von 48,4%, das schlechteste (GPT-4o) lag bei 62,4%. Kein einziges Modell erreichte eine bessere Bewertung als Note D.

Die Hauptfehlerquelle: Ganzzahl-Arithmetik (Integer-Überläufe) mit einer Fehlerrate von 87%. Unter realen Bedingungen mit GCC AddressSanitizer führten 6 von 7 repräsentativen Befunden zu echten Speicherabstürzen.

Die Asymmetrie-Erkenntnis

Vielleicht die wichtigste Entdeckung der Cobalt-AI-Studie: Dieselben Modelle, die im Generierungsmodus zu 55,8% unsicheren Code erzeugen, erkennen im Überprüfungsmodus ihre eigenen Fehler in 78,7% der Fälle korrekt. Die Forschenden folgern:

"Die Modelle verfügen grundsätzlich über das Wissen, um Sicherheitsprobleme zu erkennen — wenden es beim Schreiben von Code jedoch nicht zuverlässig an."

Das ist eine strukturelle Einschränkung, kein Prompt-Engineering-Problem. Die Studie zeigte: Explizite Sicherheitshinweise im System-Prompt senkten die Fehlerquote lediglich von 64,8% auf 60,8% — vier Prozentpunkte.

Warum KI-Modelle unsicheren Code erzeugen

Die Ursachen sind vielfältig und gut dokumentiert:

1. Training auf unsichere Beispiele. LLMs werden auf öffentlichem Code trainiert — Stack Overflow, Tutorials, Open-Source-Repos. Dieser Code priorisiert Funktionalität vor Sicherheit. Parameterisierte Queries, Eingabevalidierung und Ausgabe-Kodierung fehlen in den meisten Tutorial-Beispielen.

2. Optimierung auf den Happy Path. KI-Modelle generieren Code, der funktioniert. Input-Validierung, Fehlerbehandlung und Sicherheitsprüfungen sind aus Sicht des Modells „unnötige" Komplexität, die nicht zur Lösung des eigentlichen Problems beiträgt.

3. Fehlender Kontext. Ein KI-Modell weiß nicht, ob eure Anwendung im Internet erreichbar ist, ob der Benutzer vertrauenswürdig ist oder welche Daten schützenswert sind. Sicherheitsentscheidungen erfordern Kontext, den das Modell nicht hat.

4. Hartcodierte Secrets. Wiz Research fand heraus, dass vibe-gecodete Apps häufig API-Schlüssel, Service-Account-Zugangsdaten und Passwörter direkt im clientseitigen JavaScript enthalten. Warum? Weil der generierte Code sofort funktionieren soll — das Auslagern von Secrets in Umgebungsvariablen erfordert Deployment-Wissen.

Die konkreten Gefahren: Das fällt tatsächlich durch

Injection-Schwachstellen

SQL-Injection, Command-Injection, Code-Injection — die Klassiker sind nach wie vor die häufigsten KI-Fehler. Ein typisches Beispiel:

# Was die KI generiert (unsicher):
@app.route('/user')
def get_user():
    username = request.args.get('name')
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

# Wie es sicher sein sollte:
@app.route('/user')
def get_user():
    username = request.args.get('name')
    query = "SELECT * FROM users WHERE username = ?"
    return db.execute(query, (username,))

Der Unterschied ist minimal — aber entscheidend. Die parameterisierte Variante verhindert SQL-Injection vollständig. Die KI wählt häufig die erste Variante, weil sie in Trainingsdaten häufiger vorkommt.

SSRF: Der heimliche Anführer

Server-Side Request Forgery (SSRF) war die häufigste Einzelkategorie in der AppSec-Santa-Studie mit 32 Funden. Das Muster ist immer gleich:

# Was die KI generiert (unsicher):
@app.route('/preview')
def url_preview():
    url = request.args.get('url')
    response = requests.get(url)  # SSRF-Gefahr!
    return response.content

# Sicherere Alternative:
from urllib.parse import urlparse

ALLOWED_DOMAINS = ['example.com', 'api.example.com']

@app.route('/preview')
def url_preview():
    url = request.args.get('url')
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_DOMAINS:
        abort(403, "Domain nicht erlaubt")
    if parsed.scheme not in ('https',):
        abort(403, "Nur HTTPS erlaubt")
    response = requests.get(url, timeout=5)
    return response.content

Slopsquatting: Ein neues Angriffsmuster

Ein besonders tückisches Problem: KI-Assistenten halluzinieren manchmal Paketnamen, die gar nicht existieren. Angreifer registrieren diese halluzinierten Namen mit schädlichen Paketen. Wenn dann eine nachfolgende KI-Session denselben halluzinierten Namen importiert, wird das schädliche Paket installiert. Selbst Vergiftungsraten von 0,001% können massiven Schaden anrichten, wenn Millionen von Entwickelnden KI-Tools nutzen.

Statische Analyse reicht nicht

Die Cobalt-AI-Studie offenbarte ein weiteres alarmierendes Ergebnis: Sechs branchenübliche statische Analyse-Tools erkannten nur 7,6% der KI-generierten Artefakte als auffällig. 97,8% der formal bewiesenen Schwachstellen blieben unentdeckt. Die gängigen SAST-Tools sind schlicht nicht darauf ausgelegt, Integer-Überläufe in Zuweisungsarithmetik zuverlässig zu erkennen.

Das bedeutet: Selbst wenn ihr SAST-Tools einsetzt — was ihr auf jeden Fall tun solltet —, dürft ihr euch nicht in falscher Sicherheit wiegen.

Was Entwickelnde konkret tun können

1. Statische Analyse als Pflicht-Checkpoint

Tools wie Semgrep, CodeQL oder Snyk Code sollten in jedem Pull Request laufen — nicht nächtlich, sondern als blockierendes Gate. Sie fangen nicht alles ab, aber sie fangen genug ab, um den Unterschied zu machen.

# Beispiel: GitHub Actions SAST-Pipeline
name: Security Scan
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten

2. Secrets-Scanning mit KI-spezifischen Mustern

Standard-Scanning erkennt bekannte Muster (AWS-Keys, GitHub-Tokens). KI-generierter Code bringt aber neue Muster: Base64-kodierte Zugangsdaten, verschleierte API-Endpunkte, Platzhalter-Werte, die als echte Zugangsdaten funktionieren. Pre-Commit-Hooks sind hier unverzichtbar.

3. Abhängigkeiten pinnen und prüfen

Jedes von der KI vorgeschlagene Paket sollte gegen Schwachstellen-Datenbanken geprüft werden. Pinnt exakte Versionen in Lock-Files. Aktiviert Dependabot oder Renovate für automatische Updates. Und: Prüft, ob das vorgeschlagene Paket überhaupt existiert (Slopsquatting-Schutz).

4. Sicherheitsbewusste Prompts

Es ist kein Allheilmittel, wie die Cobalt-AI-Studie zeigt. Aber es hilft:

• Schlecht: „Baue einen Login-Endpunkt"
• Besser: „Baue einen Login-Endpunkt mit parameterisierten Queries, Eingabevalidierung, Rate-Limiting und OWASP-konformer Fehlerbehandlung"

Teamweite Prompt-Templates für sicherheitskritische Bereiche (Authentifizierung, Datenbankabfragen, Dateioperationen) können die Schwachstellendichte um 30–40% senken.

5. Der Review-Modus als Sicherheitsetage

Die Asymmetrie-Erkenntnis der Cobalt-AI-Studie bietet einen praktischen Ansatz: Nutzt KI-Modelle im Review-Modus, um den generierten Code auf Sicherheitslücken zu prüfen. Da die Modelle ihre eigenen Fehler zu fast 79% korrekt erkennen, ist dieser Ansatz erstaunlich effektiv. Der Workflow: Generieren → separater Review-Prompt → menschliche Prüfung.

6. Menschliche Expertise bleibt unverzichtbar

Benennt Security-Champions in jedem Team. Schulung von Entwickelnden, KI-Vorschläge kritisch zu hinterfragen — besonders bei Code, der Benutzereingaben, Authentifizierung oder Datenzugriff behandelt. Für kritische Systeme: externe Audits vor Major Releases.

Der EU AI Act: Regulatory Deadline rückt näher

Am 2. August 2026 treten die Hauptpflichten des EU AI Act in Kraft. Für Unternehmen, die KI-Coding-Tools für kundenorientierte Anwendungen einsetzen, bedeutet das:

• Transparenzpflichten: Dokumentation, wo und wie KI-Tools im Entwicklungsprozess eingesetzt werden
• Risikobewertungen: Bewertung der Risiken durch KI-generierten Code
• Qualitätsmanagement: Prozesse für die Qualitätssicherung von KI-generierten Outputs

Bei Verstößen drohen Bußgelder bis zu 15 Millionen Euro oder 3% des weltweiten Jahresumsatzes. Deutschland ist weltweit auf Platz 2 bei Vibe-Coding-Suchanfragen — die Relevanz für hiesige Unternehmen ist enorm.

Zahlen, die man sich merken sollte

• 42% allen Codes ist mittlerweile KI-generiert oder KI-unterstützt (Sonar-Umfrage)
• 25% der KI-Codebeispiele enthalten bestätigte OWASP-Top-10-Schwachstellen (AppSec Santa)
• 55,8% enthalten formal bewiesene Sicherheitslücken (Cobalt AI)
• 97,8% dieser Lücken werden von Standard-SAST-Tools nicht erkannt (Cobalt AI)
• 581 durchschnittliche Schwachstellen pro Codebasis — ein Anstieg von 107% im Jahresvergleich (Black Duck OSSRA)
• 20% der Unternehmen, die Vibe-Coding-Plattformen nutzen, stehen vor systemischen Sicherheitsrisiken (Wiz Research)

Fazit: Wegducken ist keine Option

KI-Coding-Tools sind aus der modernen Softwareentwicklung nicht mehr wegzudenken. Sie machen uns schneller, produktiver und befähigen mehr Menschen, Software zu bauen. Aber die Sicherheitslücken, die sie erzeugen, sind real, messbar und strukturell.

Die gute Nachricht: Die Lösungsansätze sind bekannt und umsetzbar. Automatisierte Sicherheitsanalyse in jeder Pipeline, sicherheitsbewusste Prompts, KI-gestützte Code-Reviews und menschliche Expertise als fallback bilden zusammen einen robusten Schutzschild.

Die schlechte Nachricht: Die meisten Teams tun noch nicht genug. Nur 24% der Organisationen führen laut Black-Duck-Studie umfassende Bewertungen von KI-generiertem Code durch. Das muss sich ändern — spätestens am 2. August, wenn der EU AI Act greift.

Wer jetzt handelt, hat einen Wettbewerbsvorteil. Wer es ignoriert, wird es bereuen.

---

Quellen: AppSec Santa 2026, Cobalt AI „Broken by Default" (arXiv:2604.05292), Black Duck OSSRA 2026, Wiz Research, Cycode AI Security Report 2026, Sherlock Forensics AI Code Security Report 2026, Secure Code Warrior & RMIT University Benchmarking Study