---
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`).