Deploy-Security-Gate

Deploy Security Gate

Dieses Skill setzt eine einzige Checkliste durch: Kein Schlüssel wird jemals exponiert, und kein einzelner Fehler bringt das Produkt zu Fall. Es läuft in drei Durchläufen:

1. Ein automatisierter Scan mit scripts/scan.py, der schnell, deterministisch und schreibgeschützt ist.
2. Eine Code-Review jeder erkannten Integration, angeleitet durch references/integrations.md.
3. Ein manuelles Gate für alles, was nicht im Repository sichtbar ist, wie Provider-Dashboards, Rotationen, Backups und Übungen. Diese Punkte stammen aus references/checklist.md.

Der Scan allein ist kein Bestehen. Er deckt grob ein Drittel der Checkliste ab. Der Wert dieses Skills liegt darin, alle drei Durchläufe zu absolvieren und ehrlich zu sein, was überprüft wurde und was noch von einem Menschen bestätigt werden muss.

Arbeitsablauf

1. Umfang

Ermitteln, was ausgeliefert wird:

• das Repository-Root
• Frontend- oder Mobile-Build-Ausgabe, falls vorhanden
• das Bereitstellungsziel, z. B. Container, Serverless oder Kubernetes
• ob es sich um einen ersten Launch, eine neue Integration oder eine Routinewartung handelt

Wenn der Benutzer eine bestimmte Änderung genannt hat, z. B. „Stripe hinzufügen“, konzentrieren Sie die Überprüfung darauf. Führen Sie trotzdem den vollständigen Scan durch, denn ein Leck an anderer Stelle blockiert die Veröffentlichung genauso.

2. Den Scanner ausführen

python3 <skill-dir>/scripts/scan.py <repo> --history

• --build-dir <dir> für jedes gebaute Bundle hinzufügen (dist, .next/static, eine entpackte APK/IPA). Ausgelieferte Bundles sind der Ort, an dem sich „öffentliche“ Schlüssel als geheim herausstellen. Häufige Build-Verzeichnisse werden automatisch erkannt; bauen Sie die App zuerst, wenn keine existieren.
• --entropy fügt einen Durchlauf mit hoher Entropie hinzu, der benutzerdefinierte Geheimnisse erfasst, die kein benanntes Muster kennt (geringe Schwere; jedes vor der Meldung verifizieren).
• --format json oder --format sarif geben maschinenlesbare Ausgabe; SARIF lädt in GitHub Code Scanning hoch. --fail-on high|medium|low|never steuert den Exit-Code, was in CI nützlich ist.
• Bestätigte Fehlalarme können mit einem Inline-Kommentar # security-gate: allow oder einer .security-gate-ignore-Datei im Repository-Root unterdrückt werden (siehe README). Bevorzugen Sie die Unterdrückung bestimmter Funde gegenüber der Herabsetzung von --fail-on.
• Der Scanner maskiert geheime Werte. Behalten Sie dies bei, was immer Sie schreiben: Geben Sie niemals einen vollständigen Schlüssel in Chat, Dateien, Commits oder PR-Text aus, da dies ein zweites Leck erzeugt.

Der Scanner prüft:

• Geheimnis-Muster (AWS, Anthropic, OpenAI, OpenRouter, Groq, xAI, Perplexity, Replicate, fal, Google API-Keys und OAuth-Secrets, Stripe Live-Keys und Webhook-Secrets, Razorpay, GitHub, GitLab, Slack-Tokens und App-Tokens, GCP-Service-Accounts, npm, PyPI, SendGrid, Hugging Face, DigitalOcean, New Relic, Shopify, Square, Databricks, Doppler, PlanetScale, Linear, Azure Storage-Keys, Mailgun, Telegram, Discord-Webhooks, JWTs, Private Keys, DB-URLs mit Passwörtern, hartcodierte *_SECRET / *_TOKEN / *_SERVICE_ROLE-Zuweisungen — zitiert (einschließlich JSON/MCP-Konfigurationen) oder unzitiert) im Arbeitsbaum, Build-Ausgabe und Git-Historie
• mit --entropy, Zeichenfolgen mit hoher Entropie, die keinem bekannten Format entsprechen (benutzerdefinierte oder neuartige Geheimnisse)
• commitierte .env-Dateien und ein fehlender .gitignore-Eintrag
• geheim aussehende Variablen hinter client-seitigen Präfixen (NEXT_PUBLIC_, VITE_, REACT_APP_, EXPO_PUBLIC_ und ähnliche) sowie direkte LLM-Aufrufe aus Client-Code
• Source Maps im Build-Ausgabe
• GitHub Actions Workflows: Tag-verankerte Aktionen, pull_request_target, fehlender permissions:-Block, ausgegebene Geheimnisse, in Dateien geschriebene Geheimnisse oder $GITHUB_ENV / $GITHUB_OUTPUT, statische Cloud-Schlüssel anstelle von OIDC und Installationen mit Lifecycle-Skripten
• Dockerfiles: Geheimnisse in ARG/ENV, kopierte .env-Dateien und Ausführung als root
• Zahlungs-Webhook-Handler ohne Signaturverifikation
• Lesezugriff von Coding-Agents auf .env-Dateien
• die verwendeten Integrationen sowie Hinweise auf Single-Provider (Single Point of Failure) für KI und Zahlungen

