Wie Sie Produktionsumgebungen vor LLM-bedingten Schwachstellen schützen: Automatisierte Sicherheitsprüfung von KI-Code

von Denis Shokhirev, Enterprise AI Architect aus Freiburg — Ich betreibe DennisCraft AI Studio und liefere produktive KI-Lösungen für DACH-B2B-Kunden. Mein Stack: Claude, Supabase, n8n, Doppler, Postgres (self-hosted). Im produktiven Einsatz stoße ich regelmäßig auf ein wiederkehrendes Problem: LLM-Integrationen führen zu Schwachstellen, die unbemerkt in die Produktionsumgebung gelangen — trotz DSGVO, BSI-Grundschutz und ISO 27001-Vorgaben.

Typische Schwachstellen durch LLM-Code im Produktivbetrieb

In den letzten sechs Monaten habe ich in vier Fällen SQL-Injection-Muster im von LLM generierten Python- oder SQL-Code (Claude Code, OpenAI cookbook, gpt-4) direkt im Backend entdeckt. In zwei weiteren Fällen wurde ungefilterter User-Input an APIs weitergegeben; einmal wurde ein Doppler-Secret versehentlich im Log abgelegt. Solche Fehler entstehen vor allem dann, wenn n8n-Workflows oder Supabase-Edge-Funktionen automatisiert generiert und bereitgestellt werden — ohne ausreichende Prüfung.

Warum LLM-Code besonders riskant ist

• Automatisch generierter Code durchläuft selten ein menschliches Review.
• LLMs berücksichtigen keine vollständigen Geschäftsregeln oder Compliance-Anforderungen (z.B. DSGVO-Restriktionen).
• Updates gelangen über CI/CD automatisiert in die Produktion — ohne individuelle Freigabe.

Die 2023er Stanford CodeGen Benchmark-Studie (Quelle) fand in über 30% der LLM-generierten Python-Snippets mindestens ein häufiges CWE-Muster wie Injection oder unsichere Deserialisierung. Diese Werte spiegeln meine Erfahrungen im DACH-Markt wider.

Automatisierte Sicherheitsprüfung: Welche Tools im DACH-Stapel funktionieren

Statt auf manuelle Kontrolle zu setzen, etabliere ich automatisierte Sicherheitsprüfungen für jede LLM-generierte Code-Artefakt — noch vor dem Staging. Im produktiven Stack bewähren sich folgende Werkzeuge:

semgrep: Statische Analyse für LLM-generierten Code

semgrep lässt sich direkt als Schritt in n8n oder CI einbinden. Die Regeln können Sie auf Ihre LLM-typischen Muster anpassen:

semgrep --config=auto --include '**/*.py' --json > semgrep-report.json
cat semgrep-report.json | jq '.results[] | select(.extra.severity=="ERROR")'

So filtern Sie kritische Fehler automatisiert vor dem Staging-Einsatz.

bandit: Python-Code aus LLMs prüfen

Gerade für von LLM generierte Python-Funktionen (z.B. Supabase/Backend) ist bandit der Standard für statische Sicherheitsprüfung:

bandit -r ./generated_code/ -f json -o bandit-report.json
cat bandit-report.json | jq '.results[] | select(.issue_severity=="HIGH")'

gitleaks: Secret-Leaks im LLM-Code verhindern

LLMs können versehentlich echte oder plausible Secrets generieren. Mit gitleaks lässt sich das zuverlässig vor der Bereitstellung erkennen:

gitleaks detect --source=./generated_code/ --report-format=json --report-path=gitleaks.json
cat gitleaks.json | jq '.findings[] | select(.rule_id=="GithubToken")'

Sicherheitsprüfung automatisieren: n8n/Supabase-Muster aus dem Produktivbetrieb

Mein erprobtes Vorgehen: Jeder von einem LLM generierte Code-Artefakt (Skript, SQL, Backend-Funktion) wird sofort durch eine Kette von Scannern geprüft. Gibt es einen Fund, gelangt der Code nicht ins Staging. Das LLM erhält automatisiertes Feedback und generiert neu.

Beispiel-Workflow mit n8n

1. LLM generiert Code und speichert temporär
2. n8n triggert semgrep/bandit/gitleaks
3. Bei Fund: Workflow gibt Summary an das LLM (Claude/OpenAI) zurück
4. Schleife bis alle Scans bestanden sind

- name: LLM Code Generation
- name: semgrep Scan
  run: semgrep ...
- name: bandit Scan
  run: bandit ...
- name: gitleaks Scan
  run: gitleaks ...
- name: Conditional Feedback
  if: scan-failed
  action: prompt-agent-to-regenerate

Vorteile des Musters

• Schwachstellen werden vor dem Staging/Produktivbetrieb erkannt.
• Manuelles Review jeder Änderung entfällt.
• LLM-Fehler lassen sich systematisch auswerten und reduzieren.

Was statische Scanner nicht abdecken: Monitoring im Betrieb

Statische Analyse deckt 70–80% der Schwachstellen ab. Logikfehler oder Verstöße gegen Zugriffsregeln (z.B. DSGVO-ACLs) können jedoch durchrutschen. In der Produktion pflege ich ein Audit-Log in Postgres, das jede von LLM generierte Query inkl. Parameter protokolliert. Atypische Insert/Update/Delete-Muster (z.B. Massenänderungen, neue Schemata) lösen Alerts aus.

Beispiel: Audit-Trigger in Postgres

CREATE OR REPLACE FUNCTION audit_func()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO audit_log(table_name, changed_by, change_time)
  VALUES (TG_TABLE_NAME, current_user, NOW());
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_trigger
AFTER INSERT OR UPDATE OR DELETE ON critical_table
FOR EACH ROW EXECUTE FUNCTION audit_func();

FAQ

Erkennen statische Scanner wirklich 90% der LLM-Bugs?

Nein, realistisch sind es etwa 60–70%. Logik- und Runtime-Fehler müssen zusätzlich überwacht werden.

Können Sie LLM-Code ohne menschliches Review vertrauen?

Nein. Für kritische Funktionen ist mindestens ein stichprobenartiges Review notwendig.

Welcher CI/CD-Stack eignet sich für produktive KI-Projekte?

GitHub Actions als Orchestrierung, n8n für den Agenten-Workflow, Supabase als Backend, Postgres (self-hosted) für Audit-Logs.

Wie überwachen Sie Laufzeitangriffe?

Audit-Logs plus Anomalieerkennung der Query-Muster und Alerts auf verdächtige Aktionen/Payloads.

Welcher Scanner erkennt die meisten Bugs?

semgrep ist am effektivsten bei Python/JS-Code und generischen Schwachstellen.

In welcher Pipeline-Phase erkennen Sie die meisten Schwachstellen aus LLM-Integrationen — statische Analyse, Laufzeitüberwachung oder menschliches Review? Ich biete einen kostenfreien 30-Minuten-Stack-Audit für DACH-Unternehmen mit KI-Projekten im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.