--- name: auditoria-seguranca description: "Auditoria completa de segurança de projetos e automações, agnóstica de stack: mapeia o projeto, caça segredos (inclusive no histórico do git e no bundle), RLS e regras de banco abertas, IDOR, injeção, Server Actions sem auth, webhooks de pagamento e n8n expostos, riscos de IA/agentes e falhas de infra, e entrega relatório priorizado com evidência + baseline versionado com diff entre execuções. Use quando pedirem para auditar/revisar a segurança de um projeto, SaaS, app feito com IA ou vibe coding, checar RLS, IDOR, segredos vazados, webhooks expostos, revisar antes de lançar, preparar pentest ou conformidade LGPD." --- # Auditoria de segurança de projeto Auditoria de segurança de aplicações e automações, com foco no que quebra em projeto construído rápido com IA: o código funciona, mas a camada de segurança nunca foi pensada. Escreva tudo em português do Brasil, direto, sem enrolação. ## Regras inegociáveis - **Fase 0 sempre primeiro.** Nunca opine sobre a segurança de um projeto que ainda não foi mapeado. - **Somente leitura por padrão.** Não altere código, não rode exploit contra produção, não use credencial de produção para teste. Propor patch ≠ aplicar patch: só aplique após aprovação explícita, um bloco por vez. - **Todo achado tem evidência** (`arquivo:linha`, workflow/nó, query ou resposta HTTP). Suspeita não confirmada vai marcada como `A VERIFICAR`, com o passo exato de verificação. - **Severidade pela rubrica**, não por impressão: `references/severidade-e-relatorio.md`. Não infle tudo para Crítico nem amenize o que é real. - **Segredo nunca aparece em claro — nem no relatório, nem na conversa.** Use `scripts/secrets_scan.py`, que já mascara. Se um comando ad hoc imprimir um segredo, não o repita; registre só local, regra, fingerprint e instrução de rotação. - **Comprometimento ativo interrompe a auditoria.** Chave vazada publicamente, backdoor ou dados já expostos → pare, avise o usuário na hora e entregue a contenção (revogar/rotacionar, fechar a superfície, preservar logs). Se houver dado pessoal envolvido, inclua o aviso de LGPD de `references/logs-lgpd-incidente.md` (comunicação à ANPD e aos titulares). - **Teste ativo só com autorização explícita do usuário no chat**, só em sistema dele, e preferencialmente em staging/localhost. Nunca teste sistema de terceiro. - **Relatório e baseline são mapa para atacante.** Antes de gravá-los no repositório, confirme se ele é público (ver Fase 4). ## Modos Pergunte qual modo, a menos que o pedido já deixe claro: - **Rápido (pré-lançamento):** Fase 0 + `scripts/secrets_scan.py` + o checklist "Top 12 do vibe coding" de `references/severidade-e-relatorio.md` + relatório curto. Sem baseline. - **Completo:** todas as fases, todos os domínios aplicáveis, relatório + baseline. Em repositório grande, delimite o escopo com o usuário (quais apps/serviços, o que fica de fora) e registre o escopo no relatório. ## Fase 0 — Reconhecimento ```bash bash /scripts/recon.sh # na raiz do projeto ``` O script lista stack, manifests, arquivos `.env` **versionados** (o que é achado) vs. apenas presentes localmente (o que é normal), configs de deploy/CI/IaC, regras de Firebase, pasta do Supabase, exports de n8n, configs de MCP e uso de SDKs de LLM e de pagamento. Complete à mão o que ele não pegar. Registre: linguagem e framework (com versão), banco e ORM, auth, hospedagem/deploy, CI, containers/IaC, automações, e o mapa de **superfícies expostas** — rotas HTTP, Server Actions, APIs, webhooks, jobs, storage público, rotas que chamam APIs pagas. Se a stack ou o escopo ficarem ambíguos, pergunte antes de prosseguir. Nunca assuma Next.js/Supabase por padrão. ## Fase 1 — Coleta de evidências (só leitura) ```bash python3 /scripts/secrets_scan.py --history # working tree + histórico, mascarado python3 /scripts/secrets_scan.py --build # bundle local (.next/static, dist, build, out) bash /scripts/deps_audit.sh # todos os ecossistemas detectados ``` O scanner próprio tem regras para provedores comuns no Brasil (Asaas, Mercado Pago, Meta/WhatsApp) e para chaves atuais de OpenAI, Anthropic, Stripe e Supabase; se o `gitleaks` estiver instalado, roda junto (com `--redact`) e soma o que faltou. JWTs são decodificados para separar chave pública por design (anon/publishable do Supabase) de chave de servidor (`service_role`, `sb_secret_`). Cada segredo sai com fingerprint, usado no ID do achado e no baseline. Banco (acesso somente leitura): `scripts/rls_check.sql` para Postgres/Supabase. Automações: se houver ferramenta/MCP do n8n conectada, liste os workflows por ela; senão, peça o export. ## Fase 2 — Análise por domínio Carregue **só** as referências que a stack detectada justifica. Para cada domínio pulado, diga que pulou e por quê. | Sinal na Fase 0 | Carregue | | --- | --- | | Qualquer app com HTTP/API | `references/app-web.md` (auth, autorização/IDOR, injeção, API e transporte, frameworks) | | Postgres, Supabase, Firebase, Mongo, storage | `references/dados.md` | | Sempre | `references/segredos-e-supply-chain.md` | | Docker, IaC, CI, cloud | `references/infra-e-deploy.md` | | n8n, Make, Zapier, webhooks de automação | `references/automacoes-n8n.md` | | SDK de LLM, agentes, MCP, RAG, observabilidade de LLM | `references/ia-e-agentes.md` | | Pagamento, assinatura, créditos, cupom, rota que chama API paga | `references/pagamentos-e-logica.md` | | URL publicada **e** autorização do usuário para checagem externa | `references/superficie-publicada.md` | | Dados pessoais, logs, resposta a incidente | `references/logs-lgpd-incidente.md` | Fronteira: este skill audita a **aplicação** e o que ela expõe. Saúde e hardening do host/VPS (SO, SSH, firewall, recursos) são da skill `auditoria-servidor`; se aparecerem, registre e indique. ## Fase 3 — Priorização Antes de reportar, **confirme cada achado lendo o código ao redor** — falso positivo custa confiança. Cada achado segue o formato de `references/severidade-e-relatorio.md`: ID estável (`SEC--`), título, severidade pela rubrica, referência OWASP, evidência, cenário de exploração em uma frase, correção com trecho de código, **como verificar que corrigiu**, e esforço. Ordene por severidade. ## Fase 4 — Entrega 1. **Verifique se o repositório é público** (pergunte, ou confira o remoto). Se for público ou houver dúvida, grave relatório e baseline fora do repositório ou em caminho ignorado pelo git, e diga isso ao usuário. 2. **`AUDITORIA-SEGURANCA-.md`** — escopo, resumo executivo em 5 linhas, achados priorizados, plano em ondas (hoje / esta semana / este mês). A onda "este mês" inclui prevenção: secret scanning em pre-commit e no CI, para não regredir. 3. **`SECURITY-BASELINE.md`** — modelo em `references/severidade-e-relatorio.md`. Nas execuções seguintes, compare os IDs com o baseline anterior e abra o relatório com o diff: corrigido, regrediu, novo, aceito. Ao final, ofereça aplicar as correções uma a uma, com aprovação a cada bloco, e — se o usuário usar um tracker conectado — abrir uma tarefa por achado. ## Avaliação da skill `evals/` traz um gerador de projeto propositalmente vulnerável e a lista de achados esperados, para medir se uma versão nova da skill detecta mais do que a anterior.