🛡️ Database Sentinel

Uma Skill do Claude que audita seus backends de banco de dados em busca de vulnerabilidades de segurança.

Coloque-a no Claude Code, no Cursor ou em qualquer ambiente com tecnologia Claude. Diga "audite meu banco de dados" e receba um relatório abrangente de segurança com o código de correção exato — em minutos, não em dias.

Mais de 170 apps Lovable foram violados. 20,1 milhões de linhas foram expostas em startups do YC. ~87.000 instâncias MongoDB ficaram vulneráveis ao MongoBleed (CVE-2025-14847, CISA KEV). 1,8 milhão de senhas do Firebase vazaram em um único incidente de 2025. 45% do código gerado por IA introduz vulnerabilidades do OWASP Top 10. O Database Sentinel testa se sua configuração de segurança realmente funciona — não apenas se ela existe.

O que ele faz

O Database Sentinel realiza uma auditoria de segurança em 7 etapas nos backend(s) que seu projeto utiliza:

1. Detecta quais backends você está usando (Supabase, Firebase, MongoDB, Postgres / MySQL auto-hospedados)
2. Escaneia sua base de código em busca de credenciais expostas, chaves hardcoded e segredos no git
3. Inspeciona cada backend — esquema, políticas, regras, usuários, papéis, configuração
4. Compara os achados com catálogos de anti-padrões específicos de cada backend, baseados em CVEs, relatórios de violações, benchmarks CIS e pesquisas de vibe-coding de 2025–2026
5. Testa dinamicamente com primitivas seguras (tx=rollback, coleções canário, detector opt-in de MongoBleed)
6. Gera um relatório de segurança com pontuação, com explicações em linguagem simples e cenários concretos de ataque
7. Produz o código de correção exato — SQL DDL, arquivos de regras, diffs de configuração, Terraform — copie, cole, pronto

O raciocínio entre backends detecta problemas que scanners de backend único não percebem (por exemplo, um UID do Firebase Auth considerado confiável por uma API Postgres sem verificação JWT).

Status

O Database Sentinel era anteriormente o Supabase Sentinel (backend único). A renomeação aconteceu durante a Fase 1 da expansão multi-backend. Um shim de compatibilidade com versões anteriores em compat/supabase-sentinel/ preserva o nome antigo da skill por pelo menos a próxima versão menor — usuários existentes não veem nenhuma regressão.

Início rápido

Opção 1: Claude Code / Cursor

Clone a skill para o diretório de skills do seu projeto, ou para um diretório central:

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

Depois peça ao Claude:

Audit my database

O Database Sentinel detectará qual(is) backend(s) seu projeto usa, executará as auditorias relevantes e produzirá um relatório unificado. Se houver múltiplos backends (Firebase Auth + dados Postgres, etc.), o relatório incluirá uma seção de interações entre backends quando a Fase 6 for lançada.

Opção 2: Invocação de backend único

Se você quiser auditar apenas um backend específico, peça explicitamente:

Audit my Supabase project
Audit my MongoDB instance

O dispatcher restringe o escopo.

Opção 3: Manual (qualquer assistente de IA)

Copie o conteúdo de SKILL.md mais o backends/<name>/workflow.md relevante para o seu prompt de sistema. Percorra as 7 etapas com suas credenciais.

O que ele detecta

Supabase (Fase 1) — 27 padrões

MongoDB (Fase 2) — 20 padrões

A sonda de rede MongoBleed (backends/mongodb/mongobleed-probe.md) inclui um detector de pacote único que confirma a explorabilidade em tempo de execução — verificado contra mongo:7.0.20 (vulnerável) e mongo:7.0.28 (corrigido). Ela é somente leitura, exige duas confirmações opt-in e nunca extrai conteúdo.

Exemplo de saída

╔════════════════════════════════════════════════════════╗
║                  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 🔴
─────────────────────────────────────────────────────────

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

  Risk:     Anyone on the internet can read your entire users table.
  Attack:   Open browser DevTools → copy anon key → curl the API → dump
            all emails, names, and metadata.
  Proof:    curl returns [{"id":"...","email":"[email protected]",...}]
  Source:   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 🔴
─────────────────────────────────────────────────────────

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

  Risk:     A single TCP packet leaks fragments of MongoDB's memory —
            including credentials, queries, and document data — without
            requiring any login.
  Attack:   Public PoC available since Dec 26 2025; CISA KEV. Repeated
            requests progressively dump more of the working set.
  Proof:    buildInfo.version = "7.0.20" (vulnerable; patched in 7.0.28)
            zlib compression enabled (default): true
            Active probe returned: vulnerable (opCode=2012, 163 bytes)
  Source:   CVE-2025-14847 / CISA KEV / MongoDB Server Security Update Dec 2025

  Fix:
  Upgrade to 7.0.28+. Same-day mitigation if upgrade is blocked:
  net.compression.compressors = "snappy,zstd"  in mongod.conf

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

Estrutura de arquivos

