From claudex-forge
Auditoria OFENSIVA (pentest read-only, não-destrutivo) do seu projeto — pensa como ATACANTE, não como bug hunter. Faz inventário da superfície exposta + todas as portas de entrada, ataca na pele de 8 personas (anônimo, link vazado, baixo privilégio, outro usuário/tenant, ex-membro, admin parcial, integração externa), roda um CÉTICO interno que tenta refutar cada achado, e fecha em 3 listas honestas (VULNERÁVEL / TESTADO E BLOQUEADO / NÃO TESTADO). Regra de ouro: nada é confirmado sem evidência contra o sistema NO AR — código, migration e doc podem estar desatualizados. O alvo, o ambiente e o regime de compliance vêm do claudex.config.json e de references/arquitetura.md; se não estiverem lá, o Passo 0 pergunta ao usuário. É uma MÁQUINA DE ESCOPO: sem alvo + ambiente + contas + ações proibidas definidos, ela PARA e pergunta. Acionar quando o usuário disser "/audit-offensive", "auditoria ofensiva", "pentest do projeto", "testa acesso indevido", "alguém consegue ver dado de outro usuário", "testa se vaza dado entre contas", "testa cross-tenant", "testa RLS de verdade", "alguém sem login consegue X", "red team", "testa link público", "ex-membro ainda acessa?" — mesmo sem citar o nome literal. NÃO acionar para caça-bug de 1 componente (use findbugs), nem para review de PR.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claudex-forge:audit-offensiveThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.
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.
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.
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.
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.)
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:
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.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).Apresentar o escopo travado em 3-4 linhas e aguardar o "vai".
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.
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.
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.
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.
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:
Não começar com time pesado "por garantia" — é caro e dilui o foco.
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.
CONFIRMADO ou PLAUSÍVEL) — severidade CRITICAL/HIGH/MEDIUM/LOW, + sugestão de correção, + como confirmar com segurança se for plausível.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.
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.
references/attack-checklist.md — superfície + portas de entrada, por área de ataquereferences/personas.md — as 8 personas e o que testar em cadareferences/report-template.md — formato exato das 3 listas e dos campos por itemassets/attack-surface-map.template.md — artefato persistente entre rodadasnpx claudepluginhub cassianodiniz/cassiano.diniz --plugin claudex-forgeGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.