add-on: Security baseline checklist

[Fluory]

Checklist from the control center (Entwicklungsplan/templates/addons/security.md, fluory-system 2.1), activated in project-profile.yml. Tick items as they are implemented; each item is proven in the PR that implements it. The checklist text is copied verbatim (German).

---

Add-on: Security (ab P1; Basis-Teile sofort bei jedem Projekt)

Prinzip: Sicherheit wird beim Entwurf der betroffenen Komponente eingebaut, nicht nach
der ersten produktiven Nutzung. Kein Schutz „auf Vorrat" für Komponenten, die es nicht gibt.
Tiefe bei Bedarf: Referenz research/security-architektur.md
(Matrix pro Architekturteil, Rate-Limit-Ebenen, Netzwerktopologie, Quellen).

Sofort – bei jedem Projekt, auch P0 (deckt den Großteil des realen Risikos)

• MFA auf GitHub, Cloud, DNS-Registrar und E-Mail-Konto
• Entwicklungsrechner: Festplattenverschlüsselung, Passwort-Manager, Bildschirmsperre; bei Geräteverlust: alle Tokens/Sessions widerrufen (Ablauf einmal notieren)
• Keine Secrets in Git, Chats, PRs, Logs oder Prompts; .env in .gitignore
• Secret Scanning + Push Protection, Dependabot Alerts + Security Updates
• main nur per PR; klarer Owner für Domain, Cloud-Account, Repo

Secrets als Prozess (ab externer API/Cloud, wichtig bei mehreren Accounts)

• .env.example enthält nur Variablennamen, nie Werte; lokale .env in .gitignore
• Dev-Secrets im Passwortmanager/Team-Vault; P1/P2-Laufzeit-Secrets im Cloud-Secret-Manager
  oder geschützten GitHub Environments (dev/staging/production getrennt)
• CI bekommt nur die Secrets des konkreten Jobs; Prod-Environment mit Freigabe-Schutzregel
• Bei Leak oder Accountverlust: sofort rotieren
• docs/technical/local-setup.md erklärt, wie ein berechtigter neuer Account Dev-Secrets erhält

Sobald die Domain E-Mails versendet (Transaktionsmails, Passwort-Reset)

• SPF, DKIM und DMARC einrichten – sonst kann jeder in eurem Namen mailen

Sobald etwas öffentlich erreichbar ist

• Nur HTTPS/TLS; DNS-Zugriff eng beschränkt (MFA, minimale Rechte)
• Auth wo Daten/Funktionen geschützt sind; Autorisierung serverseitig, nie nur UI-Verstecken; Account-Recovery-Flow bewusst designen (oft die schwächste Stelle)
• Rate Limits mindestens für Login, Reset, Registrierung und teure Endpunkte; Timeouts + Payload-Limits; CORS bewusst konfigurieren
• Fehler ohne interne Stacktraces; strukturierte Logs + Health Check
• Werte konservativ starten, echte Nutzung messen, dann anpassen

Agenten-Berechtigungen (SYSTEM.md §10)

• .claude/settings.json aus templates/base/ eingezogen: Read-Sperren für Secrets (permissions.deny), Artefakt-Sperre per Hook (guard-read.sh, Ausnahme nur FLUORY_ALLOW_ARTIFACTS=1), autoMemoryEnabled: false
• Sandbox ab P1 risikobasiert (macOS, Linux, WSL2): einschalten, wenn der Agent externe Befehle ausführt, Daten oder Credentials verarbeitet, Infra-/Deploy-Code im Worktree liegt, unbekannte Dependencies oder Generatoren laufen oder parallele Agenten Isolation brauchen – Entscheidung im Profil (agent.sandbox). Snippet für .claude/settings.json:
  { "sandbox": { "enabled": true, "filesystem": { "denyRead": ["~/.ssh", "~/.aws"] }, "network": { "allowedDomains": ["github.com", "registry.npmjs.org"] } } } –
  Credential-Schutz (sandbox.credentials) wirkt nur aus User- oder Managed-Settings, nicht aus Projektdateien

Prozess statt Ampel

• CVE-Triage: Wer sichtet Findings, Patch-Frist je Schwere (Richtwert: kritisch 48 h, hoch 1 Woche); Lockfiles/Version-Pinning
• Ausnahmen-Register (Abschnitt in der Architekturkarte): bewusst akzeptierte Risiken mit Owner und Ablaufdatum – sonst werden Ausnahmen stillschweigend permanent
• Drift-Prüfung: quartalsweise prüfen (Termin/Issue), ob die Behauptungen im project-profile.yml und der Sicherheitstabelle noch stimmen
• SAST/Code Scanning (CodeQL) als PR-Job mit timeout-minutes

Sicherheitsvertrag pro Komponente (ab P1)

Die Modultabelle in der Architekturkarte bekommt Sicherheits-Spalten – eine Zeile pro Komponente,
keine eigene Sicherheits-Doku pro Datei:

Komponente	Exposition	Datenklasse	Schutz	Prüfung
API	öffentlich	fachliche Daten	Auth, Rollen, Rate Limit	Integrationstest
DB	privat	vertraulich	privates Netz, Backup	Restore-Test

Vor P2 / Produktion (eigener Security-PR)

• Private Netzwerktopologie: nur DNS/CDN/Load Balancer öffentlich; App, DB, Cache, Queue, Admin privat; Firewall nur nötiger Verkehr; Admin-Zugang via Identität + MFA, nie offene Adminports
• WAF/DDoS-Schutz des Providers aktiv; Threat Model für kritische Datenflüsse
• Rechte-/Admin-Review; Offboarding-Ablauf (Zugänge, Tokens, geteilte Secrets) definiert
• Backup-Restore getestet, Rollback geprobt, Monitoring/Alerts aktiv, Lasttest kritischer Endpunkte
• Externe Prüfung: mindestens ein fokussierter Pentest oder externes Review – eigene Checklisten finden die eigenen blinden Flecken nicht
• CODEOWNERS für kritische Pfade (nur real existierende Accounts/Teams)

Projektende (Dekommissionierung)

• Daten gemäß Löschkonzept löschen, Backups vernichten, Secrets/Tokens widerrufen, Domain/DNS abbauen oder übertragen, Repo archivieren, PROJEKTE.md aktualisieren