Alan-Lucena/claude-skills

Remediar hallazgos de seguridad (Sicherheitslücken beheben)

Deine Aufgabe ist es nicht, „alles auf einmal zu reparieren". Es geht darum, in der richtigen Reihenfolge zu beheben, jede Korrektur zu überprüfen und nichts zu beschädigen, was bereits funktioniert. Der Benutzer ist oft ein Vibecoder: Geh nicht davon aus, dass er den Explosionsradius (Blast Radius) versteht – erkläre ihn.

Goldene Regel

Lösche, undeploye oder deaktiviere NIE etwas in der Produktion, ohne vorher zu antworten: „Was verwendet es heute?“ (Frontend, Jobs, andere Endpunkte, das Dashboard). Erst prüfen, dann löschen. Wenn etwas Legitimes es verwendet, anhalten und den Benutzer informieren, nicht fortfahren.

Wie man an jedem Gate fragt

An jedem Punkt, an dem der Fluss zur Bestätigung anhält (vorgeschlagene Reihenfolge, Authentifizierungsplan, vor dem Anwenden von etwas Irreversiblem), verwende das Tool AskUserQuestion, anstatt in Freitext zu fragen. Der Benutzer ist ein Vibecoder und zieht es vor, eine Option auszuwählen, anstatt die Antwort zu formulieren.

Muster für jedes Gate:

• Kurzer Header (z. B. „Kritisch – Stufe 1“, „Auth-Plan“, „Diffs anwenden“).
• Typische Optionen: „Genehmigen und starten“ (empfohlen, zuerst), „Vorher anpassen“, „Zuerst prüfen/mehr erklären“.
• Eine Frage pro tatsächlicher Entscheidung. Fasse nicht Dinge, die der Benutzer separat genehmigen möchte (z. B. Stufe 1 starten und Stufe-2-Plan genehmigen sind ZWEI verschiedene Fragen), in einer einzigen Frage zusammen.
• Wenn die Entscheidung von etwas abhängt, das der Benutzer noch nicht gesehen hat (z. B. der Diff wurde noch nicht angezeigt), zeige zuerst diesen Inhalt an und frage dann.

Ablauf

1. Triage (Ersteinschätzung)

Ordne die Funde nach Schweregrad und Irreversibilität, nicht nur nach Schweregrad. Ein „hoher“ Fund, der einen Produktionsworkflow unterbricht, ist heikler als ein isolierter „kritischer“ Fund. Klassifiziere jeden Fund in:

• Isoliert + reversibel → kann direkt repariert werden.
• Betrifft Authentifizierung / ändert öffentlichen Vertrag → erfordert einen Plan vor dem Code.
• Löscht oder undeployed Infrastruktur in der Produktion → erfordert Bestätigung „Was verwendet es heute?“ + Backup + Rollback-Plan, BEVOR etwas angefasst wird.

Präsentiere die vorgeschlagene Reihenfolge und halte an. Fahre nicht mit der Korrektur fort, ohne dass der Benutzer bestätigt.

2. Kritisch / irreversibel zuerst, einzeln

• Bevor du löschst/undeployest: Liste auf, was es heute aufruft. Wenn es wirklich verwaist ist, hinterlege ein Backup (Export der betroffenen Tabellen) und einen Rollback-Plan.
• Wende NUR eine einzige Änderung an. Mische sie nicht mit anderen Funden.
• Überprüfe (Schritt 4), bevor du fortfährst.

3. Korrekturen der Authentifizierung / des öffentlichen Vertrags

• Zuerst den Plan in Textform: Welche Validierung fügst du hinzu, welche legitimen Clients rufen heute auf, wie vermeidest du, sie zu beschädigen? Warte auf Genehmigung.
• Erst dann schreibe Code.

4. Überprüfung (obligatorisch für jede Korrektur)

Führe denselben Angriff/Nachweis (PoC) erneut aus, der die Sicherheitslücke gefunden hat, und zeige „vorher anfällig / jetzt abgewiesen“. Ohne Reproduktion gilt die Korrektur NICHT als abgeschlossen. Das Wort „ist bereits repariert“ reicht nicht.

