Resumo para quem tem 30 segundos
- Se o desenvolvedor precisa perguntar como reproduzir, o achado ainda não está pronto.
- Um finding acionável cabe em um ticket e aponta arquivo, rota ou configuração.
- Reteste automático fecha o ciclo e elimina discussão sobre o que foi realmente corrigido.
A maior perda de tempo em segurança de aplicação não está em achar a falha, está no caminho entre o relatório e o commit de correção. Relatórios escritos para auditoria viram fila parada. Relatórios escritos para engenharia viram merge request.
Anatomia de um finding que o dev aceita
- 1Título que descreve o efeito, não a categoria: prefira leitura de pedidos de outro cliente a IDOR.
- 2Local exato: rota, parâmetro, arquivo ou recurso de infraestrutura.
- 3Reprodução copiável: requisição completa, usuário usado e resposta esperada.
- 4Evidência do impacto: o dado que voltou, o estado que mudou, o acesso que foi obtido.
- 5Correção sugerida no vocabulário da stack do time, com alternativa se houver restrição.
- 6Critério de aceite objetivo para o reteste.
POST /api/v1/pedidos/8172/itens HTTP/1.1
Host: app.exemplo.com.br
Authorization: Bearer <token do usuário B>
Content-Type: application/json
{"produto_id": 41, "quantidade": 1}
# Esperado: 403. Observado: 201, item criado no pedido do usuário A.Uma falha, um ticket
Agrupar dez ocorrências da mesma classe em um único item parece eficiente e trava a correção. Agrupe por causa raiz quando o conserto é um só, e separe quando os donos são diferentes.
O que remover do relatório
- Páginas de metodologia genérica no meio dos achados.
- Capturas de tela ilegíveis substituindo requisição em texto.
- Severidade sem justificativa do contexto do ativo.
- Recomendações genéricas copiadas de guia de referência.
Fechando o ciclo
| Etapa | Responsável | Sinal de conclusão |
|---|---|---|
| Publicação do finding | Segurança ofensiva | Ticket criado com reprodução |
| Correção | Time dono do serviço | Deploy referenciando o ticket |
| Reteste | Automático | Mesma cadeia reexecutada sem sucesso |
| Encerramento | Segurança | Evidência de falha bloqueada anexada |
Relatório bom é aquele que o desenvolvedor lê uma vez, entende e resolve sem abrir uma reunião.