Claude Code Security: Sicherheitslücken finden und Code absichern mit KI

Ein einziger SQL-Injection-Angriff kann eine Datenbank leeren. Ein hardcodierter API-Key im Repo kostet im schlimmsten Fall Tausende Euro durch missbrauchte Cloud-Ressourcen. Und ein fehlerhaft konfigurierter JWT-Check öffnet die Tür für jeden, der die Signatur kennt.

Security ist kein Feature, das man "später noch einbaut". Trotzdem enden Code Reviews in der Praxis oft nach zehn Minuten: Der Zeitdruck ist zu hoch, die Angriffsfläche zu groß, das Wissen zu verteilt. Claude Code ändert diese Gleichung. Als KI, die deinen gesamten Codebase liest und Angriffsmuster erkennt, macht es aus flüchtigem Security-Theater echte, systematische Überprüfung.

Dieser Artikel zeigt, wie du Claude Code konkret einsetzt: für OWASP-Reviews, Dependency-Scans, Secrets-Audits, Auth-Checks und Container-Sicherheit.

1. OWASP Top 10 und häufige Sicherheitslücken: SQL Injection, XSS, CSRF

Die OWASP Top 10 ist seit Jahren der de-facto-Standard für Web-Application-Security. Sie fasst die zehn gefährlichsten Schwachstellenklassen zusammen — von Injection über Broken Access Control bis zu Security Misconfiguration. Manuelle Reviews gegen diese Liste kosten Stunden. Claude Code erledigt einen Erst-Scan in Minuten.

SQL Injection erkennen

SQL Injection entsteht, wenn Nutzereingaben ungefiltert in SQL-Queries landen. Der Klassiker:

# Gefährlich — direktes String-Formatting in der Query
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)

Übergib Claude Code deine Datenbankzugriffsschicht und frag gezielt:

Analysiere alle Datenbankabfragen in src/db/ auf SQL-Injection-Risiken.
Markiere jede Stelle, wo Nutzereingaben ohne Parametrisierung
in SQL-Strings eingebaut werden. Zeig den Fix mit Prepared Statements.

Claude Code durchsucht alle Dateien, erkennt Muster wie String-Konkatenation, f-Strings und format()-Aufrufe in Query-Kontexten und schlägt Prepared Statements vor — für jede betroffene Stelle konkret, nicht nur als generellen Hinweis.

Cross-Site Scripting (XSS)

XSS-Lücken entstehen, wenn Nutzerdaten ungefiltert als HTML gerendert werden. In React ist dangerouslySetInnerHTML das offensichtlichste Warnsignal, aber auch serverseitiges Templating kann betroffen sein.

Suche in meinem React-Frontend nach allen Stellen, wo
dangerouslySetInnerHTML verwendet wird oder DOM-Manipulation
ohne DOMPurify stattfindet. Bewerte das Risiko je nach
Datenherkunft (API-Response vs. user_input).

Besonders wertvoll: Claude Code unterscheidet zwischen Daten aus kontrollierten API-Endpunkten und echten Nutzereingaben — und priorisiert die Findings entsprechend.

CSRF-Schutz verifizieren

Cross-Site Request Forgery (CSRF) trifft zustandsändernde Endpunkte, die keine Origin-Prüfung haben. Der Prompt:

Prüfe alle POST/PUT/DELETE-Endpunkte in routes/ auf CSRF-Schutz.
Welche Endpunkte fehlen CSRF-Token-Validierung?
Welche sind durch SameSite-Cookies oder CORS bereits abgesichert?

Vollständiger OWASP-Scan

Für einen systematischen Überblick nutze diesen Prompt einmal pro Sprint:

Führe einen OWASP Top 10 Review meines Projekts durch.
Für jede Kategorie:
1. Sind in meinem Code potenzielle Schwachstellen vorhanden?
2. Konkrete Dateipfade und Zeilennummern
3. Schweregrad: Kritisch / Hoch / Mittel / Niedrig
4. Empfohlener Fix

Kategorien: Injection, Broken Auth, Sensitive Data Exposure,
XXE, Broken Access Control, Security Misconfiguration,
XSS, Insecure Deserialization, Known Vulnerabilities, Logging.

2. Dependency-Scanning und Supply Chain Security: npm audit, Snyk, SBOM

