🛡️ Database Sentinel

Une compétence Claude qui audite vos bases de données backend pour les vulnérabilités de sécurité.

Déposez-la dans Claude Code, Cursor ou tout environnement Claude. Dites « audite ma base de données » et obtenez un rapport de sécurité complet avec le code de correction exact — en quelques minutes, pas en jours.

Plus de 170 applications Lovable ont été compromises. 20,1 millions de lignes ont été exposées parmi les startups YC. Environ 87 000 instances MongoDB ont été laissées vulnérables à MongoBleed (CVE-2025-14847, CISA KEV). 1,8 million de mots de passe Firebase ont fuité lors d'un seul incident en 2025. 45 % du code généré par IA introduit des vulnérabilités OWASP Top 10. Database Sentinel vérifie si votre configuration de sécurité fonctionne réellement — pas seulement si elle est présente.

Ce qu'il fait

Database Sentinel effectue un audit de sécurité en 7 étapes sur le(s) backend(s) utilisé(s) par votre projet :

1. Détecte quels backends vous utilisez (Supabase, Firebase, MongoDB, Postgres / MySQL auto-hébergés)
2. Analyse votre codebase pour trouver des identifiants exposés, des clés en dur, des secrets dans git
3. Inspecte chaque backend — schéma, politiques, règles, utilisateurs, rôles, configuration
4. Compare les résultats avec des catalogues d'anti-patrons spécifiques au backend issus de CVE, rapports de brèche, benchmarks CIS et recherches sur le vibe-coding 2025–2026
5. Sonde dynamiquement avec des primitives sûres (tx=rollback, collections canaries, détecteur MongoBleed sur option)
6. Génère un rapport de sécurité noté avec des explications en français simple et des scénarios d'attaque concrets
7. Produit le code de correction exact — DDL SQL, fichiers de règles, diffs de configuration, Terraform — copiez, collez, c'est fait

Le raisonnement inter-backend détecte des problèmes que les analyseurs mono-backend ratent (par exemple, un UID Firebase Auth considéré comme fiable par une API Postgres sans vérification JWT).

Statut

Database Sentinel s'appelait auparavant Supabase Sentinel (mono-backend). Le renommage a eu lieu pendant la Phase 1 de l'extension multi-backend. Un shim de rétrocompatibilité dans compat/supabase-sentinel/ préserve l'ancien nom de compétence au moins jusqu'à la prochaine version mineure — les utilisateurs existants ne voient aucune régression.

Démarrage rapide

Option 1 : Claude Code / Cursor

Clonez la compétence dans le répertoire des compétences de votre projet, ou dans un répertoire central :

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

Puis demandez à Claude :

Audite ma base de données

Database Sentinel détectera quel(s) backend(s) votre projet utilise, exécutera les audits correspondants et produira un rapport unifié. Si plusieurs backends sont présents (Firebase Auth + données Postgres, etc.), le rapport inclut une section sur les interactions inter-backend une fois la Phase 6 livrée.

Option 2 : Invocation mono-backend

Si vous voulez auditer uniquement un backend spécifique, demandez explicitement :

Audite mon projet Supabase
Audite mon instance MongoDB

Le répartiteur réduit le périmètre.

Option 3 : Manuel (tout assistant IA)

Copiez le contenu de SKILL.md plus le backends/<name>/workflow.md correspondant dans votre prompt système. Parcourez les 7 étapes avec vos identifiants.

Ce qu'il détecte

Supabase (Phase 1) — 27 patrons

MongoDB (Phase 2) — 20 patrons

La sonde réseau MongoBleed (backends/mongodb/mongobleed-probe.md) embarque un détecteur à paquet unique qui confirme l'exploitabilité à l'exécution — vérifié contre mongo:7.0.20 (vulnérable) et mongo:7.0.28 (patché). Il est en lecture seule, verrouillé derrière deux confirmations opt-in, et n'extrait jamais de contenu.

Exemple de sortie

