O Problema da Entrega: Escrevendo Relatórios de Bug que Sobrevivem aos Primeiros 90 Segundos de um Engenheiro de Triage

Gancho e Contexto

Você encontrou algo real. Passou horas — talvez dias — confirmando, testando casos extremos, verificando se não é uma informação conhecida ou uma duplicata. Você abre o editor de relatórios, descreve o que encontrou, cola a requisição, adiciona uma screenshot e envia. Três dias depois: Informativo. Obrigado pela sua contribuição. Ou pior, Não Aplicável. Fora do escopo.

A vulnerabilidade não falhou. O relatório é que falhou.

Este é o problema da entrega. No momento em que você clica enviar, você sai completamente da equação. Um engenheiro de triage — frequentemente trabalhando através de uma fila de dúzias de relatórios — pega seu trabalho e precisa reconstruir seu modelo mental do bug do zero. Ele nunca viu sua sessão. Ele não sabe do caso extremo que você notou. Ele não pode sentir o "opa, isto é grave" que você teve. Tudo o que ele tem é texto, screenshots, e quaisquer passos de reprodução que você se incomodou em incluir. A diferença entre um bug válido e um bug pago é, surpreendentemente frequentemente, o próprio relatório. Não o exploit. O documento.

Este artigo faz engenharia reversa no fluxo de trabalho do engenheiro de triage e ensina você a escrever relatórios que sobrevivem aos primeiros 90 segundos de escrutínio — relatórios que são triados rapidamente, escalados apropriadamente e pagos na severidade que merecem.

TL;DR

🎯 Um bom relatório de bug resolve o trabalho do engenheiro de triage para ele. Comece com impacto, não mecânica. Forneça um resumo de uma sentença, um caminho de reprodução claro, uma justificativa de severidade precisa e um PoC mínimo — não um romance. A estrutura reduz a carga cognitiva. A redução da carga cognitiva significa triage mais rápido, confiança maior e melhores resultados para seu bounty.

Fundações e Teoria

Por Que Triage É Difícil

Antes de poder escrever para um engenheiro de triage, você precisa entender o que esse papel realmente é. Triage em um programa de bug bounty maduro é um trabalho de filtragem operando sob pressão de tempo constante. Um único triador em um programa bem conhecido pode processar entre 20 e 80 relatórios em um dia ocupado, abrangendo classes de vulnerabilidades radicalmente diferentes, tipos de ativos e níveis de habilidade do repórter. A maioria dos relatórios recebidos é ruído: duplicatas, submissões fora do escopo, comportamento mal compreendido ou self-XSS sem impacto significativo.

Esse contexto molda o comportamento de leitura do engenheiro de triage. Ele não está lendo seu relatório com curiosidade fresca — ele está buscando sinais disqualificadores primeiro. Se algo parece uma submissão de baixo esforço no primeiro parágrafo, os recursos cognitivos são racionados. O relatório recebe um julgamento rápido. Isto não é malícia. É triage, literalmente — o termo médico para classificar pacientes por urgência quando recursos são limitados.

A Lacuna do Modelo Mental

Quando você encontrou o bug, construiu um modelo mental completo: o endpoint, o parâmetro, o comportamento, o fluxo de usuário afetado, o pior cenário e a cadeia de raciocínio que os conecta. Esse modelo vive inteiramente em sua cabeça. Seu relatório é a compressão com perda desse modelo em texto.

O engenheiro de triage tem que reconstruir seu modelo mental a partir dessa saída comprimida — frequentemente enquanto metade de sua atenção está no próximo item da fila. Toda sentença ambígua, todo passo pulado, toda afirmação de impacto vaga força ele a fazer uma suposição (que pode ser desfavorável para você) ou investir tempo adicional pedindo esclarecimentos (o que atrasa a resolução e sinaliza baixa qualidade de relatório).

Seu trabalho como repórter é minimizar o custo de reconstrução. Quanto mais seu relatório se aproximar de instanciar completamente seu modelo mental na cabeça de outra pessoa sem nenhuma ambiguidade, melhor seu resultado.

Onde Se Encaixa no Fluxo de Trabalho

A escrita de relatórios não é uma reflexão pós-exploração. Pertence à sua metodologia como uma fase de primeira classe, sentando-se entre Validação e Envio:

Reconhecimento → Teste → Exploração → Validação → [ESCRITA DE RELATÓRIO] → Envio → Acompanhamento

A maioria dos pesquisadores trata isso como uma tarefa de 10 minutos após o trabalho real estar pronto. Os pesquisadores que ganham consistentemente pagamentos Critical tratam como um exercício de artesanato de 30–60 minutos. O achado é a matéria-prima. O relatório é o produto.