Der SolarWinds-Angriff 2020 hat gezeigt, was Supply Chain Attacks bedeuten: Schadhafter Code landet über legitime Dependencies im eigenen Projekt — und niemand merkt es, weil die Checksums stimmen. Seitdem ist Dependency-Security kein Nischenthema mehr.

npm audit verstehen und priorisieren

npm audit listet bekannte CVEs in deinen Dependencies — aber oft mit Dutzenden Findings, von denen viele nicht ausnutzbar sind. Claude Code hilft beim Triage:

Ich paste dir den Output von `npm audit --json`.
Analysiere die Findings und kategorisiere sie:
- Direkt ausnutzbar in meinem Setup (mit Begründung)
- Transitive Abhängigkeiten, nicht direkt angreifbar
- False Positives (vulnerability existiert, aber code path nicht erreichbar)

Priorisiere nach echtem Risiko, nicht nach CVSS-Score allein.

Das spart erheblich Zeit: Statt 47 Findings abzuarbeiten, siehst du sofort die drei, die wirklich gefährlich sind.

Snyk-Integration

Snyk erweitert npm audit um lizenzbasierte Risiken und Runtime-Vulnerabilities. Mit Claude Code kannst du Snyk-Reports direkt analysieren lassen:

Hier ist mein Snyk-Report als JSON. Erkläre mir für die
Top-5-Findings je:
- Wie der Angriff konkret aussehen würde
- Ob wir den verwundbaren Code-Pfad überhaupt nutzen
- Den konkreten Update-Befehl oder Workaround

Software Bill of Materials (SBOM) erstellen

Ein SBOM ist ein maschinenlesbares Inventar aller Komponenten eines Projekts. Seit Executive Order 14028 in den USA ist es für staatliche Software Pflicht — und auch für B2B-Enterprise-Verkäufe zunehmend Voraussetzung.

Erstelle ein SBOM für mein Projekt nach SPDX-Standard.
Liste alle direkten und transitiven Dependencies mit:
- Paketname und Version
- Lizenz
- Bekannte CVEs (Stand heute)
- Herkunfts-Repository

Format: JSON, bereit für Cyclone DX oder SPDX.

Verdächtige Packages erkennen

Typosquatting und Dependency Confusion sind reale Angriffsvektoren. Claude Code kann deine package.json auf Auffälligkeiten prüfen:

Analysiere meine package.json auf Risiko-Indikatoren:
- Sehr neue Packages ohne Sterne/Downloads (potentielles Typosquatting)
- Packages mit ungewöhnlichen Post-Install-Scripts
- Packages, die Systemzugriff oder Netzwerkzugriff fordern
- Direkte Abhängigkeiten mit sehr viel zu breiten Permissions

3. Secrets Management: Vault, AWS Secrets Manager, keine Hardcoded Keys

Laut GitGuardian werden jeden Tag über 10.000 Secrets in öffentlichen GitHub-Repos committed. API-Keys, Datenbankpasswörter, Zertifikate — einmal im Git-History, immer im Git-History. Claude Code hilft sowohl beim Finden als auch beim Beseitigen des Problems.

Secrets im Code aufspüren

Der erste Schritt ist ein vollständiger Scan nach hartcodierten Credentials:

Durchsuche den gesamten Codebase nach hardcodierten Secrets.
Suche nach:
- API-Keys (typische Muster: sk_, pk_, api_key=, token=)
- Datenbankverbindungsstrings mit Passwörtern
- Private Keys (-----BEGIN RSA PRIVATE KEY-----)
- JWT-Secrets direkt im Code
- Base64-encodierte Credentials
- Passwörter in Konfigurationsdateien

Gib Datei, Zeile und Kontext aus — nicht den Key selbst.

Claude Code erkennt dabei auch verschleierte Muster wie Base64-encodierte Keys oder Secrets in scheinbar harmlosen Variablennamen wie config.token.

Migration zu Umgebungsvariablen

Der einfachste erste Schritt ist die Migration zu .env-Dateien mit dotenv:

Ich habe folgende hardcodierte Keys gefunden (zeige Liste).
Erstelle:
1. Eine .env.example mit allen Keys als Platzhalter
2. Den Refactored Code, der os.environ / process.env nutzt
3. Den .gitignore-Eintrag für .env
4. Ein README-Abschnitt, wie neue Entwickler die Keys setzen

HashiCorp Vault integrieren

Für Produktionsumgebungen ist Vault der Standard für Secrets Management. Claude Code kann dir die Integration schreiben:

Erstelle eine Vault-Integration für meine Node.js-App.
Anforderungen:
- AppRole-Authentifizierung (kein Token hardcoded)
- Secrets werden beim App-Start geladen und gecacht
- Rotation wird unterstützt (bei Vault-Signal neu laden)
- Fallback auf Umgebungsvariablen für lokale Entwicklung
- Fehler beim Secret-Load beenden die App (fail fast)

AWS Secrets Manager

Auf AWS-Infrastruktur ist AWS Secrets Manager die native Lösung — mit automatischer Rotation für RDS-Credentials:

Migriere meine AWS-Konfiguration auf Secrets Manager.
Aktuell: Datenbankpasswort als Umgebungsvariable in ECS Task Definition
Ziel: Secrets Manager mit automatischer RDS-Rotation alle 30 Tage
Schreibe: IAM Policy, Lambda Rotation Function, Python SDK Integration

Pre-commit Hooks gegen Secret-Leaks

Das beste Secrets Management ist das, das Commits mit Secrets verhindert:

Erstelle einen pre-commit Hook der:
1. Mit `detect-secrets` scannt
2. Bekannte False-Positives (Test-Keys, Fixture-Daten) in .secrets.baseline hält
3. Bei Fund: Commit abbricht und Zeile zeigt
4. In .pre-commit-config.yaml integriert ist

4. Authentifizierung und Autorisierung: OAuth2, JWT, RBAC

Broken Authentication ist OWASP-Kategorie zwei — und einer der häufigsten Einfallstore für Angreifer. Ein falsch implementiertes JWT, eine zu weite CORS-Policy oder ein fehlendes RBAC-Check lassen sich schwer durch Tests entdecken, weil sie im Normalfall "funktionieren". Claude Code liest den Code wie ein Security-Auditor.

JWT-Implementierung prüfen

JSON Web Tokens haben einige typische Fallstricke: kein Expiry, unsicherer Algorithmus, fehlende Signatur-Verifikation. Der Prompt:

Analysiere meine JWT-Implementierung in auth/ auf diese Schwachstellen:
1. Wird der Algorithm explizit auf HS256/RS256 eingeschränkt?
   (Angriff: Algorithm=none bypass)
2. Gibt es ein Expiry (exp) und wird es geprüft?
3. Wo wird der Secret gespeichert? (nie im Code)
4. Gibt es Token-Refresh-Logik oder laufen Tokens ewig?
5. Werden JWTs nirgendwo in URLs übergeben? (Leakage via Logs)

Der "Algorithm=none"-Angriff ist berüchtigt: Viele frühe JWT-Libraries akzeptierten alg: none als gültigen Algorithmus — womit ein Angreifer die Signatur einfach weglassen konnte. Claude Code erkennt, ob du die Library-Version verwendest, die das gepatcht hat.

OAuth2-Flow auf Korrektheit prüfen

Prüfe meinen OAuth2-Authorization-Code-Flow:
- Wird der state-Parameter korrekt validiert? (CSRF-Schutz)
- Wird der Authorization Code nur einmal verwendet?
- Werden Access- und Refresh-Token sicher gespeichert?
  (nicht in localStorage — HttpOnly Cookie!)
- Wird das id_token auf nonce und audience geprüft?
- Gibt es PKCE bei public clients (SPAs, Mobile)?

Role-Based Access Control (RBAC) implementieren

Broken Access Control ist OWASP-Platz 1. Der häufigste Fehler: Auth prüft nur "ist der User eingeloggt", nicht "darf er das".

Implementiere RBAC für meine Express-API:
Rollen: admin, editor, viewer
Ressourcen: posts, users, settings

Anforderungen:
- Middleware-basiert, nicht Inline-Checks überall
- Permissions als Enum, nicht Magic Strings
- Jede Route explizit annotiert (kein "vergessen" möglich)
- Fehler: 403 (nicht 401) bei fehlender Permission
- Teste mit Unit Tests für jeden Rollenpfad

Session-Management absichern

Prüfe mein Session-Management auf diese Schwachstellen:
- Session-Fixation: wird die Session-ID nach Login regeneriert?
- Session-Timeout: gibt es absolutes und inaktives Timeout?
- Secure/HttpOnly/SameSite auf Session-Cookie gesetzt?
- Werden Sessions beim Logout serverseitig invalidiert?
- Gibt es Concurrent-Session-Limits?