5. Regression

Bestätige, dass die legitimen Abläufe weiterhin funktionieren (z. B. wenn du einem Endpunkt Authentifizierung hinzugefügt hast, stelle sicher, dass der offizielle Client weiterhin funktioniert). Nenne, was du getestet hast.

6. Guardrail (Schutzmassnahme)

Füge für jede bestätigte Sicherheitslücke einen Test hinzu, der den Exploit reproduziert und fehlschlägt, wenn er wieder auftritt. Wenn es nicht testbar ist, hinterlasse eine Notiz, warum.

7. Quick Wins (Schnelle Erfolge) in einem Batch

Niedrigrisiko-Funde (Header, Eingabevalidierungen, Query-Fixes) können in einem Commit gruppiert werden, aber liste jeden mit seinem Diff auf, bevor du ihn anwendest.

8. Abschluss

Abschließende Zusammenfassung: was repariert und verifiziert wurde, was noch aussteht und warum (z. B. Multisig vor dem Mainnet), und welche Änderungen ein manuelles Deployment durch den Benutzer erfordern.

Selbstüberprüfungen (überspringe sie nicht, warte nicht, bis der Benutzer sie anfordert)

Der Benutzer ist ein Vibecoder und kann eine Korrektur genehmigen, ohne zu bemerken, dass sie nur dekorativ ist. Bevor du einen Fund als abgeschlossen erklärst, führe diese Überprüfungen selbst durch, und wenn eine zutrifft, sage es, auch wenn niemand danach gefragt hat.

• Authentifizierung = Identität, nicht Anwesenheit. Ein Gate, das nur prüft, ob ein Token ANKOMMT, schließt keine IDOR (Insecure Direct Object Reference). Bestätige, dass der Token/die Sitzung an die Identität (Wallet, user_id) gebunden ist und dass du diese Identität mit der angeforderten Ressource vergleichst. Wenn die „Zugehörigkeitsprüfung“ (403) nicht auf einem echten Binding basiert, ist die Korrektur falsch.
• main = Produktion. Wenn du die Korrekturen von einem nicht zusammengeführten Branch aus deployed hast, läuft in der Produktion Code, der nicht in main ist: Das nächste Deployment von main MACH DIE KORREKTUREN RÜCKÄNGIG. Weise darauf hin, dass ein Merge erforderlich ist, und kennzeichne dies als Sicherheitsrisiko, nicht als Ordnungsliebe.
• Der Auditor kann sich irren. Bevor du eine Korrektur anwendest, überprüfe die Annahme des Fundes im tatsächlichen Code (z. B. „Der Client sendet einen Token“ kann falsch sein). Eine Korrektur basierend auf einer falschen Annahme legt die Produktion lahm.
• Akzeptiertes Risiko wird dokumentiert, nicht totgeschwiegen. Wenn etwas nicht repariert wird (statischer Token, zurückgesetzte Rotation, weil sie einen Workflow beschädigt hat), schreibe es als akzeptiertes Risiko auf, nicht als „abgeschlossen".
• Validierung an einem Endpunkt, nicht an allen. Wenn ein Feld in PATCH, aber nicht in POST validiert wird (oder umgekehrt), bleibt das Loch bestehen. Überprüfe alle Eingabepfade desselben Datums.
• Löschen hinterlässt Spuren. Nach dem Undeployen/Löschen, prüfe die Tabelle oder Ressource auf Daten, die der Exploit hinterlassen hat; geh nicht davon aus, dass das Rückgängigmachen des Endpunkts den bereits angerichteten Schaden bereinigt.

Ausgabestil

• Zeige den Diff, bevor du irreversible Änderungen oder Deployment-Änderungen vornimmst.
• Erkläre einen Fund nicht als „gelöst", ohne die Reproduktion aus Schritt 4.
• Wenn sich ein Fund bei der Untersuchung als Fehlalarm (False Positive) herausstellt, sag es und „repariere" ihn nicht.