audit-offensive

audit-offensive — Auditoria ofensiva (pentest) do seu projeto

Skill de descoberta com cabeça de atacante, complementar às de bug. A skill findbugs acha bug lendo código por tipo/severidade. Esta ataca a superfície exposta na pele de quem quer entrar onde não devia. Acha → entrega pro seu tracker de issues (gestão) ou pro fluxo de correção (/claudex-forge). Ela não conserta — só caça, prova e classifica.

---

⚖️ USO RESPONSÁVEL (ler primeiro)

Esta é uma ferramenta ofensiva. Use-a somente contra sistemas que VOCÊ controla ou para os quais tem autorização explícita por escrito para testar. Atacar sistemas de terceiros sem autorização é ilegal na maioria das jurisdições. O comportamento padrão é read-only e nunca contra dado real de produção sem as travas de segurança abaixo. Na dúvida sobre o escopo da sua autorização, PARE e confirme antes de testar.

---

Identidade do alvo (de onde vem)

O alvo, o ambiente e o regime de compliance não são cravados — eles vêm da configuração do projeto. No Passo 0, carregue (se existirem):

Campo	Fonte
Projeto / repo	claudex.config.json (project_name, repo_owner, repo_name, repo_path_*)
Produção / staging	claudex.config.json (deploy_url, staging_url)
Backend / banco / auth	claudex.config.json (stack_backend, stack_database, stack_auth, backend_project_id, api_base_url)
Compliance	references/arquitetura.md — o regime aplicável ao projeto (ex.: LGPD, GDPR, HIPAA). A auditoria não pode virar o próprio vazamento.
Tabelas/recursos sensíveis + helper de authz	references/arquitetura.md (schema, tabelas reguladas, função/guard de autorização)

Se qualquer um faltar, o Passo 0 pergunta ao usuário — não inventa. Sugerir registrar a resposta em references/arquitetura.md pra não perguntar de novo.

---

⛔ Regras de segurança — NÃO-NEGOCIÁVEIS (a própria auditoria não pode causar estrago)

O maior risco aqui não é técnico, é operacional: uma IA testando produção com dado real. Estas regras vêm antes de qualquer achado. Se um teste só for possível quebrando uma destas, o item vira NÃO TESTADO — nunca force.

1. Read-only por padrão. Consultas e requests de leitura, sim. Mutação de dado real, não: nada de criar/editar/deletar registro, usuário, pedido, conta, perfil ou dado de verdade.
2. Nunca disparar efeito externo real — e-mail, mensagem, cobrança, webhook, fila, contrato/assinatura, automação. Se o teste dispararia um desses, para e marca como NÃO TESTADO (ou usa cenário sintético aprovado).
3. Contas sintéticas, não dado real. Testar cross-tenant/ex-membro/baixo-privilégio exige contas de teste seedadas (usuário A, usuário B, ex-membro, admin parcial). Persona sem conta disponível → vira NÃO TESTADO, nunca "seguro" por omissão.
4. PII nunca entra no relatório. Mascarar e-mail, documento, telefone, token, ID real de registro/usuário. O relatório vai pro git — vazar PII nele é furo de compliance criado pela auditoria. Rode seu scanner de PII (se tiver um) contra o arquivo antes de salvar.
5. Confirmar o ambiente antes de concluir. Testou contra produção? Contra local? Um achado de produção só vale com evidência contra produção. Ler migration/código não prova o estado de produção (ver Regra de Ouro).
6. Sem carga / fuzzing agressivo / lockout. Teste de login/sessão pode bloquear conta real ou mascarar bug por rate-limit. Limitar tentativas; preferir a conta sintética.
7. Nada destrutivo entra sem autorização explícita do usuário — mesmo "só pra confirmar". Achado que exige passo destrutivo pra fechar fica PLAUSÍVEL, não CONFIRMADO.

---

REGRA DE OURO (transversal)

Nada entra como VULNERÁVEL confirmado sem evidência contra o sistema atual no ar. Código, documentação e migration podem estar desatualizados; o comportamento real e o estado atual das permissões são a verdade. Um achado por leitura de código que uma camada real bloqueia não é vulnerabilidade — é falso positivo. (Padrão comum: achado de RLS/ACL do hunter costuma ser falso positivo quando a escrita passa por uma função de backend com credencial de serviço; sempre checar o cliente real do request antes de cravar.)

---

Passo 0 — MÁQUINA DE ESCOPO (obrigatório; sem isso, PARE e pergunte)

Pentest genérico em produção dá relatório bonito e confiança ruim. Antes de qualquer teste, trave o escopo com o usuário. Comece carregando o contexto do projeto (claudex.config.json, references/arquitetura.md). Se faltar qualquer item, pergunte — não invente:

1. Alvo da rodada — repo inteiro é amplo demais pra uma rodada ofensiva boa. Escolher UMA frente (ver references/attack-checklist.md): superfície pública/anônima · RLS/ACL cross-tenant · funções de backend · links públicos/tokens · auth & sessão · storage · área restrita · abuso de regra legítima.
2. Ambiente autorizado — produção (deploy_url) ou local? Confirmar URL e o deploy/commit atual. Confirmar também que você tem autorização para testar esse ambiente (ver USO RESPONSÁVEL).
3. Contas/personas disponíveis — quais contas sintéticas existem pra usar? (anônimo é grátis; as outras precisam ser seedadas). O que não tiver conta vira NÃO TESTADO.
4. Ações proibidas — confirmar o default (read-only, sem efeito externo) e qualquer trava extra desta rodada.
5. Limite de cota — passe único (rotina) ou multi-agente (rodada crítica)? Ver "Como executar".
6. Fontes autoritativas permitidas — MCP do banco (consulta read-only, advisors), logs do deploy, URL de produção, repo local, PRs.

