Security-Checklist für Claude Code & Co.
LinkedIn-Bild des Tages: Paul Joshua Kramer (cybersec architect) mit seiner "Claude Code App Security Checklist" . Acht simple Punkte – und trotzdem stolpert fast jedes AI-Projekt über mindestens zwei davon. Hier die Lis …
AI Dev-Teams, Prompt-Engineers, Security Leads.
Grundverständnis von Claude Code bzw. AI-Coding-Assistenten.
LinkedIn-Bild des Tages: Paul Joshua Kramer (cybersec architect) mit seiner "Claude Code App Security Checklist". Acht simple Punkte – und trotzdem stolpert fast jedes AI-Projekt über mindestens zwei davon. Hier die Liste in Textform, dazu ein paar Ergänzungen aus unserer Erfahrung.
Pauls Liste (übersetzt & kondensiert)
- Authorization: Wer darf eigentlich was? Granulare Rollen, Token-Scopes, Policy-as-Code.
- Input Validation: Prompts, Files, URLs → alles sanitizen, Escape-Filter vor API-Calls.
- Rate Limiting: Nicht nur OpenAI/Anthropic, auch intern (Hooks, Webhooks, Plugins).
- Fail-Safe Defaults: Wenn etwas unsicher ist → Block. Keine heimlichen Fall-Throughs.
- Error Handling: Stacktraces gehören in Logs, nicht ins User-UI. Maskiere Secrets.
- Observability Alerts: Metriken, Logs, Trace – und echte Alerts mit Ownership.
- Staging (pre-prod): LLM-Flows zuerst in isolierten Test-Umgebungen fahren.
- Post-Prod Monitoring: Laufende Audits, Pen-Tests, Replay-Checks.
Quelle: LinkedIn-Post von Paul Joshua Kramer
Praxis-Erweiterungen
| Block | Warum | Tooling/Beispiel |
|---|---|---|
| Secrets & Config | Claude-Code-Apps verarbeiten API-Keys, Kundendaten → .env in Vault, Rotations-Plan, keine Keys in Logs. | Doppler, Hashi Vault, AWS Secrets Manager |
| Dependency Hygiene | Supply-Chain-Angriffe (z. B. Fake „litellm“ auf PyPI) treffen AI-Stacks hart. Hash-Pinning + pip-audit. |
pip-tools, Poetry.lock + pip install --require-hashes |
| Data Classification | Welche Daten landen im Prompt? Maskieren? Tokengrenzen? Definiere PII-Level & Speicherorte. | Data Catalog, Open Policy Agent |
| Kill-Switch & RBAC | Jede Runtime braucht einen großen roten Button (Disable Workflows) + feinmaschiges RBAC (z. B. IAM + OPA). | Grafana OnCall, LaunchDarkly |
| Human-in-the-Loop | Code- oder Action-Review via Four-Eyes (PR-Gates, Anthropic Tool Use Approvals). | GitHub Checks, Slack Approval Bots |
Quick Checklist für dein Projekt
- [ ] Perimeter: TLS überall, Redirects geschlossen, WAF an oder Cloudflare Turnstile.
- [ ] Identity: OIDC / SSO statt Custom JWT, Secrets im Vault, Tokens revoken können.
- [ ] Data Path: Prompt-Filter (Regex, Schema-Validator), Logging mit PII-Redaction.
- [ ] Runtime: Resource-Quotas, Liveness/Readiness-Checks, Auto-Restart (Supervisor/systemd).
- [ ] Supply Chain: SBOM (CycloneDX), Dependabot/Mend, Signaturprüfung bei Container-Pulls.
- [ ] Incident Runbook: Wer macht was, wenn Claude plötzlich SSH-Befehle spammt?
Fazit
LLM-Coding-Stacks sind nur so sicher wie ihre kleinste Automatisierung. Pauls Poster ist ein guter Start – aber setzt noch eine Schicht drauf: Secrets, Supply Chain, Observability und vor allem ein Kill-Switch. Wer Claude Code „einfach laufen lässt“, baut sich schneller einen Angriffsvektor als ein Feature.
Bonus: Ich arbeite gerade an einem YAML-Template (security-checklist.yml), das man bei jedem Claude-/Cursor-Projekt in den Repo-Root legen kann. Ping mich, wenn du Betatester:in sein willst.