🛡️ Database Sentinel

Ein Claude-Skill, der deine Datenbank-Backends auf Sicherheitslücken prüft.

Füge ihn in Claude Code, Cursor oder eine beliebige Claude-Umgebung ein. Sage „audit my database“ und erhalte einen umfassenden Sicherheitsbericht mit exaktem Fix-Code – in Minuten, nicht Tagen.

Über 170 Lovable-Apps wurden kompromittiert. 20,1 Mio. Datensätze waren bei YC-Startups exponiert. ~87.000 MongoDB-Instanzen waren anfällig für MongoBleed (CVE-2025-14847, CISA KEV). 1,8 Mio. Firebase-Passwörter wurden in einem einzigen Vorfall im Jahr 2025 geleakt. 45 % der KI-generierten Codes führen OWASP Top 10-Sicherheitslücken ein. Database Sentinel testet, ob deine Sicherheitskonfiguration tatsächlich funktioniert – nicht nur, ob sie vorhanden ist.

Was es tut

Database Sentinel führt eine 7-stufige Sicherheitsprüfung für die Backends durch, die dein Projekt verwendet:

1. Erkennt, welche Backends du verwendest (Supabase, Firebase, MongoDB, selbstgehostetes Postgres / MySQL)
2. Durchsucht deine Codebasis nach exponierten Anmeldeinformationen, hartcodierten Schlüsseln, Secrets in Git
3. Untersucht jedes Backend – Schema, Richtlinien, Regeln, Benutzer, Rollen, Konfiguration
4. Gleicht die Ergebnisse mit backend-spezifischen Anti-Pattern-Katalogen ab – basierend auf CVEs, Breach-Berichten, CIS-Benchmarks und Vibe-Coding-Forschung von 2025–2026
5. Testet dynamisch mit sicheren Primitiven (tx=rollback, Canary-Collections, optionalem MongoBleed-Detektor)
6. Erstellt einen bewerteten Sicherheitsbericht mit allgemeinverständlichen Erklärungen und konkreten Angriffsszenarien
7. Produziert exakten Fix-Code – SQL DDL, Regeldateien, Konfig-Diffs, Terraform – kopieren, einfügen, erledigt

Backend-übergreifende Analysen erkennen Probleme, die Einzel-Backend-Scanner übersehen (z. B. ein Firebase Auth UID, dem eine Postgres-API ohne JWT-Verifizierung vertraut).

Status

Database Sentinel hieß früher Supabase Sentinel (Einzel-Backend). Die Umbenennung erfolgte während Phase 1 der Multi-Backend-Erweiterung. Ein Abwärtskompatibilitäts-Shim unter compat/supabase-sentinel/ bewahrt den alten Skill-Namen mindestens bis zum nächsten Minor-Release – bestehende Benutzer sehen keine Regression.

Schnellstart

Option 1: Claude Code / Cursor

Klone den Skill in das Skills-Verzeichnis deines Projekts oder in ein zentrales:

git clone https://github.com/Farenhytee/database-sentinel.git ~/claude-skills/database-sentinel

Dann frage Claude:

Audit my database

Database Sentinel erkennt, welche Backends dein Projekt verwendet, führt die entsprechenden Audits durch und erstellt einen einheitlichen Bericht. Wenn mehrere Backends vorhanden sind (Firebase Auth + Postgres-Daten usw.), enthält der Bericht nach Phase 6 einen Abschnitt zu Backend-übergreifenden Interaktionen.

Option 2: Einzel-Backend-Aufruf

Wenn du nur ein bestimmtes Backend prüfen möchtest, frage explizit:

Audit my Supabase project
Audit my MongoDB instance

Der Dispatcher schränkt den Umfang ein.

Option 3: Manuell (beliebiger KI-Assistent)

Kopiere den Inhalt von SKILL.md plus das entsprechende backends/<name>/workflow.md in deinen System-Prompt. Durchlaufe die 7 Schritte mit deinen Anmeldeinformationen.

Was es erkennt

Supabase (Phase 1) – 27 Muster

MongoDB (Phase 2) – 20 Muster

Der MongoBleed-Netzwerkprobe (backends/mongodb/mongobleed-probe.md) enthält einen Ein-Paket-Detektor, der die Ausnutzbarkeit zur Laufzeit bestätigt – verifiziert gegen mongo:7.0.20 (anfällig) und mongo:7.0.28 (gepatcht). Er ist schreibgeschützt, durch zwei Opt-in-Bestätigungen abgesichert und extrahiert niemals Inhalte.

Beispielausgabe

