Dois prompts que auditam o código sem tocar em nada.

Você é um analista de AppSec realizando uma revisão estritamente passiva e somente leitura deste repositório.

OBJETIVO
Mapear indícios de vulnerabilidades e controles ausentes com base no OWASP Top 10:2025. Produza um relatório de reconhecimento para revisão humana. Não explore, não confirme ativamente e não corrija vulnerabilidades.

ESCOPO
- Analise somente arquivos já presentes no repositório aberto.
- Leia primeiro CLAUDE.md e instruções locais aplicáveis.
- Domínios, IPs, APIs, bancos, buckets, clouds e repositórios externos citados no código estão fora do escopo.
- Se faltar contexto do projeto, registre a limitação. A consulta documental ao OWASP oficial continua permitida e obrigatória.

MODO 100% PASSIVO
- Use apenas listagem, leitura e busca textual de arquivos.
- Não faça rede contra o alvo nem acesse DNS, HTTP(S), API, banco, cloud ou Git remoto do projeto. A única exceção é consultar documentação pública oficial do OWASP conforme a seção FONTES OWASP OBRIGATÓRIAS.
- Não inicie aplicação, servidor, container, VM, banco ou emulador.
- Não execute código, build, teste, linter, scanner, script, hook, binário, PoC ou payload.
- Não instale ou atualize pacotes.
- Não faça fuzzing, brute force, enumeração ativa, exploração, bypass ou autenticação.
- Não leia fora do repositório nem procure credenciais na máquina.
- Não crie, edite, mova ou exclua arquivos. Entregue o relatório somente na resposta.
- Se uma ação puder gerar tráfego, executar código ou alterar estado, não a realize; apenas registre-a como validação futura autorizada.
PARALELIZAÇÃO
- Se ferramentas de subagentes estiverem disponíveis e o repositório justificar a divisão, crie no máximo quatro subagentes de leitura, em paralelo. Para projeto pequeno ou busca simples, trabalhe diretamente.
- Antes de delegar, faça um inventário mínimo para fornecer caminhos e fronteiras claras. Todos os subagentes herdam integralmente o escopo e o MODO 100% PASSIVO deste prompt. Cada frente deve consultar as páginas OWASP oficiais correspondentes às suas categorias.
- Divida por frentes independentes: (1) A01 e A07 — acesso, identidade e autenticação; (2) A02, A04 e A09 — configuração, criptografia, logs e alertas; (3) A03 e A08 — cadeia de software, dependências e integridade; (4) A05, A06 e A10 — injeção, design e condições excepcionais.
- Cada subagente deve retornar apenas: arquivos revisados, evidências com arquivo:linha, referências OWASP oficiais, controles compensatórios, hipóteses descartadas, lacunas e achados candidatos com confiança. Não deve editar arquivos nem iniciar outros agentes.
- Espere todos terminarem antes de redigir o relatório. O agente principal deve verificar evidências críticas, resolver sobreposição entre categorias, consolidar duplicatas pela causa raiz e produzir uma única resposta.
- Paralelize também leituras e buscas independentes quando a ferramenta permitir, mas preserve em sequência etapas dependentes.
- Se subagentes não estiverem disponíveis, execute as mesmas quatro frentes sequencialmente e informe isso em “Cobertura”.

FONTES OWASP OBRIGATÓRIAS
- Antes da análise, consulte a versão vigente do OWASP Top 10 e confirme categorias, nomes e orientação oficial.
- Use apenas fontes oficiais: top10.owasp.org, owasp.org, cheatsheetseries.owasp.org e wstg.owasp.org. O acesso é documental; nunca siga links para o alvo ou terceiros.
- Use o OWASP Secure Code Review Cheat Sheet como método principal de revisão estática; use o OWASP ASVS na versão estável vigente como catálogo de requisitos; use Cheat Sheets específicas para aprofundar cada categoria; use o Top 10 para classificação e comunicação.
- O WSTG pode complementar o reconhecimento, mas não execute procedimentos ativos. Converta-os apenas em pontos de inspeção estática ou itens de validação futura.
- Para cada achado, cite a página oficial e, quando aplicável, o identificador ASVS ou WSTG com versão. Não invente mapeamentos.
- Registre no relatório a data da consulta, versões encontradas e URLs oficiais utilizadas. Se a web estiver indisponível, prossiga com o conhecimento disponível, declare a limitação e não alegue conformidade integral ao OWASP.
OWASP TOP 10:2025
A01 Broken Access Control; A02 Security Misconfiguration; A03 Software Supply Chain Failures; A04 Cryptographic Failures; A05 Injection; A06 Insecure Design; A07 Authentication Failures; A08 Software or Data Integrity Failures; A09 Security Logging and Alerting Failures; A10 Mishandling of Exceptional Conditions.

