sec-hardening - strukturell statt Stück für Stück

Wiederholen sich Funde derselben Klasse, liegt die Ursache meist in der Struktur (fehlende zentrale Validierung, ungeprüfte Vertrauensgrenze, Geheimnisse im Code). Dieser Skill schlägt Änderungen auf dieser Ebene vor. Vertrag: sec-scan/references/contract.md (Funde §1/§2, Regel 4 Geheimnisse, Regel 5 Kosten).

Eingabe

findings.json (idealerweise validated oder weiter), Vorfallberichte, Assessments, threatmodel.md und das Wissen über den Code. Ohne belegte Eingabe keine Vorschläge; Annahmen als solche kennzeichnen.

Ablauf

Ursachen bündeln: Funde nach Wurzel gruppieren (nicht nach Datei): z. B. "jede Route baut SQL selbst", "Zugriffsprüfung in jedem Handler einzeln", "Konfiguration enthält Geheimnisse". Je Gruppe die Fund-ids nennen.
Ist-Architektur skizzieren als ASCII-Bild: Vertrauensgrenzen, Datenfluss, wo die Prüfung heute (nicht) stattfindet.
Optionen je Ursache (mindestens zwei, inklusive "nur Einzelpatches"): Beschreibung, Aufwand, Risiko der Umsetzung (Regressionen, Migration), Wirkung (welche Fundklasse verschwindet, welche bleibt), Abhängigkeiten. Als Tabelle.
Empfehlung pro Ursache mit Begründung und Soll-Bild (ASCII) im Vergleich zum Ist-Bild.
Reihenfolge: was zuerst, weil es mehrere Funde auf einmal schließt oder Voraussetzung für anderes ist; was kann warten. Zwischenschritte, die einzeln auslieferbar sind.
Evidenz je Vorschlag: Fund-ids, Codestellen (pfad:zeile), Messwerte. Ein Vorschlag ohne Beleg wird als Hypothese markiert. Keine erfundenen Aufwandsangaben in Zeit; nur relativ (klein/mittel/groß) oder vom Nutzer vorgegeben.