<img src="banner.png" width="100%" alt="sec-fix banner">

sec-fix - minimaler Sicherheitspatch

Phase "fix" der ellmos-Security-Familie. Vertrag: sec-scan/references/contract.md (Verzeichnis §1, Lebenszyklus §2, Regeln §6). Hier nur die Anwendung.

Wann (und wann nicht)

• Nur auf ausdrücklichen Wunsch. Ein Scan oder eine Validierung löst nie automatisch einen Fix aus.
• Nur Funde mit Status validated oder triaged. candidate zuerst durch sec-validate; rejected bleibt liegen.
• Normaler Bug ohne Sicherheitsbezug: bugfix-protocol. Ob ein vorhandener Patch taugt: sec-verify-fix. Strukturelle Ursache hinter mehreren Funden: sec-hardening.

Ablauf

1. Fund und Umfang lesen: findings.json (Fund, evidence, recommendation), betroffene Datei und die Aufrufer der Stelle. Die Ursache beheben, nicht das Symptom an einer Aufrufstelle; gibt es mehrere Aufrufer derselben unsicheren Funktion, den gemeinsamen Punkt patchen.
2. Lock prüfen (Vertrag §6 Regel 2): lock_scan.py --check-dir <repo> --json; Exit 0 = frei, 1 = gesperrt, alles andere = unbekannt = stoppen; ohne lock_scan.py auf dem Host stattdessen LOCK*.txt im Repo und in den Elternordnern suchen (keine = frei, sonst stoppen). LOCK.user.* nie anfassen.
3. Arbeitskopie: Scratch-Kopie oder git worktree in einem Ordner außerhalb des Originals. Im Original wird nichts geschrieben.
4. Basis messen: Tests des Projekts einmal vor dem Patch laufen lassen und das Ergebnis festhalten (grün/rot, Anzahl). Gibt es keine Tests: sagen, nicht erfinden.
5. Minimal patchen: kleinste Änderung, die den Source-to-Sink-Pfad schließt (Validierung, Parametrisierung, Allowlist, Escaping an der richtigen Stelle). Kein Refactoring, keine Stilkorrekturen, keine neuen Abhängigkeiten ohne Not. Ein Regressionstest für den Fund gehört in den Patch, wenn das Projekt Tests hat.
6. Nachmessen: Tests erneut laufen lassen; Vorher/Nachher ehrlich berichten, auch rote Tests und Tests, die nicht liefen.
7. Patch ablegen: git diff der Arbeitskopie nach patches/<id>.diff im Scan-Verzeichnis; mit git apply --check gegen den Zielstand prüfen (verändert nichts).
8. Finding aktualisieren: status: fixed, fix.patchFile: patches/<id>.diff; dann python scripts/secfind.py validate findings.json coverage.json (Skript liegt in sec-scan).

Grenzen

• Kein Anwenden, kein Commit, kein Push (Regel 3). Das braucht einen direkten Nutzerauftrag.
• Geheimnis-Funde: Der alte Wert steht zwangsläufig in den --Zeilen des Diffs. Patch nur lokal im Scan-Verzeichnis, nie in Ticket, Chat oder Bericht; das Geheimnis zuerst beim Anbieter rotieren (Regel 4). Offen: ob ein maskierter Diff sinnvoll anwendbar wäre - nicht erfinden.
• Der Autor des Patches prüft ihn nicht selbst: sec-verify-fix mit anderem Prüfer (Regel 7).
• Kostenwarnung bei Fixes für viele Funde auf einmal (Regel 5); seriell abarbeiten.

Changelog

0.1.0 (2026-10-31)

• Erstfassung.