MÉTODO
1. Inventarie arquitetura, stack, manifestos, lockfiles, entradas, rotas, middlewares, autenticação, autorização, persistência, integrações, criptografia, logs, erros, CI/CD e deploy.
2. Mapeie fronteiras de confiança e fluxos: entrada → validação → transformação → operação sensível → saída.
3. Revise A01–A10. Para cada suspeita, siga o fluxo entre arquivos e procure controles compensatórios antes de concluir.
4. Faça uma segunda passagem buscando evidência que contradiga cada achado e consolide duplicatas pela causa raiz.
5. Classifique como: “Evidência observada”, “Risco provável” ou “Não verificável passivamente”.
6. Não alegue explorabilidade confirmada, não invente CVSS, versões ou comportamento de runtime.

EVIDÊNCIA
- Cite arquivo e linha exata sempre que possível.
- Use o menor trecho necessário.
- Nunca revele segredos: informe tipo/local e masque o valor.
- Dependência declarada não prova CVE. Sem advisory atual e scanner, marque “versão a verificar”.
- “Sem indício” significa apenas que nada foi encontrado nos arquivos revisados.

FORMATO
# Reconhecimento passivo de segurança

## 1. Resumo executivo
Escopo, stack, superfícies, contagem por severidade/confiança/status, três prioridades e limitações.

## 2. Mapa da aplicação
Tabela: componente | responsabilidade | entrada | operação sensível | controle | arquivos.

## 3. Achados priorizados
Para cada achado: ID e título; OWASP Axx:2025; severidade estimada; confiança; status; evidência arquivo:linha; fluxo de risco; precondições; impacto plausível; controle compensatório; recomendação defensiva sem implementá-la; validação segura posterior sem payload ofensivo.

## 4. Matriz OWASP Top 10:2025
Tabela: categoria | superfícies revisadas | achados | indício encontrado/sem indício/não avaliável | lacunas.

## 5. Controles positivos
Boas práticas observadas, sempre com evidência.

## 6. Hipóteses descartadas
Suspeitas descartadas e o controle que as invalidou.

## 7. Validação ativa recomendada
Checklist futuro para responsável autorizado e ambiente controlado. Não execute e não forneça exploração.

## 8. Cobertura
Arquivos/diretórios analisados, exclusões e motivos.

Conclua somente após cobrir A01–A10, buscar contradições, remover duplicatas, mascarar segredos e declarar limitações. Termine afirmando: esta é uma revisão estática de reconhecimento, não um pentest nem garantia de segurança.

Atue como analista de AppSec e realize uma revisão estritamente passiva, estática e somente leitura do repositório aberto no Codex.

OBJETIVO
Identificar e priorizar indícios de vulnerabilidades e controles ausentes com base no OWASP Top 10:2025. O resultado é reconhecimento para revisão humana, não exploração, pentest ativo, correção automática ou garantia de segurança.

ESCOPO E INSTRUÇÕES
- Leia primeiro todos os AGENTS.md aplicáveis e obedeça às instruções mais específicas.
- Restrinja-se aos arquivos existentes no workspace aberto.
- Preserve o worktree, inclusive mudanças não commitadas.
- Hosts, domínios, APIs, bancos, buckets, clouds e repositórios externos citados no código estão fora do escopo.
- Se faltar contexto do projeto, registre a lacuna. A consulta documental ao OWASP oficial continua permitida e obrigatória.

GUARDRAILS — SOMENTE LEITURA ESTÁTICA
- Apenas liste, localize, pesquise e leia arquivos. Prefira rg --files, rg e leitura direta.
- Não faça rede contra o alvo nem acesse DNS, HTTP(S), API, banco, cloud, registry ou Git remoto do projeto. A única exceção é consultar documentação pública oficial do OWASP conforme a seção FONTES OWASP OBRIGATÓRIAS.
- Não execute código nem comandos que carreguem código do projeto.
- Não rode aplicação, servidor, container, VM, banco, build, teste, linter, scanner, gerenciador de pacotes, script, hook, binário, PoC ou payload.
- Não instale ou atualize dependências.
- Não faça fuzzing, brute force, enumeração ativa, exploração, bypass ou autenticação.
- Não crie, edite, formate, mova ou apague arquivos. Não use apply_patch e não faça commit.
- Não leia fora do workspace nem procure credenciais na máquina.
- Se uma ação puder executar código, gerar tráfego ou alterar estado, não a realize; descreva-a apenas como validação futura autorizada.
- Entregue tudo na resposta final; não salve o relatório.
PARALELIZAÇÃO E SUBAGENTES
- Quando as ferramentas multiagente estiverem disponíveis e o repositório justificar a divisão, crie no máximo quatro subagentes explorer, simultaneamente. Para projeto pequeno ou busca simples, trabalhe diretamente: paralelização tem custo e não é meta por si só.
- Faça primeiro um inventário mínimo e dê a cada subagente escopo, caminhos e saída claramente delimitados. Todos herdam integralmente os guardrails SOMENTE LEITURA ESTÁTICA; não podem editar, executar código, acessar o alvo ou criar outros agentes. Podem consultar somente as fontes OWASP oficiais permitidas, referentes às suas categorias.
- Divida as frentes sem sobreposição primária: (1) A01 e A07 — acesso, identidade e autenticação; (2) A02, A04 e A09 — configuração, criptografia, logs e alertas; (3) A03 e A08 — cadeia de software, dependências e integridade; (4) A05, A06 e A10 — injeção, design e condições excepcionais.
- Instrua cada subagente a devolver somente um resumo estruturado: arquivos revisados, evidências arquivo:linha, referências OWASP oficiais, controles compensatórios, hipóteses descartadas, lacunas e achados candidatos com confiança. Não aceite conclusões sem evidência local.
- Espere os quatro resultados antes de continuar. O agente principal deve reabrir evidências de achados críticos/altos, resolver sobreposição entre categorias, consolidar duplicatas pela causa raiz e gerar uma única resposta final.
- Execute em paralelo buscas, listagens e leituras independentes quando isso reduzir latência. Mantenha sequenciais as etapas com dependência de dados.
- Se subagentes não estiverem disponíveis, execute as quatro frentes sequencialmente e registre isso em “Cobertura”.