╔════════════════════════════════════════════════════════╗
║                  SENTINEL SECURITY AUDIT               ║
╠════════════════════════════════════════════════════════╣
║  Backends:   supabase, mongodb                         ║
║  Scanned:    2026-04-30 14:30 UTC                      ║
║  Score:      0/100 🔴                                  ║
║  Summary:    2 backends, 8 findings (3C / 4H / 1M)     ║
╚════════════════════════════════════════════════════════╝

─────────────────────────────────────────────────────────
  Supabase                                       35/100 🔴
─────────────────────────────────────────────────────────

🔴 KRITISCH — public.users: RLS Disabled                  [SB-001]

  Risiko:    Jeder im Internet kann deine gesamte Benutzertabelle lesen.
  Angriff:   Browser DevTools öffnen → anon key kopieren → curl auf die API → alle
             E-Mails, Namen und Metadaten auslesen.
  Nachweis:  curl gibt [{"id":"...","email":"[email protected]",...}] zurück
  Quelle:    CVE-2025-48757 / Splinter 0013_rls_disabled_in_public

  Fix:
  ALTER TABLE public.users ENABLE ROW LEVEL SECURITY;

  CREATE POLICY "users_select_own"
    ON public.users FOR SELECT TO authenticated
    USING ((SELECT auth.uid()) = id);

─────────────────────────────────────────────────────────
  MongoDB                                         0/100 🔴
─────────────────────────────────────────────────────────

🔴 KRITISCH — mongod 7.0.20: MongoBleed (CVE-2025-14847)  [MG-SH-001]

  Risiko:    Ein einzelnes TCP-Paket legt Fragmente des MongoDB-Arbeitsspeichers
             offen – einschließlich Anmeldeinformationen, Abfragen und Dokumentdaten – ohne
             dass ein Login erforderlich ist.
  Angriff:   Öffentlicher PoC seit 26. Dez. 2025 verfügbar; CISA KEV. Wiederholte
             Anfragen legen nach und nach mehr des Working Sets offen.
  Nachweis:  buildInfo.version = "7.0.20" (anfällig; gepatcht in 7.0.28)
             zlib compression aktiviert (Standard): true
             Aktiver Probe ergab: anfällig (opCode=2012, 163 Bytes)
  Quelle:    CVE-2025-14847 / CISA KEV / MongoDB Server Security Update Dez. 2025

  Fix:
  Upgrade auf 7.0.28+. Gleichzeitige Abhilfe, falls Upgrade blockiert ist:
  net.compression.compressors = "snappy,zstd"  in mongod.conf

✅ BESTANDEN — Supabase: orders, payments, invoices, subscriptions

Dateistruktur

database-sentinel/
├── SKILL.md                                # Dispatcher – erkennt Backends, leitet Audits weiter (~2K Tokens)
├── DECISIONS.md                            # Festgelegte Architekturentscheidungen (D1-D4 + Ablösungen)
├── core/
│   ├── workflow.md                         # Universeller 7-Schritte-Audit-Workflow
│   ├── detection.md                        # Backend-Erkennung + JSON-Manifest
│   ├── scoring.md                          # Backend-spezifische Gewichtung, Min-Aggregation
│   ├── reporting.md                        # Einheitliches Berichtsformat (Text + JSON)
│   └── credentials.md                      # Umgang mit öffentlichen vs. privilegierten Schlüsseln
├── backends/
│   ├── supabase/                           # Phase 1 – implementiert
│   │   ├── workflow.md                     # 7-Schritte-Audit spezialisiert für Supabase
│   │   ├── audit-queries.md                # 20 SQL-Abfragen zur Schema-Introspektion
│   │   ├── anti-patterns.md                # 27 Muster (SB-001..SB-027)
│   │   └── fix-templates.md                # SQL-Fix-Vorlagen (7 RLS-Muster + mehr)
│   └── mongodb/                            # Phase 2 – implementiert
│       ├── workflow.md                     # 7-Schritte-Audit spezialisiert für MongoDB
│       ├── introspection.md                # mongosh + Atlas Admin API + IaC-Scan
│       ├── anti-patterns.md                # 20 Muster (MG-SH-001..014, MG-AT-001..006)
│       ├── mongobleed-probe.md             # Sicherer CVE-2025-14847 Ein-Paket-Detektor
│       ├── fix-templates.md                # Versionstabelle + mongod.conf + Validatoren + Atlas TF
│       └── test-recipe.md                  # Nur-dokumenten-basiertes End-to-End-Testrezept
├── compat/
│   └── supabase-sentinel/                  # Abwärtskompatibilitäts-Shim (erzwingt backend=supabase)
│       └── SKILL.md
├── references/
│   ├── vibe-coding-context.md              # CVE-2025-48757, Breach-Studien – backend-übergreifend
│   └── cve-feed.md                         # Backend-übergreifende CVE-Liste (MongoBleed gesät)
├── assets/
│   └── ci/
│       ├── github-action-supabase.yml      # 1 Job – Sicherheitsaudit
│       └── github-action-mongodb.yml       # 3 Jobs – statischer IaC, Live-Audit, MongoBleed-Probe
├── README.md                               # Diese Datei
├── LICENSE                                 # MIT
├── DECISIONS.md
└── sentinel-implementation-plan.md         # Multi-Backend-Erweiterungs-Roadmap

