Security-Audits mit Claude Code praktisch durchführen

Security nicht ungeprüft an KI übergeben

Claude Code kann Security-Audits deutlich beschleunigen. Es kann Routen lesen, Pull-Request-Diffs vergleichen, Dependency-Risiken zusammenfassen, riskante Logs suchen, Umgebungsvariablen finden und wiederkehrende Review-Schritte in Checklisten verwandeln. Das hilft, weil echte Risiken selten in einer einzigen Datei liegen. Sie verteilen sich auf Auth-Middleware, Berechtigungen, Billing-Jobs, Webhooks, CI und Logs.

Der Fehler ist, nur “prüfe die Sicherheit” zu schreiben und die Antwort als Nachweis zu behandeln. Ein Audit ist kein Bauchgefühl. Es ist eine Review mit Scope, Assets, Bedrohungen, Kontrollen, Evidenz und Restrisiko. Claude Code kann recherchieren und ordnen, aber die Entscheidung über Geschäftsrisiko, Disclosure und Release bleibt bei Menschen.

Dieser Leitfaden zeigt einen praktischen Ablauf für Claude Code, ohne gefährliche Exploit-Details zu veröffentlichen. Er behandelt Scope, Asset-Inventar, Threat Model, Dependency Review, Auth- und Session-Review, Secrets, Input Validation, Logging und PII, CI-Gates, Evidence Receipts und vier typische Use Cases. Als externe Basis eignen sich OWASP Top 10, OWASP ASVS, NIST SSDF und GitHubs Dokumentation zu secret scanning.

Zuerst den Scope festlegen

Das erste Ergebnis ist kein Fix, sondern ein Audit-Brief. Der Scope sagt Claude Code, was geprüft wird, was nicht verändert werden darf, welche Befehle erlaubt sind und wann die Arbeit abgeschlossen ist. Ohne Scope kommentiert die KI oft sichtbare Dateien und übersieht Admin-Routen, Billing-Flows, Hintergrundjobs, Deployment-Skripte oder CI-Secrets.

Diese Vorlage kann direkt in die Session kopiert werden.

# Security Audit Brief

## Goal
- Find serious issues in authentication, authorization, secrets, input validation, logging, and dependencies before release
- Produce evidence and remaining-risk notes, not just suggested fixes

## Scope
- Repository:
- Branch or PR:
- Feature or workflow:
- Directories Claude Code may inspect:
- Directories Claude Code must not change:
- Commands Claude Code may run:

## Priority areas
- Authentication and session handling
- Authorization and roles
- Input validation and output encoding
- Secrets and environment variables
- Dependencies and licenses
- Logs, PII, and audit events
- CI gates that should block release

## Completion criteria
- Record findings in the risk register
- Include only minimal reproduction context
- Do not include live secrets, customer data, or dangerous exploit instructions
- Record commands, results, skipped areas, and human-review items in the evidence receipt

Danach sollte Claude Code zuerst kartieren, nicht ändern: “Liste Routen, Auth-Middleware, externe APIs, Environment Variables, Logging-Punkte, CI-Jobs und Hochrisiko-Dateien. Noch keine Codeänderungen.” So kann der menschliche Reviewer fehlende Bereiche erkennen, bevor der Audit zu eng wird.

Asset-Inventar und Threat Model

Security beginnt mit der Frage, was geschützt werden muss. Assets sind Nutzerdaten, Billing-Status, API-Keys, Admin-Oberflächen, Audit-Logs, Uploads, Support-Nachrichten und Analytics-Daten. Ein Threat Model ist eine kleine Karte: Wer könnte über welchen Einstiegspunkt was angreifen, und welche Kontrolle sollte das stoppen?

| Asset | Stored in | Entry point | Likely threat | Required control | Owner |
| --- | --- | --- | --- | --- | --- |
| User email address | users table | signup, admin | unauthorized access, log leakage | authorization, PII masking, audit log | backend |
| Billing status | billing table, Stripe | webhook, admin | tampering, duplicate processing | signature verification, idempotency, role checks | backend |
| API keys | env, secret manager | CI, runtime | repository leak, log exposure | secret scanning, rotation, least privilege | platform |
| Admin console | /admin | browser | privilege escalation | MFA, admin role, operation logs | product |

Gib diese Tabelle an Claude Code und lasse Trust Boundaries und Tests ergänzen. Eine Trust Boundary trennt kontrollierte Bereiche von Eingaben, die nicht vertraut werden dürfen. Browser-Eingaben, Webhooks, importierte CSVs, Markdown, Dateinamen und Antworten externer APIs sollten vor Verwendung validiert werden.

