67476ea59b
Same skills in .agents/skills (Codex) and .claude/skills (Claude Code): codeguard, security-review, dependency-vetting, pre-release-gate, authz-idor-audit, threat-model-light. Source: cj/claude-skills. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.5 KiB
2.5 KiB
| name | description |
|---|---|
| threat-model-light | Leichtgewichtiges Threat-Model für eine App oder ein Feature: Assets, Angreifer, Vertrauensgrenzen, Risiken mit Maßnahme und prüfbarem Beleg. Eine Seite, kein STRIDE-Roman. TRIGGER WENN der User sagt: "Threat Model", "Bedrohungsanalyse", "was kann schiefgehen", "Risiken", "/threat-model-light", zum Projektstart, oder bevor ein Feature mit Login, Rollen, Zahlungen, Uploads, externen Schnittstellen oder personenbezogenen/Gesundheitsdaten gebaut wird. Ergebnis: Risikotabelle mit Maßnahme und Beleg pro Risiko, als docs/THREATMODEL.md im Repo. |
threat-model-light
Ablauf
- System skizzieren (aus Code und Compose, nicht raten): Komponenten, Ports, Proxy
(Caddy/Authelia?), Datenbank, externe Dienste, wer sich wie anmeldet. Eine Zeile pro
Datenfluss:
Browser → Caddy → App:3141 → SQLite. - Assets: Was ist schützenswert? (Personendaten, Arbeitszeiten, Abwesenheiten, Zugangsdaten, Kundendaten, Verfügbarkeit). Gesundheitsdaten (z. B. „krank“) und Daten Dritter markieren.
- Angreifer: anonym aus dem Internet, eingeloggter Nutzer mit niedriger Rolle, Kollege mit gleicher Rolle (IDOR!), jemand im LAN am Proxy vorbei, kompromittiertes Paket, KI-Agent mit Schreibrechten.
- Vertrauensgrenzen markieren: wo wird Identität festgestellt, wo geprüft, wo nur vertraut? Typische Lücke: App vertraut einem Header, den nur der Proxy setzen sollte, Port ist aber direkt erreichbar.
- Risiken je Grenze und Asset. Für jedes Risiko eine konkrete Maßnahme und einen prüfbaren Beleg (Test, Scan, Konfiguration). Risiko ohne Beleg = offen.
- Datensparsamkeit: Für jedes sensible Feld fragen: brauchen wir es? Neutrale Alternative (z. B. „abwesend“ statt „krank“) spart Datenschutzaufwand.
Ausgabe: docs/THREATMODEL.md
# Threat-Model <App> (Stand <Datum>)
## System
<Datenflüsse, eine Zeile je Fluss>
## Assets
| Asset | Schutzbedarf | Bemerkung |
## Risiken
| # | Risiko | Angreifer | Wirkung | Prio | Maßnahme | Beleg | Status |
| 1 | Identitäts-Header fälschbar | LAN | Vollzugriff | K | Shared Secret + Port nur intern | Spoofing-Test, compose ports | offen |
## Offene Entscheidungen
<fachliche Fragen an den User, z. B. Rollenmatrix, Speicherung Abwesenheitsgrund>
Prioritäten wie ASVS-light: K / H / M. Offene K-Risiken blockieren den Release (pre-release-gate).
Danach: Risiken mit Status „offen“ als Tests umsetzen (authz-idor-audit, test-baseline-setup).