So funktioniert progressive Offenlegung: Claude lädt zunächst nur SKILL.md (~2K Tokens) plus core/*. Wenn die Erkennung ein Backend identifiziert, werden das passende backends/<name>/workflow.md und optionale Referenzdateien geladen. Ein reines Supabase-Audit zahlt nicht die Kosten für MongoDB-Inhalte; zukünftige Firebase-/Postgres-/MySQL-Erweiterungen folgen dem gleichen Muster.

Kontinuierliches Monitoring (GitHub Actions)

Jedes implementierte Backend enthält eine CI-Workflow-Vorlage:

Workflows werden bei relevanten Dateiänderungen (Migrationen, Regeldateien, IaC, Abhängigkeitsmanifeste), wöchentlichem Cron (Montag 06:00 UTC) und manueller Auslösung gestartet. Sie posten PR-Kommentare, laden Bericht-Artefakte hoch und lassen den Build bei kritischen Ergebnissen fehlschlagen.

Frage einfach: „Richte kontinuierliches Sicherheitsmonitoring für dieses Projekt ein.“

Forschungsgrundlage

Die Anti-Pattern-Datenbank von Database Sentinel basiert auf:

Supabase / Firebase / Vibe-Coding-Ökosystem

• CVE-2025-48757 – 170+ Lovable-Apps exponiert, CVSS 9.3 (Matt Palmer, Mai 2025)
• Escape.tech – 2.000+ Schwachstellen in 5.600 vibe-codierten Apps (Oktober 2025)
• Veracode – 45 % der KI-generierten Code führen OWASP Top 10-Schwachstellen ein (Juli 2025)
• Carnegie Mellon SusVibes – 82,8 % des funktional korrekten KI-Codes war unsicher (Dezember 2025)
• SupaExplorer – 11 % der Indie-Apps legen Supabase-Anmeldedaten offen (Januar 2026)
• ModernPentest – 20,1 Mio. Datensätze exponiert in 107 YC-Startups (März 2026)
• OpenFirebase / Icex0 (Sept. 2025) – ~150 Firebase-Apps mit unauthentifiziertem Lese-/Schreibzugriff
• Zendata (Mai 2025) – 1,8 Mio. Klartext-Firebase-Passwörter geleakt in über 900 Apps
• GitGuardian – 19,8 Mio. Firebase-Secrets auf öffentlichem GitHub geleakt
• Supabase Splinter – Alle 16 offiziellen Sicherheits-Checks abgebildet und erweitert
• Wiz Research – Kritischer Auth-Bypass in Base44-Vibe-Coding-Plattform (Juli 2025)

MongoDB / Atlas

• CVE-2025-14847 "MongoBleed" (CVSS 8.7, CISA KEV) – Pre-Auth-Heap-Offenlegung, ~87K exponierte Instanzen
• CVE-2024-53900 / CVE-2025-23061 – Mongoose populate-match $where-Injection
• CVE-2025-30706 – MongoDB Connector/J kritisch (Oracle CPU April 2025)
• MongoDB Atlas Data API-Abkündigung (30. Sept. 2025)
• Shadowserver / Meow-Ransomware-Verfolgung (fortlaufende Scans 2024–2025)
• CIS MongoDB 7 Benchmark v1.2

Siehe references/vibe-coding-context.md und references/cve-feed.md für den vollständigen Zitiernachweis.

Was Database Sentinel erkennt, das integrierte Tools übersehen

Sicherheit

Database Sentinel ist für den Einsatz in der Produktion sicher konzipiert:

• Standardmäßig schreibgeschützt. Introspektionsabfragen lesen nur Systemkataloge (pg_tables, pg_policies, getCmdLineOpts usw.). Standardmäßig kein DDL oder DML.
• Schreib-Tests sind optional. Backend-spezifische Strategie:
  • Supabase – Prefer: tx=rollback (PostgREST-nativ; keine Daten modifiziert)
  • Postgres selbstgehostet – BEGIN…ROLLBACK (transaktionales DDL)
  • MongoDB Replica/Sharded – Session + abortTransaction()
  • MongoDB Standalone – Canary-Collection einfügen+löschen (Best-Effort-Bereinigung, als Opt-in formuliert)
  • Firebase – Canary-Collection unter /_sentinel_probe/{random}
  • MySQL selbstgehostet – _sentinel_probe-Schema + DROP DATABASE (Opt-in, destruktiv – explizite Warnung)
• Netzwerk-Tests (MongoBleed) sind Double-Opt-in. Die Audit-Richtlinie muss Netzwerk-Tests aktivieren UND der Benutzer muss den Host-Besitz separat bestätigen. Einige Überwachungstools schlagen beim Testpaket Alarm, obwohl es sich um einen einzelnen 42-Byte-Lesevorgang handelt.

Mitwirken

Beiträge sind willkommen. Die wertvollsten Beiträge:

1. Neue Anti-Patterns – Ein Sicherheitsproblem gefunden, das nicht in unserer Datenbank ist? Füge es mit Schweregrad, Erkennungsabfrage, Fix-Code und realem Nachweis (CVE / Breach / Splinter / CIS) zum entsprechenden backends/<name>/anti-patterns.md hinzu.
2. Verbesserungen von Fix-Vorlagen – Bessere Policy-Muster, Randfälle oder Leistungsoptimierungen in backends/<name>/fix-templates.md.
3. Live-Tests – Führe Database Sentinel gegen deine eigenen Backends aus und melde Fehlalarme / verpasste Funde. Live-Tests haben während Phase 2 drei echte Bugs aufgedeckt (siehe backends/mongodb/mongobleed-probe.md „Empirisch verifiziert“-Anmerkungen).
4. Neue Backend-Erweiterungen – Phasen 3–5 sind offen. Folge der Struktur von backends/mongodb/ und backends/supabase/. Der Implementierungsplan (sentinel-implementation-plan.md) enthält den Vertrag für jedes.
5. Zuordnung von Vibe-Coding-Mustern – Wenn du ein Muster findest, das plausibel KI-generiert von Cursor / Bolt / Lovable / Claude Code ist, dokumentiere es. Das ist das Alleinstellungsmerkmal des Projekts.

So kannst du mitwirken

1. Forke das Repository
2. Branch (git checkout -b add-new-pattern)
3. Füge deine Änderungen mit klarer Dokumentation und Zitaten hinzu
4. PR mit einer Beschreibung des Musters und Nachweisen

Roadmap

Als nächstes ausgeliefert

• Phase 3 – Firebase (Firestore + RTDB + Storage + Cloud Functions + Remote Config + App Check). Die größte Erweiterung; Untermodule pro Firebase-Produkt zur Verwaltung des Token-Budgets.
• Phase 4 – PostgreSQL selbstgehostet, inkl. pgBouncer (CVE-2025-12819-Erkennung)
• Phase 5 – MySQL selbstgehostet (Oracle CPU CVE-Abdeckung; mysql_native_password-Ablösung für 8.4+)
• Phase 6 – Backend-übergreifende Interaktionsanalyse (Firebase Auth → Postgres Trust-Pfade usw.)
• Phase 7 – README-Feinschliff (dieses), BACKENDS.md-Kurzreferenz, Abkündigungszeitplan für den supabase-sentinel-Shim

Zukunft

• CLI-Tool – npx database-sentinel audit für Nicht-Claude-Umgebungen
• MCP-Server – programmatischer Zugriff für CI/CD und Dashboards
• VS Code-Erweiterung – Inline-Sicherheitswarnungen im Editor
• Premium-Dashboard – historische Trends, Multi-Projekt-Ansichten, Slack-Benachrichtigungen

Namensgeschichte

• Supabase Sentinel (v1) – Einzel-Backend Supabase-Auditor. Ursprüngliche Veröffentlichung.
• Sentinel (Arbeitsname während der architektonischen Umstellung in Phase 1)
• DB Sentinel (v2, vorübergehender Arbeitsname während des Multi-Backend-Rollouts)
• Database Sentinel (v3, aktuell) – Multi-Backend; volles Wort „Database“ für explizite Skill-Discovery und Übereinstimmung mit dem GitHub-Repository-Namen

Der Skill-Name supabase-sentinel funktioniert weiterhin über den Kompatibilitäts-Shim unter compat/supabase-sentinel/. Er erzwingt das Audit nur auf Supabase und erzeugt eine Ausgabe, die von v1 nicht zu unterscheiden ist. Abschaltdatum: TBD; mindestens bis zum nächsten Minor-Release.

Lizenz

MIT – Verwende es wie du möchtest, kommerziell oder anderweitig.

Entwickelt für die Vibe-Coding-Ära.
Denn „es funktioniert“ und „es ist sicher“ sind zwei sehr unterschiedliche Dinge.