Redação de Constatações

Um achado é a unidade de valor em um relatório de teste de invasão. Um bom achado é claro, respaldado por evidências e acionável.

O leitor deve entender o problema, acreditar que ele é real e saber o que fazer, tudo a partir de uma única entrada.

Use um modelo consistente para cada achado. A consistência gera confiança e torna os achados comparáveis.

Cada achado tem as mesmas seções fixas.

O título deve indicar a classe e a localização da vulnerabilidade em poucas palavras. É a primeira coisa que o leitor examina.

• Bom: Injeção de SQL no formulário de login
• Fraco: Problema no banco de dados

Seja específico, não vago.

A descrição explica qual é a falha e por que ela existe, em duas ou três frases. Considere um engenheiro competente que ainda não viu a falha.

Declare a causa raiz, não apenas o sintoma.

Liste as etapas para reproduzir de forma exata e numerada. Qualquer pessoa da equipe deve conseguir segui-las e ver o mesmo resultado.

Inclua a solicitação, a carga útil e a resposta observada.

O impacto responde à pergunta que todo executivo faz: e daí? Traduza a falha técnica em consequências para o negócio.

• Acesso completo de leitura ao banco de dados de usuários.
• Possibilidade de contornar a autenticação de qualquer conta.
• Possível violação de normas regulatórias.

Declare apenas o que você demonstrou. Se você não extraiu dados, diga que a falha permite a extração de dados, não que você extraiu registros.

Marque claramente as teorias não verificadas como potenciais, não confirmadas.

Anexe o mínimo de evidências necessário para provar o achado: um par de solicitação e resposta ou uma captura de tela anotada.

Oculte segredos e dados pessoais reais. As evidências geram credibilidade; evidências excessivas escondem o ponto principal.

Vincule cada achado a uma classificação reconhecida, como CWE ou os 10 principais da OWASP.

As referências permitem que o cliente pesquise o problema de forma independente e mostram que seu trabalho se baseia em padrões.

Use a voz ativa, frases curtas e nenhum jargão sem explicação. Defina uma sigla na primeira vez que a usar.

Lembre-se do público duplo: as linhas do resumo devem fazer sentido para um gerente, e as etapas devem atender às necessidades de um engenheiro.

Evite estes erros frequentes ao escrever achados.

• Copiar e colar a saída bruta da ferramenta de varredura como se fosse um achado.
• Não apresentar uma declaração clara de impacto.
• Fornecer etapas que não podem ser reproduzidas.
• Usar gravidade inconsistente para problemas semelhantes.

Verifique sua compreensão da redação de achados.

Você aprendeu a escrever achados claros e acionáveis.

• Use um modelo consistente para cada achado.
• Escreva títulos específicos, descrições da causa raiz e etapas numeradas para reprodução.
• Traduza as falhas em impacto para o negócio.
• Declare apenas o que demonstrou; oculte as informações confidenciais das evidências.
• Vincule os achados a referências de CWE e OWASP.

Em seguida, você aprenderá a fornecer orientações eficazes de correção.