5. Security Code Reviews mit Claude Code: SAST und Threat Modeling

Static Application Security Testing (SAST) ist klassisch ein Tool-Problem: SonarQube, Semgrep, Checkmarx scannen Code nach bekannten Mustern. Claude Code geht weiter — es versteht den Kontext, erkennt Business-Logic-Fehler und kann Threat Modeling durchführen.

SAST mit Claude Code

Für einen vollständigen SAST-ähnlichen Scan gibt es diesen systematischen Prompt:

Führe einen statischen Security-Scan meines Projekts durch.
Prüfe auf diese Schwachstellenklassen:
- Command Injection (os.system, eval, exec mit Nutzerdaten)
- Path Traversal (Dateioperationen mit Nutzerdaten ohne Sanitization)
- Open Redirects (Weiterleitungen auf externe URLs ohne Whitelist)
- Insecure Deserialization (pickle.loads, YAML.load ohne SafeLoader)
- XXE (XML-Parsing ohne Entity-Auflösung deaktiviert)
- SSRF (HTTP-Anfragen auf Nutzerdaten-URLs)
- Mass Assignment (Object-Hydration ohne Whitelist)

Format: Kritisch → Hoch → Mittel → Niedrig, je mit Datei:Zeile und Fix.

Threat Modeling: STRIDE mit Claude Code

Threat Modeling ist Security-Planung bevor Code geschrieben wird. STRIDE ist ein Framework von Microsoft, das sechs Angriffskategorien abdeckt: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Erstelle ein Threat Model für meine Anwendung nach STRIDE.
Architektur: [beschreibe kurz deine Architektur, z.B.
React SPA → Node API → PostgreSQL + Redis, gehostet auf AWS ECS]

Für jede STRIDE-Kategorie:
1. Konkrete Bedrohungen in meinem Setup
2. Aktuell vorhandene Gegenmaßnahmen
3. Lücken und empfohlene Controls
4. Priorität nach Wahrscheinlichkeit × Impact

Security Review für Pull Requests

Integriere Security Reviews direkt in deinen PR-Workflow:

Ich zeige dir den Diff dieses Pull Requests.
Führe einen Security-fokussierten Code Review durch:

1. Neue Angriffsfläche: Welche neuen Eingabepfade entstehen?
2. Validierung: Werden alle Inputs sanitized?
3. Auth-Checks: Sind alle neuen Endpunkte geschützt?
4. Secrets: Gibt es hardcodierte Credentials oder Logs mit Secrets?
5. Fehlerbehandlung: Leaken Error-Messages interne Infos?
6. Regression: Könnte der Change existierende Security-Controls brechen?

Ausgabe: Security-Findings sortiert nach Kritikalität.

Security Champions Programm

Teams, die Security in ihre Entwicklungskultur integrieren wollen, nutzen Security Champions — Entwickler, die als Security-Ansprechpartner fungieren, ohne Security-Experten zu sein. Claude Code ist das ideale Werkzeug für Security Champions:

Erkläre mir diese Schwachstelle (zeige Codezeile) so,
dass ich sie meinen Kollegen in einem 5-Minuten-Slot erklären kann:
- Was ist die Schwachstelle?
- Wie würde ein Angriff konkret aussehen? (Beispiel-Payload)
- Warum ist der Fix der richtige Weg?
- Gibt es ähnliche Stellen im Codebase, die ich auch prüfen sollte?

6. Container und Infrastruktur Security: Docker Scanning, Terraform Security

Applikationscode ist nur eine Schicht. Container-Images, Kubernetes-Configs und Terraform-Dateien sind genauso Teil der Angriffsfläche — und werden in Security Reviews oft vergessen. Claude Code liest auch YAML, Dockerfile und HCL.

Dockerfile Security Review

Prüfe mein Dockerfile auf Security-Best-Practices:
1. Base Image: Nutze ich ein minimales Image (alpine/distroless)?
   Gibt es bekannte CVEs im verwendeten Image-Tag?
2. Root-User: Läuft der Container als root?
   (Pflicht: USER nonroot hinzufügen)
3. Secrets: Gibt es ARG oder ENV mit Credentials?
4. Layer-Hygiene: Werden APT-Listen nach Install gelöscht?
5. Multi-Stage Build: Sind Build-Tools im finalen Image?
6. Read-only Filesystem: Ist --read-only möglich?