╔════════════════════════════════════════════════════════╗
║                  AUDIT DE SÉCURITÉ SENTINELLE          ║
╠════════════════════════════════════════════════════════╣
║  Backends :   supabase, mongodb                         ║
║  Scanné :     30/04/2026 14:30 UTC                     ║
║  Score :      0/100 🔴                                  ║
║  Résumé :     2 backends, 8 constats (3C / 4H / 1M)    ║
╚════════════════════════════════════════════════════════╝

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

🔴 CRITIQUE — public.users : RLS désactivée                 [SB-001]

  Risque :   N'importe qui sur Internet peut lire toute votre table users.
  Attaque :  Ouvrir DevTools navigateur → copier clé anon → curl l'API → extraire
             tous les emails, noms et métadonnées.
  Preuve :   curl retourne [{"id":"...","email":"[email protected]",...}]
  Source :   CVE-2025-48757 / Splinter 0013_rls_disabled_in_public

  Correction :
  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 🔴
─────────────────────────────────────────────────────────

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

  Risque :   Un seul paquet TCP divulgue des fragments de la mémoire de MongoDB —
             y compris identifiants, requêtes et données documentaires — sans
             nécessiter aucune connexion.
  Attaque :  PoC public disponible depuis le 26 décembre 2025 ; CISA KEV. Des requêtes
             répétées extraient progressivement davantage de l'espace de travail.
  Preuve :   buildInfo.version = "7.0.20" (vulnérable ; patché dans 7.0.28)
             compression zlib activée (par défaut) : true
             Sonde active retourné : vulnérable (opCode=2012, 163 octets)
  Source :   CVE-2025-14847 / CISA KEV / MongoDB Server Security Update Dec 2025

  Correction :
  Mettez à niveau vers 7.0.28+. Atténuation le jour même si la mise à niveau est bloquée :
  net.compression.compressors = "snappy,zstd"  dans mongod.conf

✅ PASSÉ — Supabase : orders, payments, invoices, subscriptions

Structure des fichiers

database-sentinel/
├── SKILL.md                                # Répartiteur — détecte les backends, achemine les audits (~2K tokens)
├── DECISIONS.md                            # Décisions d'architecture verrouillées (D1-D4 + remplacements)
├── core/
│   ├── workflow.md                         # Workflow d'audit universel en 7 étapes
│   ├── detection.md                        # Détection des backends + manifeste JSON
│   ├── scoring.md                          # Poids par backend, agrégation min
│   ├── reporting.md                        # Format de rapport unifié (texte + JSON)
│   └── credentials.md                      # Gestion des clés publiques et privilégiées
├── backends/
│   ├── supabase/                           # Phase 1 — implémenté
│   │   ├── workflow.md                     # Audit en 7 étapes spécialisé pour Supabase
│   │   ├── audit-queries.md                # 20 requêtes SQL pour l'introspection du schéma
│   │   ├── anti-patterns.md                # 27 patrons (SB-001..SB-027)
│   │   └── fix-templates.md                # Modèles de correction SQL (7 patrons RLS + plus)
│   └── mongodb/                            # Phase 2 — implémenté
│       ├── workflow.md                     # Audit en 7 étapes spécialisé pour MongoDB
│       ├── introspection.md                # mongosh + Atlas Admin API + scan IaC
│       ├── anti-patterns.md                # 20 patrons (MG-SH-001..014, MG-AT-001..006)
│       ├── mongobleed-probe.md             # Détecteur à paquet unique sûr CVE-2025-14847
│       ├── fix-templates.md                # Matrice de versions + mongod.conf + validateurs + Atlas TF
│       └── test-recipe.md                  # Recette de test de bout en bout document uniquement
├── compat/
│   └── supabase-sentinel/                  # Shim de rétrocompatibilité (force backend=supabase)
│       └── SKILL.md
├── references/
│   ├── vibe-coding-context.md              # CVE-2025-48757, études de brèches — inter-backend
│   └── cve-feed.md                         # Liste CVE inter-backend (MongoBleed amorcé)
├── assets/
│   └── ci/
│       ├── github-action-supabase.yml      # 1 job — audit de sécurité
│       └── github-action-mongodb.yml       # 3 jobs — IaC statique, audit en direct, sonde MongoBleed
├── README.md                               # ce fichier
├── LICENSE                                 # MIT
├── DECISIONS.md
└── sentinel-implementation-plan.md         # Feuille de route d'extension multi-backend