database-sentinel/
├── SKILL.md                                # Dispatcher — detects backends, routes audits (~2K tokens)
├── DECISIONS.md                            # Locked architecture decisions (D1-D4 + supersessions)
├── core/
│   ├── workflow.md                         # Universal 7-step audit workflow
│   ├── detection.md                        # Backend detection + JSON manifest
│   ├── scoring.md                          # Per-backend weights, min-aggregation
│   ├── reporting.md                        # Unified report format (text + JSON)
│   └── credentials.md                      # Public-vs-privileged key handling
├── backends/
│   ├── supabase/                           # Phase 1 — implemented
│   │   ├── workflow.md                     # 7-step audit specialized for Supabase
│   │   ├── audit-queries.md                # 20 SQL queries for schema introspection
│   │   ├── anti-patterns.md                # 27 patterns (SB-001..SB-027)
│   │   └── fix-templates.md                # SQL fix templates (7 RLS patterns + more)
│   └── mongodb/                            # Phase 2 — implemented
│       ├── workflow.md                     # 7-step audit specialized for MongoDB
│       ├── introspection.md                # mongosh + Atlas Admin API + IaC scan
│       ├── anti-patterns.md                # 20 patterns (MG-SH-001..014, MG-AT-001..006)
│       ├── mongobleed-probe.md             # Safe CVE-2025-14847 single-packet detector
│       ├── fix-templates.md                # Version matrix + mongod.conf + validators + Atlas TF
│       └── test-recipe.md                  # Document-only end-to-end test recipe
├── compat/
│   └── supabase-sentinel/                  # Backwards-compat shim (forces backend=supabase)
│       └── SKILL.md
├── references/
│   ├── vibe-coding-context.md              # CVE-2025-48757, breach studies — cross-backend
│   └── cve-feed.md                         # Cross-backend CVE list (MongoBleed seeded)
├── assets/
│   └── ci/
│       ├── github-action-supabase.yml      # 1 job — security audit
│       └── github-action-mongodb.yml       # 3 jobs — static IaC, live audit, MongoBleed probe
├── README.md                               # this file
├── LICENSE                                 # MIT
├── DECISIONS.md
└── sentinel-implementation-plan.md         # Multi-backend expansion roadmap

