Escrever relatórios de bug bounty com IA

Um bug não vale nada até outra pessoa conseguir reproduzi-lo e ver o impacto. O relatório é onde isso acontece, e é a etapa que iniciantes apressam. Um modelo rascunha um relatório limpo das suas notas em segundos, o que é útil, desde que você confira cada linha antes de sair. Este post fecha a trilha que começou com o loop. Para o básico de escrever relatório, como escrever o seu primeiro relatório de segurança combina bem com isto.

#O que um triager precisa

Um triager lê muitos relatórios e reproduz os que são claros. Dê a ele um título curto que nomeia o bug e o alvo, passos exatos que ele consegue seguir, o request e a response que provam, e uma afirmação simples de impacto. Faça com que ele consiga colar os seus passos e ver o mesmo resultado. Um relatório que faz o leitor adivinhar é fechado ou devolvido por mais detalhe.

#As partes de um relatório

Parte	O que entra nela
Título	A classe do bug e o alvo afetado
Resumo	Uma ou duas frases sobre o quê e por que importa
Passos	Numerados, exatos, reproduzíveis a partir de um estado limpo
Evidência	O request e a response, capturas onde ajudam
Impacto	O que um atacante ganha, dito de forma simples
Correção	Uma sugestão curta e honesta quando você tiver uma

#Rascunhe das suas notas com o modelo

Se você manteve notas pelo loop, você tem a matéria-prima. Dê ao modelo o request, a response e o que o bug deixa um atacante fazer, e peça um relatório na estrutura acima. O modelo é bom em virar notas cruas em prosa limpa e passos consistentes. Dê a ele fatos, não um chute sobre severidade, e diga para deixar um placeholder onde faltar um detalhe, para ele escrever uma lacuna em vez de inventar uma.

#Classifique a severidade com honestidade

A severidade decide a faixa de recompensa, então a tentação de inflá-la é real, e triagers percebem rápido. Classifique o que você provou, não o que poderia ser possível. A Bugcrowd Vulnerability Rating Taxonomy mapeia classes de bug para severidades, e o CVSS da FIRST dá uma nota com um vetor documentado. Um modelo pode propor um vetor CVSS, e você confere cada métrica contra o que de fato demonstrou. Um medium honesto vence um high exagerado que é rebaixado e te marca como alguém que exagera.

#Confira cada linha antes de enviar

Esta é a mesma regra em que a trilha inteira roda. Leia o rascunho do modelo contra a sua evidência. Cada passo funciona a partir de um estado limpo? Toda URL e parâmetro estão corretos? O impacto bate com o que você provou, sem nada acrescentado para efeito? Passe pelos seus próprios passos mais uma vez no alvo, exatamente como escritos, e corrija o que não reproduz. O relatório tem que ser verdadeiro, porque o triager vai rodá-lo.

#O que não deixar o modelo fazer

Não deixe o modelo escrever um impacto que não sustenta, nomear um CVE do qual não tem certeza, ou descrever um passo que você não executou. Esses são os erros que um modelo fluente comete tentando ser útil, e cada um te custa credibilidade com o programa. Mantenha dados de programa e de usuário fora do rascunho além do mínimo para mostrar o bug, e mantenha o relatório fora de serviços públicos até o programa ter corrigido o problema e concordado com a divulgação. Os termos da disclose.io descrevem divulgação de boa-fé.

#Envie, depois acompanhe

Mande o relatório pelo canal do programa, responda perguntas rápido, e acrescente detalhe se o triager pedir. Se o bug for rebaixado, leia o porquê antes de discutir, porque o triager costuma ter contexto que você não tem. Um acompanhamento calmo e preciso constrói o histórico que rende convites privados depois.

#O fim da trilha, e o começo do loop

Você leu um escopo, mapeou uma superfície, testou e confirmou bugs, montou um agente para acelerar as partes chatas, e escreveu um relatório. Esse é o loop inteiro. Rode de novo no próximo alvo. Mantenha o OWASP Web Security Testing Guide e o caso de uso de bug bounty abertos, e comece a próxima passada por o loop.