robcsaszar/sentinel

Sicherheitsaudit-Skill

Führen Sie ein strenges statisches Sicherheitsaudit einer Webanwendungs-Codebasis durch. Erstellt eine Zusammenfassungstabelle (PASS / FAIL / MANUAL-REVIEW) und pro Befund Blöcke mit Datei:Zeilen-Nachweis, Risikobeschreibung und Korrekturcode.

---

Phase 1 – Stack-Triage

Bevor Sie Code scannen, beantworten Sie diese Fragen durch Lesen von package.json, Konfigurationsdateien und README:

1. Framework: SvelteKit / Next.js / Express / FastAPI / etc.
2. Datenbanktreiber: parametrisiert (libsql, pg, prisma) vs. roher String (low-level-Treiber)
3. Authentifizierungsmechanismus: JWT / HMAC-Token / Sessions / OAuth
4. Deployment-Ziel: Fly.io / Cloudflare / Vercel / bare Node – bestimmt, welchem IP-Header für Rate-Limiting und Audit-Logs vertraut werden soll (Fly-Client-IP vs CF-Connecting-IP vs X-Forwarded-For); dem falschen zu vertrauen erlaubt einem Angreifer, seine Quell-IP zu spoofen
5. Datei-Uploads: ja/nein – falls ja, wo gespeichert (lokales Dateisystem, S3-kompatibel, CDN)
6. Externe ausgehende Aufrufe: E-Mail-API, Webhooks, Medienabruf – potenzielle SSRF-Angriffsflächen

Geben Sie Ihre Stack-Zusammenfassung in einem Absatz vor Phase 2 an. Falsche Annahmen hier führen zu falschen Ergebnissen.

---

Phase 2 – Scan

VERPFLICHTENDE LEKTÜRE: references/security-checklist.md

Laden Sie references/security-checklist.md NICHT für gezielte Einzelendpunkt-Überprüfungen – dies würde den Umfang über die Aufgabe hinaus erweitern. Laden Sie sie nur für vollständige Codebasis-Audits.

Arbeiten Sie jede Kategorie in der Checkliste der Reihe nach durch – das Überspringen einer Gruppe erfordert einen schriftlichen Grund im Bericht.

Für jede Kategorie:

• Lesen Sie die relevanten Quelldatei(en). Markieren Sie PASS nicht aus dem Gedächtnis.
• Wenn die Datei nicht existiert, markieren Sie MANUAL-REVIEW mit einem Hinweis.
• Notieren Sie das Urteil (PASS / FAIL / MANUAL-REVIEW) und einen einzeiligen Nachweis.

Wenn das Repository zu groß ist, um jede Datei zu lesen, priorisieren Sie nach Risiko: Authentifizierungsabläufe und Token-Handling zuerst, dann Eingabe-/Ausgabegrenzen, dann Abhängigkeitskonfiguration. Notieren Sie, welche Dateien übersprungen wurden.

---

Phase 3 – Klassifizieren

Überprüfen Sie Ihre rohen Scan-Notizen. Wenden Sie für jedes Element die Urteilsregeln an:

• PASS – Sie haben den relevanten Code gelesen und bestätigt, dass die Kontrolle vorhanden ist. Zitieren Sie Datei:Zeile.
• FAIL – Sie haben eine bestätigte, ausnutzbare Lücke gefunden. Sie haben einen Code-Ausschnitt. Sie können einen Fix schreiben.
• MANUAL-REVIEW – Das Urteil erfordert Laufzeitkontext, Infrastrukturzugriff oder menschliches Urteilsvermögen (z. B. „überprüfen, ob dieses Token schreibgeschützten Zugriff auf das Turso-Dashboard hat“).

Bevor Sie ein Urteil fällen, fragen Sie: „Kann ich den Korrekturcode jetzt schreiben, nur mit dem, was ich gelesen habe?“ Ja → FAIL. Nein → MANUAL-REVIEW.