Como funciona a revelação progressiva: o Claude carrega inicialmente apenas SKILL.md (~2K tokens) mais core/*. Quando a detecção identifica um backend, o backends/<name>/workflow.md correspondente e os arquivos de referência sob demanda são carregados. Uma auditoria somente de Supabase não paga o custo do conteúdo de MongoDB; futuras extensões de Firebase / Postgres / MySQL seguem o mesmo padrão.

Monitoramento contínuo (GitHub Actions)

Cada backend implementado inclui um modelo de workflow de CI:

Os workflows são acionados por mudanças relevantes em arquivos (migrações, arquivos de regras, IaC, manifestos de dependências), cron semanal (segunda-feira 06:00 UTC) e dispatch manual. Eles postam comentários em PRs, enviam artefatos de relatório e fazem o build falhar quando há achados críticos.

Basta pedir: "Configure o monitoramento contínuo de segurança para este projeto."

Fundamentação de pesquisa

O banco de dados de anti-padrões do Database Sentinel é baseado em:

Ecossistema Supabase / Firebase / vibe-coding

• CVE-2025-48757 — mais de 170 apps Lovable expostos, CVSS 9.3 (Matt Palmer, maio de 2025)
• Escape.tech — mais de 2.000 vulnerabilidades em 5.600 apps vibe-coded (outubro de 2025)
• Veracode — 45% do código gerado por IA introduz vulnerabilidades do OWASP Top 10 (julho de 2025)
• Carnegie Mellon SusVibes — 82,8% do código de IA funcionalmente correto era inseguro (dezembro de 2025)
• SupaExplorer — 11% dos apps indie expõem credenciais do Supabase (janeiro de 2026)
• ModernPentest — 20,1 milhões de linhas expostas em 107 startups do YC (março de 2026)
• OpenFirebase / Icex0 (setembro de 2025) — ~150 apps Firebase com leitura/escrita não autenticada
• Zendata (maio de 2025) — 1,8 milhão de senhas Firebase em texto puro vazadas em mais de 900 apps
• GitGuardian — 19,8 milhões de segredos do Firebase vazados no GitHub público
• Supabase Splinter — Todos os 16 lints oficiais de segurança mapeados e estendidos
• Wiz Research — Bypass crítico de autenticação na plataforma de vibe-coding Base44 (julho de 2025)

MongoDB / Atlas

• CVE-2025-14847 "MongoBleed" (CVSS 8.7, CISA KEV) — divulgação de heap pré-autenticação, ~87 mil instâncias expostas
• CVE-2024-53900 / CVE-2025-23061 — injeção $where em populate-match do Mongoose
• CVE-2025-30706 — MongoDB Connector/J crítico (Oracle CPU abril de 2025)
• Descontinuação da MongoDB Atlas Data API (30 de setembro de 2025)
• Rastreamento de ransomware Shadowserver / Meow (varreduras contínuas de 2024–2025)
• CIS MongoDB 7 Benchmark v1.2

Veja references/vibe-coding-context.md e references/cve-feed.md para o conjunto completo de citações.

O que o Database Sentinel detecta e que as ferramentas integradas deixam passar

Segurança

O Database Sentinel foi projetado para ser seguro para uso em produção:

• Somente leitura por padrão. Consultas de introspecção apenas leem catálogos do sistema (pg_tables, pg_policies, getCmdLineOpts, etc.). Nenhum DDL ou DML por padrão.
• Sondas de escrita são opt-in. Estratégia por backend:
  • Supabase — Prefer: tx=rollback (nativo do PostgREST; zero dados modificados)
  • Postgres auto-hospedado — BEGIN…ROLLBACK (DDL transacional)
  • MongoDB réplica/sharded — sessão + abortTransaction()
  • MongoDB standalone — inserção+exclusão em coleção canário (limpeza de melhor esforço, apresentada como opt-in)
  • Firebase — coleção canário em /_sentinel_probe/{random}
  • MySQL auto-hospedado — schema _sentinel_probe + DROP DATABASE (opt-in, destrutivo — aviso explícito)
• Sondas de rede (MongoBleed) são duplo opt-in. A política de auditoria deve habilitar sondas de rede E o usuário deve confirmar a propriedade do host separadamente. Algumas ferramentas de monitoramento alertam sobre o pacote da sonda, mesmo sendo um único teste de 42 bytes somente leitura.

Contribuições

Contribuições são bem-vindas. As contribuições mais valiosas:

1. Novos anti-padrões — Encontrou um problema de segurança que não está no nosso banco? Adicione-o ao backends/<name>/anti-patterns.md relevante com gravidade, consulta de detecção, código de correção e evidência do mundo real (CVE / violação / Splinter / CIS).
2. Melhorias nos modelos de correção — Melhores padrões de política, casos extremos ou otimizações de desempenho em backends/<name>/fix-templates.md.
3. Testes ao vivo — Execute o Database Sentinel contra seus próprios backends e relate falsos positivos / negativos. Os testes ao vivo detectaram três bugs reais durante a Fase 2 (veja as anotações "Empirically verified" em backends/mongodb/mongobleed-probe.md).
4. Novas extensões de backend — As Fases 3–5 estão abertas. Siga a estrutura de backends/mongodb/ e backends/supabase/. O plano de implementação (sentinel-implementation-plan.md) tem o contrato para cada uma.
5. Atribuição de padrões de vibe-coding — Quando você encontrar um padrão que seja plausivelmente gerado por IA via Cursor / Bolt / Lovable / Claude Code, documente-o. É a porta de entrada do projeto.

Como contribuir

1. Faça um fork do repositório
2. Crie uma branch (git checkout -b add-new-pattern)
3. Adicione suas mudanças com documentação e citações claras
4. Abra um PR com uma descrição do padrão e evidências

Roadmap

Próximas entregas

• Fase 3 — Firebase (Firestore + RTDB + Storage + Cloud Functions + Remote Config + App Check). A maior extensão; submódulos por produto Firebase para gerenciar o orçamento de tokens.
• Fase 4 — PostgreSQL auto-hospedado, incluindo pgBouncer (detecção de CVE-2025-12819)
• Fase 5 — MySQL auto-hospedado (cobertura de CVEs do Oracle CPU; tratamento da descontinuação do mysql_native_password para 8.4+)
• Fase 6 — Análise de interação entre backends (caminhos de confiança Firebase Auth → Postgres, etc.)
• Fase 7 — polimento do README (este), referência rápida BACKENDS.md, cronograma de descontinuação do shim supabase-sentinel

Futuro

• Ferramenta CLI — npx database-sentinel audit para ambientes sem Claude
• Servidor MCP — acesso programático para CI/CD e dashboards
• Extensão para VS Code — avisos de segurança inline no editor
• Dashboard premium — tendências históricas, visualizações de múltiplos projetos, alertas do Slack

Histórico de nomes

• Supabase Sentinel (v1) — auditor de Supabase de backend único. Lançamento original.
• Sentinel (nome de trabalho durante o refatoramento arquitetural da Fase 1)
• DB Sentinel (v2, nome de trabalho transitório durante a implantação multi-backend)
• Database Sentinel (v3, atual) — multi-backend; a palavra completa "database" para um enquadramento explícito de descoberta da skill e para corresponder ao nome do repositório no GitHub

O nome da skill supabase-sentinel ainda funciona via shim de compatibilidade em compat/supabase-sentinel/. Ele força a auditoria apenas para Supabase e produz uma saída indistinguível da v1. Data de descontinuação: a definir; por pelo menos a próxima versão menor.

Licença

MIT — use como quiser, comercialmente ou não.

Construído para a era do vibe-coding.
Porque "funciona" e "é seguro" são duas coisas muito diferentes.