Comment fonctionne la divulgation progressive : Claude charge uniquement SKILL.md (~2K tokens) plus core/* initialement. Lorsque la détection identifie un backend, le backends/<name>/workflow.md correspondant et les fichiers de référence à la demande sont chargés. Un audit Supabase uniquement ne paie pas le coût du contenu MongoDB ; les futures extensions Firebase / Postgres / MySQL suivent le même schéma.

Surveillance continue (GitHub Actions)

Chaque backend implémenté embarque un modèle de workflow CI :

Les workflows se déclenchent sur les modifications de fichiers pertinents (migrations, fichiers de règles, IaC, manifestes de dépendances), cron hebdomadaire (lundi 06:00 UTC) et déclenchement manuel. Ils publient des commentaires PR, téléchargent des artefacts de rapport et font échouer la build sur les constats critiques.

Demandez simplement : « Configure une surveillance de sécurité continue pour ce projet. »

Recherche sous-jacente

La base de données d'anti-patrons de Database Sentinel est sourcée à partir de :

Écosystème Supabase / Firebase / vibe-coding

• CVE-2025-48757 — 170+ applications Lovable exposées, CVSS 9,3 (Matt Palmer, mai 2025)
• Escape.tech — 2 000+ vulnérabilités dans 5 600 applications vibe-codées (octobre 2025)
• Veracode — 45 % du code généré par IA introduit des vulnérabilités OWASP Top 10 (juillet 2025)
• Carnegie Mellon SusVibes — 82,8 % du code IA fonctionnellement correct était non sécurisé (décembre 2025)
• SupaExplorer — 11 % des applications indés exposent des identifiants Supabase (janvier 2026)
• ModernPentest — 20,1 millions de lignes exposées dans 107 startups YC (mars 2026)
• OpenFirebase / Icex0 (septembre 2025) — ~150 applications Firebase avec lecture/écriture non authentifiée
• Zendata (mai 2025) — 1,8 million de mots de passe Firebase en texte clair divulgués dans 900+ applications
• GitGuardian — 19,8 millions de secrets Firebase divulgués dans GitHub public
• Supabase Splinter — Les 16 lints de sécurité officiels cartographiés et étendus
• Wiz Research — Contournement d'auth critique dans la plateforme de vibe-coding Base44 (juillet 2025)

MongoDB / Atlas

• CVE-2025-14847 « MongoBleed » (CVSS 8,7, CISA KEV) — divulgation heap pré-auth, ~87K instances exposées
• CVE-2024-53900 / CVE-2025-23061 — Injection $where dans populate-match Mongoose
• CVE-2025-30706 — MongoDB Connector/J critique (Oracle CPU avril 2025)
• Dépréciation de l'API Data MongoDB Atlas (30 septembre 2025)
• Suivi Shadowserver / ransomware Meow (opérations continues 2024–2025)
• CIS MongoDB 7 Benchmark v1.2

Voir references/vibe-coding-context.md et references/cve-feed.md pour l'ensemble complet des citations.

Ce que Database Sentinel détecte et que les outils intégrés ratent

Sécurité

Database Sentinel est conçu pour être sûr en production :

• Lecture seule par défaut. Les requêtes d'introspection lisent uniquement les catalogues système (pg_tables, pg_policies, getCmdLineOpts, etc.). Pas de DDL ni DML par défaut.
• Les sondes d'écriture sont opt-in. Stratégie par backend :
  • Supabase — Prefer: tx=rollback (natif PostgREST ; aucune donnée modifiée)
  • Postgres auto-hébergé — BEGIN…ROLLBACK (DDL transactionnel)
  • MongoDB réplica/shardé — session + abortTransaction()
  • MongoDB standalone — insertion+suppression d'une collection canari (nettoyage au mieux, présenté comme opt-in)
  • Firebase — collection canari à /_sentinel_probe/{random}
  • MySQL auto-hébergé — schéma _sentinel_probe + DROP DATABASE (opt-in, destructif — avertissement explicite)
• Les sondes réseau (MongoBleed) sont double-opt-in. La politique d'audit doit activer les sondes réseau ET l'utilisateur doit confirmer la propriété de l'hôte séparément. Certains outils de surveillance alertent sur le paquet de la sonde, même s'il s'agit d'un test en lecture seule de 42 octets.

Contribuer

Les contributions sont les bienvenues. Les contributions les plus précieuses :

1. Nouveaux anti-patrons — Vous avez trouvé un problème de sécurité absent de notre base ? Ajoutez-le dans le backends/<name>/anti-patterns.md correspondant avec sévérité, requête de détection, code de correction et preuve réelle (CVE / brèche / Splinter / CIS).
2. Améliorations des modèles de correction — Meilleurs patrons de politiques, cas limites ou optimisations de performance dans backends/<name>/fix-templates.md.
3. Tests en direct — Exécutez Database Sentinel contre vos propres backends et signalez les faux positifs / négatifs. Les tests en direct ont permis de détecter trois vrais bugs pendant la Phase 2 (voir annotations « Vérifié empiriquement » dans backends/mongodb/mongobleed-probe.md).
4. Extensions de nouveaux backends — Les phases 3 à 5 sont ouvertes. Suivez la structure de backends/mongodb/ et backends/supabase/. Le plan d'implémentation (sentinel-implementation-plan.md) contient le contrat pour chacun.
5. Attribution de patrons de vibe-coding — Lorsque vous trouvez un patron plausiblement généré par IA (Cursor / Bolt / Lovable / Claude Code), documentez-le. C'est le fer de lance du projet.

Comment contribuer

1. Forkez le dépôt
2. Créez une branche (git checkout -b ajout-nouveau-patron)
3. Ajoutez vos modifications avec une documentation claire et des citations
4. PR avec une description du patron et des preuves

Feuille de route

À livrer prochainement

• Phase 3 — Firebase (Firestore + RTDB + Storage + Cloud Functions + Remote Config + App Check). La plus grande extension ; sous-modules par produit Firebase pour gérer le budget de tokens.
• Phase 4 — PostgreSQL auto-hébergé, y compris pgBouncer (détection CVE-2025-12819)
• Phase 5 — MySQL auto-hébergé (couverture Oracle CPU CVE ; gestion de la dépréciation mysql_native_password pour 8.4+)
• Phase 6 — Analyse des interactions inter-backend (Firebase Auth → chemins de confiance Postgres, etc.)
• Phase 7 — Polissage du README (celui-ci), référence rapide BACKENDS.md, calendrier de dépréciation du shim supabase-sentinel

Futur

• Outil CLI — npx database-sentinel audit pour les environnements non-Claude
• Serveur MCP — accès programmatique pour CI/CD et tableaux de bord
• Extension VS Code — avertissements de sécurité en ligne dans l'éditeur
• Tableau de bord premium — tendances historiques, vues multi-projets, alertes Slack

Historique du nom

• Supabase Sentinel (v1) — auditeur Supabase mono-backend. Version originale.
• Sentinel (nom de travail pendant le refactoring architectural de la Phase 1)
• DB Sentinel (v2, nom de travail transitoire pendant le déploiement multi-backend)
• Database Sentinel (v3, actuel) — multi-backend ; mot complet « database » pour un cadrage explicite de découverte de compétence et pour correspondre au nom du dépôt GitHub

Le nom de compétence supabase-sentinel fonctionne toujours via le shim de compatibilité dans compat/supabase-sentinel/. Il force l'audit sur Supabase uniquement et produit une sortie indiscernable de la v1. Date de fin de vie : à déterminer ; au moins jusqu'à la prochaine version mineure.

Licence

MIT — utilisez-le comme vous voulez, commercialement ou non.

Conçu pour l'ère du vibe-coding.
Parce que « ça marche » et « c'est sécurisé » sont deux choses très différentes.