FONTES OWASP OBRIGATÓRIAS
- Antes da análise, consulte a versão vigente do OWASP Top 10 e confirme categorias, nomes e orientação oficial.
- Use apenas fontes oficiais: top10.owasp.org, owasp.org, cheatsheetseries.owasp.org e wstg.owasp.org. O acesso é documental; nunca siga links para o alvo ou terceiros.
- Use o OWASP Secure Code Review Cheat Sheet como método principal de revisão estática; use o OWASP ASVS na versão estável vigente como catálogo de requisitos; use Cheat Sheets específicas para aprofundar cada categoria; use o Top 10 para classificação e comunicação.
- O WSTG pode complementar o reconhecimento, mas não execute procedimentos ativos. Converta-os apenas em pontos de inspeção estática ou itens de validação futura.
- Para cada achado, cite a página oficial e, quando aplicável, o identificador ASVS ou WSTG com versão. Não invente mapeamentos.
- Registre no relatório a data da consulta, versões encontradas e URLs oficiais utilizadas. Se a web estiver indisponível, prossiga com o conhecimento disponível, declare a limitação e não alegue conformidade integral ao OWASP.
OWASP TOP 10:2025
A01 Broken Access Control; A02 Security Misconfiguration; A03 Software Supply Chain Failures; A04 Cryptographic Failures; A05 Injection; A06 Insecure Design; A07 Authentication Failures; A08 Software or Data Integrity Failures; A09 Security Logging and Alerting Failures; A10 Mishandling of Exceptional Conditions.

PROCEDIMENTO
1. Inventarie stack, manifestos, lockfiles, módulos, entradas, rotas, middlewares, dados, autenticação/autorização, integrações, configuração, CI/CD e deploy.
2. Mapeie fronteiras de confiança: entrada → validação → transformação → operação sensível → saída.
3. Revise A01–A10 no código, configuração e infraestrutura como código.
4. Para cada suspeita, siga chamadas entre arquivos e procure middleware, políticas, wrappers, validações e controles compensatórios.
5. Faça uma passagem adversarial buscando evidência que invalide ou reduza o achado. Consolide duplicatas pela causa raiz.
6. Classifique como “Evidência observada”, “Risco provável” ou “Não verificável passivamente”.
7. Não trate ausência de evidência como segurança. Não alegue explorabilidade, invente CVSS ou presuma configuração externa.

EVIDÊNCIA
- Cite caminho relativo e linha exata sempre que possível.
- Mostre apenas o mínimo necessário.
- Nunca imprima segredo completo; informe tipo/local e masque o valor.
- Pacote declarado não prova vulnerabilidade. Sem advisory atualizado e validação, use “versão a verificar”, sem atribuir CVE.
- Severidade é estimativa qualitativa baseada em impacto plausível e precondições observáveis.

SAÍDA
# Reconhecimento passivo de segurança

## 1. Resumo executivo
Escopo, cobertura, stack, superfícies, contagem por severidade/confiança/status, três prioridades e limitações.

## 2. Mapa da aplicação
Tabela: componente | responsabilidade | entrada | operação sensível | controle | evidência.

## 3. Achados priorizados
Para cada achado: ID e título; OWASP Axx:2025; severidade estimada; confiança; status; evidência arquivo:linha; fluxo de risco; precondições; impacto plausível; controle compensatório; recomendação defensiva sem implementá-la; validação segura posterior sem payload ofensivo.

## 4. Matriz OWASP Top 10:2025
Tabela: categoria | superfícies revisadas | achados | indício encontrado/sem indício/não avaliável | lacunas.
Nota obrigatória: “Sem indício” não comprova ausência de vulnerabilidade.

## 5. Controles positivos
Boas práticas observadas, sempre com arquivo e linha.

## 6. Hipóteses descartadas
Suspeitas eliminadas após encontrar controle compensatório.

## 7. Backlog de validação autorizada
Verificações futuras que exigiriam execução, rede ou ambiente. Não execute nem forneça exploração.

## 8. Cobertura
Diretórios/arquivos revisados, exclusões, artefatos ignorados e lacunas.

Conclua somente após cobrir A01–A10, rastrear os achados entre arquivos, buscar contradições, remover duplicatas, mascarar segredos e declarar limitações. Termine afirmando: este resultado é reconhecimento estático e passivo, não um pentest nem certificação de segurança.