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>
47 lines
2.5 KiB
Markdown
47 lines
2.5 KiB
Markdown
---
|
|
name: threat-model-light
|
|
description: >
|
|
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
|
|
1. **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`.
|
|
2. **Assets:** Was ist schützenswert? (Personendaten, Arbeitszeiten, Abwesenheiten, Zugangsdaten,
|
|
Kundendaten, Verfügbarkeit). Gesundheitsdaten (z. B. „krank“) und Daten Dritter markieren.
|
|
3. **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.
|
|
4. **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.
|
|
5. **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.
|
|
6. **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`).
|