Klare Review-Spuren vorgeben

Dependency Review umfasst package.json, Lockfiles, Docker Images, GitHub Actions, Runtime-Versionen und transitive Dependencies. npm audit ist nur ein Signal. Claude Code soll erreichbares Produktionsrisiko von Development-Rauschen trennen, Breaking Changes erklären und nennen, welche Tests nach einem Update bestanden sein müssen.

Auth- und Session-Review prüft Login, Logout, Password Reset, MFA, OAuth, Cookie Flags, Session Expiration, CSRF und serverseitige Autorisierung. “Der Nutzer ist eingeloggt” und “der Nutzer darf diese Aktion ausführen” sind unterschiedliche Fragen. Admin-APIs, Billing-Aktionen, Downloads, User-IDs in Routen und wiederholbare Webhooks sind typische Schwachstellen.

Secrets Review umfasst .env, CI-Secrets, Beispielkonfigurationen, README, Logs, Screenshots und Test-Fixtures. Claude Code darf echte Secrets nicht in den Chat schreiben. Bei einem Verdacht gehören Pfad, Secret-Typ, Rotationsempfehlung und Owner in den Bericht, der Wert bleibt maskiert. Bei GitHub sollten secret scanning und push protection geprüft werden.

Input Validation folgt dem Datenfluss: Wo kommt der Wert hinein, wo wird er gespeichert, gerendert oder weitergesendet? Bitte Claude Code nicht um gefährliche Payloads. Frage nach Boundary Validation, Normalisierung, Escaping, Typprüfung und Tests. Für Einsteiger ist Datenflussdenken nützlicher als das Auswendiglernen von Schwachstellennamen.

Logging und PII erfordern die Suche nach E-Mail-Adressen, Namen, Adressen, Tokens, Cookies, Auth-Headers, Payment-IDs und Freitext. Ein console.log aus der Entwicklung kann in Produktion zum Retention-Problem werden. Logs sollten nur die minimal nötigen Felder für Debugging und Audit enthalten.

Vier praktische Use Cases

Der erste Use Case ist ein Pre-Release-Audit für SaaS. Vor Billing, Einladungen, Organisationssettings oder Admin-Funktionen lässt man Claude Code PR-Diff, Migrationen, Routen, Webhooks, Tests und CI lesen. Ziel ist ein Risikoregister für das Release-Meeting, nicht ein pauschaler Satz “alles sicher”.

Der zweite Use Case ist ein GitHub-Handoff-Audit. In übernommenen Repositories stecken Risiken oft in Deployment-Skripten, CI-Secrets, Environment-Namen, manuellen Runbooks und Verzeichnissen ohne Owner. Claude Code kann eine Checkliste für die erste Woche erstellen: welche Keys rotieren, welche Abläufe dokumentieren, welche CI-Gates fehlen und wo menschliche Owner gebraucht werden.

Der dritte Use Case ist ein Audit nach einem Incident. Nach Ausfall oder Leckverdacht reicht es nicht, nur die auslösende Zeile zu korrigieren. Claude Code soll ähnliche Muster suchen, Logs auf PII prüfen, Regressionstests vorschlagen, CI-Gates ergänzen und Runbooks aktualisieren. Öffentliche Berichte sollten Wirkung und Abhilfe erklären, ohne ausnutzbare Details zu verbreiten.

Der vierte Use Case ist Security Review für KI-generierte PRs. Generierter Code kann ordentlich aussehen und trotzdem Autorisierung, Audit-Logs, Error Handling oder Tests vergessen. Bitte Claude Code, nur den Security Impact des Diffs zu prüfen: Attack Surface, Permissions, Secrets, persönliche Daten, Dependency Changes und CI Coverage.

Risikoregister und Evidence Receipt

Findings brauchen Evidenz. Severity allein reicht nicht. Das Register hält Impact, Beobachtung, Empfehlung, Priorität, Status und Owner fest.

| ID | Risk | Impact | Evidence | Recommended action | Priority | Status | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | Missing authorization on admin API | Another user's data may be changed | routes/admin.ts has no role check | Add middleware and regression tests | High | Open | backend |
| SEC-002 | Webhook logs include email | Unnecessary PII retention | logs/webhook-sample.txt | Mask email and reduce retention | Medium | Open | platform |

Das Evidence Receipt verhindert, dass der Audit nur aus schwer auffindbaren Chat-Nachrichten besteht.

# Security Audit Evidence Receipt