Zeige: Was ist problematisch + das korrigierte Dockerfile.

Ein häufiger Fehler ist das Kopieren von .env-Dateien ins Image mit COPY . . — Claude Code erkennt das und schlägt ein .dockerignore vor.

Trivy für Image Scanning

Trivy ist der de-facto-Standard für Container-Image-Scanning. Integration mit Claude Code:

Hier ist der Trivy-Scan-Report meines Docker-Images (JSON).
Analysiere:
1. Welche HIGH/CRITICAL CVEs sind tatsächlich ausnutzbar?
2. Welche Packages brauche ich überhaupt? (Kandidaten für Entfernung)
3. Welches Base-Image-Update würde die meisten CVEs eliminieren?
4. Schreibe den GitHub Actions Step für automatisches Scanning im CI.

Kubernetes RBAC und Pod Security

Prüfe meine Kubernetes-Manifeste auf Security-Issues:
1. ServiceAccounts: Welche Pods haben zu weite RBAC-Berechtigungen?
2. Pod Security Context: Fehlende runAsNonRoot, readOnlyRootFilesystem?
3. Network Policies: Gibt es Default-Deny-All als Baseline?
4. Secrets: Werden K8s Secrets als Env-Vars (schlecht) oder
   Volumes (besser) oder External Secrets Operator (best) eingebunden?
5. Resource Limits: CPU/Memory Limits gesetzt? (DoS-Schutz)

Terraform Security mit tfsec / Checkov

Infrastructure as Code hat eigene Schwachstellenklassen: öffentlich zugängliche S3-Buckets, zu weite IAM-Policies, unverschlüsselte Datenbanken.

Analysiere meine Terraform-Konfiguration auf Security-Schwachstellen:
1. S3-Buckets: Sind alle öffentlichen ACLs deaktiviert? Versioning+Logging aktiv?
2. IAM: Gibt es Policies mit "*" als Action oder Resource?
3. Security Groups: Ports 0-65535 oder 0.0.0.0/0 Ingress?
4. Encryption: RDS/EBS/SQS/SNS mit KMS verschlüsselt?
5. Logging: CloudTrail aktiv? VPC Flow Logs?
6. Public Resources: EC2 in öffentlichen Subnetzen ohne Notwendigkeit?

Zeige: Terraform-Code-Fix für jedes Finding.

CI/CD Pipeline Security

Prüfe meine GitHub Actions Workflow-Dateien:
1. Werden Secrets korrekt als GitHub Secrets eingebunden (nie als Klartext)?
2. Gibt es Third-Party Actions mit zu weiten Permissions?
3. Wird GITHUB_TOKEN auf minimum-permissions gesetzt?
4. Gibt es Pull-Request-Workflows, die Code aus Forks mit Secrets ausführen?
   (GitHub Actions TOCTOU-Problem)
5. Sind alle externen Actions auf SHA-Commit gepinnt (nicht @main)?

Fazit: Security als kontinuierlicher Prozess, nicht als einmaliges Audit

Security ist keine Checkbox. Es ist ein kontinuierlicher Prozess, der bei jedem Commit beginnt und nie wirklich endet. Das Problem war bisher: Gründliche Security Reviews brauchen viel Zeit und spezialisiertes Wissen — beides ist in den meisten Entwicklungsteams knapp.

Claude Code verschiebt die Gleichung. Ein OWASP-Scan, der vorher einen halben Tag dauerte, dauert jetzt eine Stunde. Ein Threat Model, das sonst einen externen Consultant erfordert, entsteht als erster Draft in zwanzig Minuten. Dependency-Triage, JWT-Checks, Dockerfile-Reviews — alles wird schneller, systematischer und weniger abhängig von Einzelpersonen mit Spezialwissen.

Der richtige Einsatz ist als Multiplikator: Claude Code macht dein vorhandenes Wissen schlagkräftiger und hilft dabei, die Lücken zu finden, die im Stress des Alltags durchrutschen. Das ist kein Ersatz für Security-Expertise — aber ein enormer Hebel für Teams, die beides wollen: schnell entwickeln und dabei sicher bleiben.

"Security is not a product, but a process." — Bruce Schneier

Mit Claude Code wird dieser Prozess endlich in den normalen Entwicklungsalltag integrierbar — ohne extra Overhead, ohne separates Security-Sprint, ohne Warten auf das nächste externe Audit.