3. Die Funde triagieren

Der Scanner arbeitet mit Mustervergleich, daher bestätigen Sie jeden Fund durch Lesen des Codes, bevor Sie ihn melden.

• Live-Geheimnis gefunden (im Baum, in der Historie oder in einem Bundle): Behandeln Sie es als durchgesickert, selbst wenn das Repository privat ist. Befolgen Sie references/leaked-key-runbook.md, wo das Widerrufen an erster Stelle kommt und die Bereinigung später erfolgt. Das Widerrufen oder Rotieren eines Schlüssels ändert die Produktion, daher sagen Sie dem Benutzer genau, welcher Schlüssel, wo er gefunden wurde und welchen Widerrufsschritt es gibt. Lassen Sie ihn es tun, oder bestätigen Sie es, bevor Sie selbst etwas unternehmen.
• Fehlalarm (eine Test-Fixtur, ein dokumentierter öffentlicher Schlüssel): Sagen Sie, warum es sicher ist, und fahren Sie fort.
• Heuristische Funde (Webhook-Verifikation, Client-seitiger LLM-Aufruf): Öffnen Sie die Datei und überprüfen Sie den tatsächlichen Kontrollfluss. Die Verifikation könnte sich in Middleware an anderer Stelle befinden.

4. Jede erkannte Integration überprüfen

Für jede Integration, die der Scanner aufgelistet hat oder die Sie im Code finden, lesen Sie den entsprechenden Abschnitt von references/integrations.md und prüfen Sie den Code dagegen. Dieser Schritt erfasst, was Muster nicht können, z. B.:

• ein Backend-Proxy, der ein offenes Relay ist
• ein Modellname, der aus dem Anforderungskörper stammt
• Beträge, die auf dem Client berechnet werden
• Tool-Aufrufe, die mit Administrator-Anmeldeinformationen ausgeführt werden
• PII, die an Analysetools gesendet wird
• RAG-Abfragen ohne Tenant-Filter
• indirekte Prompt-Injection: Dokumente, Webseiten, Transkripte oder Tool-Ergebnisse, die das Modell liest, werden als Anweisungen behandelt (Checkliste 3.17)
• Datei-Uploads, die ohne Typ-/Größen-/Archiv-Prüfung oder Sandbox geparst werden (3.18)
• SSRF: eine *_url, die das Modell oder ein Tool abruft, ohne Blockierung privater oder Metadaten-Adressen (3.19)

Die Webhook-, Client-LLM- und Geheimnis-Prüfungen sind heuristisch: Der Scanner markiert Kandidaten, kann aber eine manuell geschriebene Steuerung oder ein nicht standardmäßiges Layout übersehen. Bestätigen Sie immer durch Lesen des Codes – ein Webhook, der mit createHmac + timingSafeEqual verifiziert wird, oder ein Backend, das zufällig unter src/ liegt, ist in Ordnung, selbst wenn ein Tool es markiert oder übersieht.

5. Auf Single Points of Failure prüfen

Verwenden Sie Checklistenabschnitt 10 und suchen Sie im Code und IaC nach:

• einem LLM-Provider ohne Fallback
• HTTP-Clients zu Anbietern ohne Timeout oder Wiederholung
• Anbieteraufrufen im Anforderungspfad, die blockieren, wenn die Analyseplattform ausfällt
• einer Single-Region oder Single-Zone Datenbank
• einem Secrets-Abruf ohne Cache
• einer Person, die allein Root- oder Inhaberzugriff hat, basierend auf dem, was der Benutzer Ihnen sagt

6. Manuelles Gate

Viele Checklistenpunkte können nicht aus einem Repository überprüft werden, z. B.:

• Ausgabenlimits in Provider-Dashboards
• Rotationspläne
• SSO und MFA auf Anbieterkonten
• Backup-Wiederherstellungstests
• Failover-Übungen
• DPAs
• PCI-Skriptinventar auf Zahlungsseiten

Listen Sie diese als Bestätigung erforderlich, jeweils mit einer einzeiligen Frage an den Eigentümer. Markieren Sie sie niemals als bestanden, basierend auf Annahmen. Ein Gate, das ungeprüfte Elemente stillschweigend passieren lässt, ist schlimmer als kein Gate.