- Target:
- Date:
- Reviewer:
- Scope provided to Claude Code:
- Commands executed:
- Files or directories inspected:
- High-risk findings:
- Fixed items:
- Skipped or out-of-scope areas:
- Decisions requiring human review:
- Release recommendation:

PR-Review-Checkliste

Für Pull Requests sollte die Checkliste kurz in den Review-Prompt kopiert werden. Bei KI-generierten Änderungen zwingt sie die Diskussion auf Risiko und Evidenz statt auf Stil.

## Security PR Review

- [ ] Scope is clear and no unrelated files are changed
- [ ] Authenticated users cannot access another user's data
- [ ] Admin or billing actions require explicit authorization
- [ ] Inputs are validated at the boundary
- [ ] Outputs are escaped or rendered safely
- [ ] No secrets, tokens, cookies, or PII are printed to logs
- [ ] Dependency changes have a reason and test evidence
- [ ] Errors do not reveal internals
- [ ] CI includes lint, tests, typecheck, and security-relevant checks
- [ ] Risk register and evidence receipt are updated

Command-Checkliste

Die Befehle hängen vom Stack ab, aber ein Node- oder TypeScript-Projekt kann oft so starten. Claude Code sollte vor jedem Befehl den Zweck erklären und bei Fehlern anhalten.

git status --short
npm ci
npm audit --audit-level=moderate
npm run lint
npm run typecheck
npm test
rg -n "TODO|FIXME|console\\.log|process\\.env|localStorage|innerHTML|dangerouslySetInnerHTML" src
git diff --check

rg-Treffer sind Hinweise, keine Urteile. process.env kann korrekt sein. innerHTML kann zulässig sein, wenn es bereinigt wird. Claude Code sollte Evidenz, Annahme und Bestätigungsschritt sauber trennen.

Häufige Fehler

Der größte Fehler ist ein vager Prompt. “Prüfe Security” erzeugt oft oberflächliche Antworten. Ein guter Prompt nennt Scope, Assets, Release-Termin, erlaubte Befehle, kritische Flows und Ausgabeformat. Ein Bericht mit klaren “nicht geprüft”-Bereichen ist wertvoller als ein selbstsicherer Absatz ohne Nachweis.

Der zweite Fehler ist fehlende Evidenz. Wenn niemand weiß, welche Befehle liefen, welche Dateien geprüft wurden und was außerhalb des Scopes lag, kann der Audit keine Release-Entscheidung stützen. Aussagen von Claude Code müssen mit CI, Tests, Diffs, Logs und Konfiguration abgeglichen werden.

Gefährlich ist auch zu viel Veröffentlichung. Keine echten URLs, Tokens, Kundendaten oder Schritt-für-Schritt-Exploit-Anleitungen in öffentliche Issues oder Artikel. Öffentlich gehören Impact und Remediation. Sensible Reproduktion gehört in ein eingeschränktes System.

Secrets und Logs dürfen nicht unterschätzt werden. Auch saubere Anwendungscodes können über CI-Logs, Debug-Screenshots, Beispiel-.env oder ausführliche Fehler leaken. Für Auth, Payments, persönliche Daten und Admin-Tools bleibt menschliche Review Pflicht.

In CI und Teamgewohnheiten integrieren

Einmalige Audits altern schnell. Ergänze CI-Gates für lint, typecheck, tests, dependency audit, secret scanning, Suche nach gefährlichen APIs und Logging-Regeln. Nicht jede Warnung muss blockieren. Praktisch ist: High blockiert, Medium bekommt ein datiertes Ticket, Low geht in regelmäßige Wartung.

Auch Claude-Code-Rechte gehören geprüft. Lies dazu den Claude Code Permissions Guide, Secrets Management, Security Failure Cases und Code Review mit Claude Code. Wenn dein Team Audit-Brief, CI-Gates und Review-Policy im echten Repository verankern möchte, passt Claude Code Training und Beratung.

Zusammenfassung

Claude Code ist im Security-Audit dann stark, wenn Menschen das System darum bauen: Scope, Assets, Threat Model, Review-Spuren, Risikoregister, Evidence Receipt, CI und menschliche Freigabe für kritische Entscheidungen. Ohne diese Struktur klingt der Bericht vielleicht gut, erklärt aber das reale Risiko nicht.

Als Masa diesen Ablauf bei ClaudeCodeLab vor Releases eingesetzt hat, brachten Risikoregister und Evidence Receipt den größten Nutzen. Claude Code inventarisierte zuerst Routen, Logs, Environment Variables und CI; danach war die menschliche Review deutlich gezielter. Das Ergebnis war keine perfekte Sicherheitsgarantie, sondern eine klarere Release-Entscheidung.