Conceitos Principais em Profundidade

1. O Primeiro Parágrafo É Sua Carreira Inteira Nesse Relatório

Os primeiros 90 segundos de um engenheiro de triage em seu relatório são passados quase inteiramente no primeiro parágrafo — o resumo. Este não é o lugar para "construir até" a vulnerabilidade. Comece com o impacto, não a mecânica.

Resumo ruim:

Estava testando o endpoint /api/user/update e notei que o parâmetro email não estava sendo validado apropriadamente. Ao manipular a requisição, consegui alterar o endereço de email de outro usuário.

Resumo bom:

Escalação de privilégio horizontal não autenticada via o endpoint /api/user/update permite que qualquer atacante modifique o endereço de email de qualquer conta de usuário fornecendo o user_id da vítima. Isto contorna completamente a propriedade da conta e permite total takeover de conta sem autenticação prévia.

O resumo bom faz quatro coisas em duas sentenças: nomeia a classe de vulnerabilidade, identifica o componente afetado, indica a pré-condição do atacante e nomeia o impacto em termos simples. Um engenheiro de triage lendo essa segunda versão já sabe a faixa de severidade antes de ter lido um único passo de reprodução.

Pense em seu resumo como uma afirmação de tese. Tudo mais no relatório é evidência sustentando-a.

2. Passos de Reprodução São uma Receita — Não uma História

Os passos de reprodução são onde a maioria dos relatórios falha operacionalmente. O engenheiro de triage precisa reproduzir seu achado — seja para validá-lo ou para entregá-lo a um desenvolvedor com um caminho de repro claro. Os passos que pulam contexto assumido, referenciam "meu cookie de sessão" ou pulam navegação intermediária destroem a reprodutibilidade do relatório.

Escreva os passos de reprodução como se os estivesse escrevendo para uma pessoa tecnicamente competente que nunca usou a aplicação antes. Numere cada passo. Seja explícito sobre os tipos de conta necessários (autenticado vs. não autenticado, admin vs. usuário regular, duas contas necessárias, etc.). Inclua a requisição exata se a vulnerabilidade está em uma chamada API.

Estrutura viável mínima:

1. Crie duas contas: Conta A (atacante) e Conta B (vítima).
2. Faça login na Conta A e navegue para [URL].
3. Intercepte a seguinte requisição POST usando um proxy:
   POST /api/user/update HTTP/1.1
   Host: target.com
   ...
4. Modifique o parâmetro `user_id` de [ID da Conta A] para [ID da Conta B].
5. Encaminhe a requisição. Observe que a resposta confirma que o email da Conta B foi atualizado.
6. Faça login na Conta B. Observe que o email agora é controlado pela Conta A.

Note o formato: verbos imperativos, numerados, papéis da conta nomeados, observação esperada no final. O passo de observação esperada é crítico — ele diz ao triador qual é o "sucesso", então eles não ficam se perguntando se algo deu errado quando replicam.

3. Justificativa de Severidade Não É um Sentimento — Use CVSS ou OWASP

"Isto é crítico porque um atacante poderia fazer muito dano" não é um argumento de severidade. É uma afirmação. Engenheiros de triage e gerentes de programa aplicam frameworks — geralmente CVSS 3.1 ou o próprio rubric da plataforma — e seu relatório precisa mapear para esse framework, não argumentar contra ele emocionalmente.

Aprenda os quatro grupos de métricas base CVSS: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, Availability. Então declare explicitamente seu raciocínio:

Estimativa CVSS 3.1: 9.1 (Critical)

• Attack Vector: Network (explorável remotamente)
• Attack Complexity: Low (sem condições especiais)
• Privileges Required: None (não autenticado)
• User Interaction: None
• Scope: Changed (atacante ganha acesso à conta de outro usuário)
• Confidentiality: High / Integrity: High / Availability: None

Mesmo que o programa não use CVSS formalmente, esse nível de especificidade força o engenheiro de triage a se engajar com seu raciocínio ao invés de descartá-lo. Se discordarem de sua pontuação, precisam articular por quê — o que significa que a conversa acontece no nível certo de abstração.

4. Impacto Empresarial: Traduza para a Sala

Muitos programas de bug bounty encaminham achados de alta severidade a um gerente de programa que não é um engenheiro de segurança. Ele está fazendo decisões de recursos, overrides de severidade e aprovações de payout — e fazendo com uma lente não técnica. Um relatório que fala apenas em termos técnicos é rebaixado neste estágio, não porque a vulnerabilidade não seja real, mas porque o tomador de decisão não consegue defender o payout para sua liderança.