Apresentar o escopo travado em 3-4 linhas e aguardar o "vai".

---

Passo 1 — Inventário de superfície + portas de entrada

O buraco mora na porta esquecida, não na principal.

Para a frente escolhida, levante a superfície exposta e, pra cada alvo, todas as portas de entrada (frontend, outra função, job, webhook, chamada admin, link público, token compartilhável, integração de terceiro). Detalhe completo do que enumerar em references/attack-checklist.md. Adapte os checklists à stack detectada no projeto (do claudex.config.json / references/arquitetura.md e do manifesto do repo).

Atualize o artefato persistente attack-surface-map.md (template em assets/) com portas mapeadas, personas testadas e o que ficou de fora — assim a próxima rodada não recomeça do zero e gasta menos cota.

Priorizar por: exposição externa → acesso anônimo/por link → dado sensível → risco entre contas/tenants → capacidade de escrita/envio/alteração financeira.

---

Passo 2 — Atacar na pele das personas

Investigue como cada persona aplicável ao alvo. As 8 personas, o que testar em cada (incluindo o roteiro detalhado de ex-membro: sessão ainda válida, refresh token, membership removido, papel rebaixado, convite reutilizável, token criado antes da revogação) estão em references/personas.md.

Ponto cego que escapa de bug hunter — abuso de regra legítima, não só bypass: usuário com acesso válido vendo mais histórico do que deveria, link público expondo metadado demais, admin parcial inferindo dado de outra conta por tela legítima, função de backend que aceita ID externo válido mas sem checar dono (ownership). Caçar isto explicitamente — costuma passar batido até por RLS/ACL superficial.

---

Passo 3 — CÉTICO interno (antes de qualquer item entrar no relatório)

Para cada achado candidato, rode um cético que tenta provar que o achado é falso. Ele procura: policy/RLS/ACL que bloqueia, guard no código, validação server-side, checagem de role, escopo obrigatório por usuário/tenant, token com escopo correto, expiração/revogação, camada compensatória, comportamento real observado, risco já aceito/documentado.

• Cético achou defesa efetiva → sai de VULNERÁVEL.
• Ataque tentado e bloqueado → TESTADO E BLOQUEADO.
• Cético não refutou + mecanismo concreto existe → VULNERÁVEL (CONFIRMADO se reproduzido; PLAUSÍVEL se a reprodução exigia setup indisponível/conta ausente/passo inseguro).
• Sem tentativa real e sem mecanismo concreto → NÃO TESTADO.

Não há terceira saída pra achado material: ou a defesa refuta, ou entra em VULNERÁVEL. O que não é material vai pra NÃO TESTADO.

---

Como executar — escala conforme a rodada

Padrão (rotina, cota apertada): passe único. Você mesmo roda Passo 1→2→3 com o checklist ofensivo + cético interno. Resolve a maior parte.

Rodada crítica → multi-agente (só quando vale a cota): mudou RLS/ACL/auth, área restrita, função de backend com dado sensível, link público novo, pré-release. Aí spawne:

1. 1 agente de inventário (superfície + portas + personas disponíveis)
2. 1-2 agentes ofensivos (uma área cada, em paralelo)
3. 1 cético/validador separado (refuta os achados, contexto fresco)
4. 1 consolidador (monta as 3 listas + próximos testes)

Não começar com time pesado "por garantia" — é caro e dilui o foco.

---

Relatório final — 3 listas (formato completo em references/report-template.md)

Linguagem honesta, sem absolutos. Cada item de VULNERÁVEL e TESTADO E BLOQUEADO carrega sempre: persona · porta de entrada · evidência · impacto · limite do teste · próximo passo.

1. VULNERÁVEL (CONFIRMADO ou PLAUSÍVEL) — severidade CRITICAL/HIGH/MEDIUM/LOW, + sugestão de correção, + como confirmar com segurança se for plausível.
2. TESTADO E BLOQUEADO — ataque tentado que falhou, com a defesa identificada (policy/guard/role/scope/expiração). Não é "seguro" geral: é "esse ataque, nessa persona, nesse ambiente, nessa data, foi bloqueado".
3. NÃO TESTADO / INCONCLUSIVO — o que não deu pra cobrir + por quê + o que faltaria pra cobrir (ex.: "precisa de 2ª conta sintética").

Os 3 piores erros do relatório (evitar a todo custo): inflar "testado e bloqueado" com item não testado; inflar "confirmado" com inferência não reproduzida; inflar "plausível" com mera ausência de teste.

---

Depois da auditoria

Entregar os achados de VULNERÁVEL pro seu tracker de issues (vira entrada do tracker) ou gerar prompt pro fluxo de correção (/claudex-forge). Esta skill nunca conserta nem commita fix — fronteira clara com as skills de correção.

Quando PARAR e escalar pro usuário

• Faltou qualquer item do escopo (Passo 0) → para e pergunta
• Um teste só fecha com passo destrutivo / mutação real / efeito externo → fica PLAUSÍVEL e escala a decisão
• Achado CRITICAL em produção → avisar antes de seguir testando (pode estar exposto agora)
• Persona sem conta sintética disponível → registrar NÃO TESTADO e perguntar se vale seedar

Arquivos de referência (ler quando precisar)

• references/attack-checklist.md — superfície + portas de entrada, por área de ataque
• references/personas.md — as 8 personas e o que testar em cada
• references/report-template.md — formato exato das 3 listas e dos campos por item
• assets/attack-surface-map.template.md — artefato persistente entre rodadas