Encontrar Bugs

Revise as alterações neste branch em busca de bugs, vulnerabilidades de segurança e problemas de qualidade de código.

Quando Usar

• Você precisa de uma revisão focada em bugs, problemas de segurança ou alterações de código arriscadas.
• A tarefa envolve auditar a diferença do branch atual em vez de implementar um novo comportamento.
• Você deseja um processo de revisão estruturado com verificação baseada em checklist contra os arquivos alterados.

Fase 1: Coleta Completa de Entradas

1. Estabeleça a base e a cabeça solicitadas como SHAs de commit verificados. Verifique o branch remoto/padrão, se necessário; não assuma que um branch local desatualizado está atualizado. Leia a diferença completa do branch com git diff "$BASE_SHA...$HEAD_SHA" --, usando refs validados em argumentos separados entre aspas. Inclua alterações preparadas e não preparadas quando estiverem no escopo; preserve o checkout.
2. Se a saída for truncada, leia cada arquivo alterado individualmente até ter visto cada linha alterada.
3. Liste todos os arquivos modificados neste branch antes de prosseguir.

Fase 2: Mapeamento da Superfície de Ataque

Para cada arquivo alterado, identifique e liste:

• Todas as entradas do usuário (parâmetros de requisição, cabeçalhos, corpo, componentes de URL)
• Todas as consultas ao banco de dados
• Todas as verificações de autenticação/autorização
• Todas as operações de sessão/estado
• Todas as chamadas externas
• Todas as operações criptográficas

Fase 3: Checklist de Segurança (verifique CADA item para CADA arquivo)

• Injeção: SQL, comando, template, injeção de cabeçalho
• XSS: Todas as saídas em templates devidamente escapadas?
• Autenticação: Verificações de autenticação em todas as operações protegidas?
• Autorização/IDOR: Controle de acesso verificado, não apenas autenticação?
• CSRF: Operações que alteram o estado protegidas?
• Condições de corrida: TOCTOU em algum padrão de leitura-depois-escrita?
• Sessão: Fixação, expiração, flags seguras?
• Criptografia: Aleatoriedade segura, algoritmos adequados, sem segredos em logs?
• Divulgação de informações: Mensagens de erro, logs, ataques de tempo?
• DoS: Operações ilimitadas, falta de limites de taxa, esgotamento de recursos?
• Lógica de negócios: Casos extremos, violações de máquina de estados, overflow numérico?

Fase 4: Verificação

Para cada problema potencial:

• Verifique se ele já está tratado em outro lugar no código alterado.
• Procure por testes existentes que cubram o cenário.
• Leia o contexto circundante para verificar se o problema é real.

Fase 5: Auditoria Pré-Conclusão

Antes de finalizar, você DEVE:

1. Listar cada arquivo que você revisou e confirmar que o leu completamente.
2. Listar cada item aplicável do checklist como uma descoberta, verificado dentro do escopo revisado, não aplicável ou não verificado; a ausência de uma descoberta não é prova de segurança.
3. Listar quaisquer áreas que você NÃO pôde verificar completamente e o porquê.
4. Somente então fornecer suas descobertas finais.

Formato de Saída

Priorize: vulnerabilidades de segurança > bugs > qualidade de código

Pule: problemas de estilo/formatação

Para cada problema:

• Arquivo:Linha - Breve descrição
• Severidade: Crítica/Alta/Média/Baixa
• Problema: O que está errado
• Evidência: Gatilho concreto, caminho alcançável e impacto observado ou raciocínio; a falta de testes por si só não prova um bug.
• Correção: Sugestão concreta
• Referências: OWASP, RFCs ou outros padrões, se aplicável.

Se você não encontrar nada significativo, diga isso - não invente problemas.

Para uma solicitação apenas de revisão, relate as descobertas sem alterar o código. Uma solicitação explícita combinada de revisão e correção autoriza reparos e verificações com escopo; preserve a distinção entre descobertas e correções concluídas.

Exemplo

Solicitação do usuário:

Revise a diferença do branch atual em busca de bugs reais, problemas de segurança e regressões, citando arquivos e linhas exatos.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente ao escopo descrito acima.
• Não trate a saída como um substituto para validação específica do ambiente, testes ou revisão especializada.
• Pare e peça esclarecimentos se as entradas necessárias, permissões, limites de segurança ou critérios de sucesso estiverem ausentes.