Adicione uma breve seção "Impacto Empresarial" abaixo de sua descrição técnica. Escreva em linguagem simples. Mapeie a vulnerabilidade para danos concretos e reconhecíveis:

Impacto Empresarial: Um atacante explorando essa vulnerabilidade poderia silenciosamente assumir qualquer conta de usuário na plataforma. De uma perspectiva de negócios, isto representa acesso não autorizado a dados financeiros de clientes, responsabilidade sob GDPR Article 32 por falha em proteger dados pessoais e potencial para fraude em larga escala. Reportado publicamente ou explorado antes da remediação, isto representaria risco significativo de reputação e regulatório.

Você não está sendo dramático. Está fazendo o trabalho de tradução que o gerente de programa teria que fazer a si mesmo. Fazê-lo para eles torna o caminho de escalação sem atrito.

5. Calibração do PoC: Script Mínimo vs. Cadeia de Exploit Completa

Há uma ideia falsa comum de que um PoC mais impressionante ganha um payout mais alto. Isto é às vezes verdade nas margens, mas mais frequentemente um PoC mínimo, limpo e legível é mais valioso para um engenheiro de triage do que uma cadeia de exploit complexa. Eis por quê: seu trabalho é validação, não ofensa. Eles precisam do sinal mais simples possível de que o bug é real.

Use um script PoC mínimo quando:

• O bug requer manipulação de requisição não óbvia
• A reprodução depende de timing, estado ou comportamento de token
• Uma requisição HTTP bruta sozinha é ambígua

Use uma cadeia de exploit completa quando:

• A severidade depende de chaining — ex., um stored XSS que só se torna Critical quando você demonstra levando a account takeover
• Você está argumentando para uma severidade mais alta do que o componente sozinho justificaria
• O programa explicitamente recompensa impacto demonstrado

Para PoCs em vídeo (Loom ou similar): use estes quando o bug envolve comportamento de UI, race conditions ou fluxos multi-passo que são difíceis de capturar em screenshots estáticas. Uma gravação de tela de 90 segundos narrada enquanto você reproduz os passos elimina ambiguidade completamente. Mantenha abaixo de 3 minutos. Mostre o estado antes e depois.

⚠️ Nunca inclua credenciais, PII ou dados exfiltrados de contas de usuários reais em seu PoC. Desfoque ou redaja qualquer coisa que não seja sua. Isto é tanto um requisito ético quanto um prático — relatórios contendo dados de usuários reais são colocados em quarentena, não triados.

Alternativas e Comparação

Diferentes contextos chamam por abordagens ajustadas:

O modo de falha comum em todos esses é otimizar para sua clareza ao invés de sua clareza. Você já entende o bug. Escreva para alguém que não entende.

Conclusões e Leitura Adicional

📚 Pontos chave:

• Comece com impacto. O parágrafo de resumo é sua única chance de uma primeira impressão. Faça uma tese, não um preâmbulo.
• Passos de reprodução são uma receita. Numere. Nomeie os papéis da conta. Declare o que "sucesso" parece ser.
• Ancore severidade a um framework. Raciocínio CVSS 3.1 não é opcional para achados high/critical — força a conversa em território produtivo.
• Traduza para stakeholders não técnicos. Uma seção de impacto empresarial não é enchimento — é o que consegue uma escalação aprovada por um gerente de programa que não consegue ler uma requisição HTTP.
• Combine a complexidade do seu PoC à necessidade de validação, não a impressão. Mínimo e reprodutível bate complexo e frágil.

Leitura Adicional:

• HackerOne Disclosure Guidelines — entenda o que plataformas realmente esperam
• CVSS 3.1 Specification Document — leia isto uma vez apropriadamente; mudará para sempre como você pontua achados
• Google Project Zero Bug Disclosure Posts — estude a estrutura de write-ups de vulnerabilidade de nível elite
• The Art of Software Security Assessment (Dowd, McDonald, Schuh) — para construir o vocabulário técnico que torna seus relatórios precisos
• Palestras públicas de Nahamsec sobre metodologia de bug bounty — perspectiva prática e fundamentada em comunidade sobre o ofício de reportagem

Os melhores pesquisadores nem sempre são os melhor pagos. Os pesquisadores melhor pagos são os que entendem que pesquisa de segurança tem dois produtos: o achado e o relatório. Encontrar o bug é o trabalho técnico. Escrever o relatório é o trabalho de comunicação. Ambos são habilidades. Ambos podem ser melhorados. E diferentemente de técnicas de exploração, escrita de relatórios é algo que você pode praticar em cada submissão, começando hoje.