7. Bericht

Verwenden Sie diese Struktur, damit Ergebnisse über Releases hinweg vergleichbar sind:

# Security Gate: <Produkt / Änderung> — <GO | NO-GO | GO WITH EXCEPTIONS>

## Blocker (müssen vor dem Deploy behoben werden)
- [Prüf-ID] Datei:Zeile — was ist falsch — die Behebung

## Sollte behoben werden (dieser Sprint)
- ...

## Überprüfte Integrationen
| Integration | Nur serverseitig | Eingeschränkter Schlüssel + Ausgabenlimit | Webhooks/Ausgaben verifiziert | Fallback | Anmerkungen |

## Bestätigung erforderlich (manuell)
- [ ] <Frage an den Eigentümer> (Checkliste §n)

## Bestanden (verifiziert)
- <Punkt> — wie verifiziert

Urteilsregel:

• NO-GO: Jeder bestätigte HIGH-Fund, der ein Live-Geheimnis, einen client-seitig exponierten geheimen Schlüssel, einen unverifizierten Zahlungs-Webhook oder ein Geheimnis in CI-Protokollen umfasst.
• GO WITH EXCEPTIONS: Es verbleiben nur mittlere oder niedrige Funde, und der Benutzer akzeptiert sie mit einem Eigentümer und einem Datum.
• GO: Nichts offen, und jeder manuelle Punkt wurde bestätigt.

Beheben von Problemen

Wenn der Benutzer Sie bittet, Funde zu beheben, bevorzugen Sie diese Abhilfen, die die Ursache und nicht das Symptom angehen:

• Schlüssel im Code: Ersetzen Sie ihn durch eine Laufzeitsuche, entweder aus der Umgebung, die vom Secrets-Manager injiziert wird, oder über das SDK des Providers. Fügen Sie einen Platzhalter zu .env.example hinzu. Schreiben Sie den echten Wert niemals irgendwohin. Teilen Sie dem Benutzer mit, dass der Schlüssel immer noch widerrufen werden muss, da das Entfernen aus dem Code ihn nicht undicht macht.
• Geheimnis, das den Client erreicht: Verschieben Sie den Aufruf hinter eine Backend-Route oder ein KI-Gateway, das den Benutzer authentifiziert, pro Benutzer und Tenant ratelimitiert, Modelle und Operationen auf eine Whitelist setzt und den Schlüssel hält. Behalten Sie nur veröffentlichbare Schlüssel im Client.
• Unverifizierter Webhook: Verifizieren Sie die Signatur am rohen Körper mit dem Provider-SDK. Lehnen Sie veraltete Zeitstempel ab, deduplizieren Sie nach Ereignis-ID und rufen Sie das Objekt erneut vom Provider ab, bevor Sie den Status ändern.
• CI-Probleme: Verankern Sie Aktionen auf Commit-SHAs (lösen Sie die SHA mit git ls-remote auf, behalten Sie das Tag in einem Kommentar). Fügen Sie permissions: contents: read hinzu. Ersetzen Sie statische Cloud-Schlüssel durch OIDC. Verwenden Sie npm ci --ignore-scripts.
• Docker-Probleme: Verwenden Sie BuildKit RUN --mount=type=secret für Build-Zeit-Geheimnisse und einen Nicht-Root-USER.
• Agentenzugriff: Fügen Sie permissions.deny-Einträge Read(./.env) und Read(./.env.*) zu .claude/settings.json hinzu. Empfehlen Sie Laufzeitinjektion (doppler run, infisical run, op run), sodass überhaupt keine Klartextdatei existiert.

Kontinuierliche Nutzung

Schlagen Sie vor, den Scanner in CI einzubinden, sodass das Gate bei jedem PR und nicht nur beim Start läuft:

- run: python3 tools/deploy-security-gate/scripts/scan.py . --fail-on high

Schlagen Sie auch eine wiederkehrende Überprüfung im Rhythmus von Checklistenabschnitt 12 vor.

Referenzdateien

• references/checklist.md: Die vollständige Checkliste (Abschnitte 1–14), mit jedem Element gekennzeichnet als [auto] (Scanner), [code] (Code-Review) oder [manual] (Eigentümer bestätigt). Lesen Sie sie für die Schritte 5–6 und immer dann, wenn Sie die genaue Kontrolle benötigen.
• references/integrations.md: Wie gut aussehen sollte für KI-Gateways und LLM-Provider, MCP-Server, Zahlungen, Analysetools und Authentifizierung, mit Mustern, nach denen gesucht werden soll. Lesen Sie die Abschnitte für die Integrationen im Umfang.
• references/leaked-key-runbook.md: Die Schritt-für-Schritt-Antwort, wenn ein Live-Schlüssel gefunden wird, mit Widerrufshinweisen pro Provider.