Redação de Relatórios de Bugs de Alta Qualidade

Um relatório de alta qualidade passa pela triagem mais rapidamente, tem menos probabilidade de ser marcado como duplicado ou informativo, recebe uma avaliação precisa da gravidade e constrói sua reputação junto aos programas. Relatórios deficientes — mesmo quando tratam de falhas críticas — podem ser rejeitados ou ter seu valor subestimado.

Todo relatório de qualidade inclui: título da vulnerabilidade, avaliação da gravidade com justificativa baseada no CVSS, ativo afetado (URL/endpoint), descrição do problema, reprodução passo a passo, prova de conceito, avaliação do impacto e correção sugerida.

Um bom título é específico e informativo: "IDOR em /api/v2/users/{id} permite que qualquer usuário autenticado acesse dados privados do perfil" é melhor do que "Contorno da autorização". Inclua: o tipo de vulnerabilidade, o endpoint afetado e o impacto em uma única frase.

Escreva as etapas de reprodução de modo que um desenvolvedor júnior que nunca tenha visto essa falha consiga reproduzi-la. Numere cada etapa. Inclua as solicitações HTTP exatas (copiadas do Burp Suite). Inclua quaisquer pré-condições necessárias (tipo de conta, restrição geográfica e horário).

Inclua capturas de tela, gravações da tela ou capturas de solicitações e respostas HTTP do Burp Suite que comprovem a existência da vulnerabilidade. No caso de IDOR: mostre a Conta A acessando os dados da Conta B com a solicitação modificada e a resposta que exibe os dados de B.

Explique claramente o impacto para o negócio: "Um invasor pode acessar o nome completo, o e-mail, o número de telefone e o endereço de cobrança de qualquer usuário iterando pelos identificadores." Quantifique sempre que possível: "A tabela de usuários tem 2 milhões de registros, todos acessíveis." Relacione o impacto técnico ao risco para o negócio.

Muitos programas usam o CVSS 3.1 para classificar a gravidade. Aprenda as seis métricas básicas: AV (vetor de ataque), AC (complexidade), PR (privilégios necessários), UI (interação do usuário), S (escopo) e C/I/A (impacto). Calcular o CVSS com precisão demonstra conhecimento e acelera a triagem.

Erros comuns em relatórios: não anexar uma PoC, omitir pré-condições nas etapas de reprodução, subestimar o impacto (não diga "baixo" quando se trata de tomada de conta), apresentar vulnerabilidades teóricas sem comprovar que são exploráveis e enviar relatos duplicados sem verificar primeiro os relatórios divulgados.

Cole a solicitação e a resposta HTTP exatas (com os dados sensíveis ocultados — não inclua PII de outros usuários além do necessário). Use o recurso "Copiar como curl" do Burp Suite para fornecer um comando de reprodução de uma linha que os revisores possam executar imediatamente.

Responda prontamente às perguntas da triagem. Se pedirem esclarecimentos, forneça-os em 24 a 48 horas. Uma comunicação profissional e cortês constrói relacionamentos duradouros com as equipes de segurança e aumenta as chances de receber crédito pelo novo teste e recompensas adicionais.

Leia os relatórios mais bem avaliados nas páginas de divulgação do HackerOne e do Bugcrowd. Estude como pesquisadores de elite estruturam os relatórios, demonstram o impacto e encadeiam vulnerabilidades. Reproduza a formatação e a descrição do impacto deles em seus próprios envios.

Qual é o elemento mais importante que distingue um relatório de vulnerabilidade de alta qualidade de um relatório deficiente?

Relatórios de vulnerabilidades de alta qualidade combinam um título específico, etapas de reprodução claras, uma prova de conceito concreta, uma pontuação CVSS precisa e uma avaliação convincente do impacto para o negócio. Investir na qualidade do relatório maximiza as recompensas, constrói reputação e acelera a triagem pelas equipes de segurança.