Stufen Sie ein FAIL nicht zu MANUAL-REVIEW herab, um den Bericht abzumildern.

---

Phase 4 – Bericht

Zuerst die Zusammenfassungstabelle:

#	Kategorie	Status	Anmerkungen
1	SQL-Injection	PASS	Durchgehend parametrisiert
2	XSS	FAIL	{@html} auf benutzergesteuertem Feld – siehe Befund
…	…	…	…

Dann für jeden FAIL und MANUAL-REVIEW ein Befundblock:

### [N]. KATEGORIE — FAIL
**Datei:** `src/lib/example.ts:42`
**Ausschnitt:**
  cookies.set(name, token, { httpOnly: true })   // ← fehlendes Secure-Flag
**Risiko:** Cookie wird in Nicht-Produktion über unverschlüsseltes HTTP übertragen; durch passiven MITM abgefangen.
**Fix:**
  cookies.set(name, token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
  });

MANUAL-REVIEW-Blöcke verwenden das gleiche Format, ersetzen jedoch Fix durch Aktion, die beschreibt, was der Mensch überprüfen muss und wo.

PASS-Elemente erscheinen nur in der Zusammenfassungstabelle – keine Blöcke.

---

NIE

• NIE PASS markieren, ohne die Datei gelesen zu haben Stattdessen: Lesen Sie die Datei, zitieren Sie Datei:Zeile im Nachweis. Warum: Gedächtnisbasierte PASS-Urteile erzeugen falsche Sicherheit – der ganze Sinn des Audits ist der Nachweis.

• NIE FAIL markieren ohne Code-Ausschnitt Stattdessen: Zitieren Sie die genaue verwundbare(n) Zeile(n). Wenn Sie keinen Ausschnitt finden, ist es MANUAL-REVIEW. Warum: Ein FAIL ohne Nachweis ist Rauschen; Entwickler brauchen die genaue Stelle, um es zu beheben.

• NIE FAIL und MANUAL-REVIEW vermischen Stattdessen: FAIL = Sie können den Fix jetzt schreiben. MANUAL-REVIEW = können Sie nicht, und Sie sagen warum. Warum: Die Vermischung zerstört die Handlungsorientierung des Berichts.

• NIE Phase 1 Stack-Triage überspringen Stattdessen: Lesen Sie package.json und eine Konfigurationsdatei, bevor Sie etwas scannen. Warum: Welchem IP-Header vertraut werden, welcher CSP-Ansatz gültig ist und welches Authentifizierungsmodell gilt, hängt vom Stack ab – falsche Annahmen führen zu falschen Urteilen.

• NIE Korrekturcode melden, der nicht zum Framework/Bibliothek des Projekts passt Stattdessen: Schreiben Sie Fixes mit den exakt bereits verwendeten APIs (z. B. SvelteKit cookies.set, nicht res.setHeader). Warum: Generische Korrekturen, die nicht kompilieren, werden ignoriert; frameworkspezifische Fixes werden übernommen.

• NIE einen Befundblock für eine Kategorie schreiben, für die Sie die Quelldatei nicht gelesen haben Stattdessen: Öffnen Sie die Datei, lesen Sie sie, schreiben Sie dann den Block. Warum: Ein Befundblock ohne Dateinachweis ist Behauptung, kein Audit – er untergräbt das Vertrauen in den gesamten Bericht, wenn er sich als falsch erweist.

• NIE stillschweigend Dateien in einem großen Repository überspringen Stattdessen: Priorisieren Sie nach Risiko (Auth/Token-Handling → Ein-/Ausgabegrenzen → Abhängigkeitskonfiguration) und listen Sie jede übersprungene Datei explizit im Bericht auf. Warum: Stillschweigende Auslassungen machen die Abdeckungsaussage des Audits nicht überprüfbar – ein sauberer Bericht über einen unvollständigen Scan wirkt wie eine falsche Entwarnung.