IA e bug bounty: quando enviar fica barato e avaliar sai caro

Uma fintech recebe um alerta de possível acesso indevido a dados de clientes. O relato tem vocabulário técnico preciso e um trecho de código que parece demonstrar a falha. A equipe de segurança para o que está fazendo, investiga e descobre que o exemplo depende de uma condição que não existe no produto.

A cena é hipotética. A conta que ela ilustra, porém, merece atenção: a IA pode reduzir o esforço de produzir um relato sem diminuir o trabalho de verificá-lo. Quem envia ganha velocidade; quem recebe herda a investigação.

É por isso que contar submissões me parece uma medida ruim de sucesso para programas de recompensa por vulnerabilidades, os chamados bug bounties. Se preparar uma alegação custa pouco e descobrir se ela procede continua caro, premiar volume é incentivar a transferência de trabalho. O que deveria valer é a evidência que permite agir.

O raciocínio também se aplica a sugestões de código, denúncias em plataformas e chamados técnicos. Antes de comemorar o aumento da participação, convém perguntar quem está terminando o serviço que ficou por fazer.

O texto convence. A falha existe?

Um modelo de linguagem pode ajudar a escrever um relato com descrição de impacto e código de exemplo. Só que uma apresentação convincente não prova que o defeito existe. Essa distinção parece óbvia até um alerta grave chegar à caixa de entrada.

Do outro lado, alguém precisa reconstruir as condições descritas e testar o que foi enviado. Talvez encontre uma falha real. Talvez encontre um comportamento esperado ou uma configuração incompatível com o produto, mas só saberá depois de gastar tempo.

Usar IA para explicar uma descoberta é bem diferente de usá-la para dar aparência de descoberta a uma hipótese não testada. No primeiro caso, a ferramenta melhora a comunicação; no segundo, empurra a pesquisa para o destinatário.

Na fintech do exemplo, a suspeita de exposição de dados pode exigir atenção urgente mesmo com evidências frágeis. A equipe não pode simplesmente ignorar o alerta porque ele parece mal fundamentado. É nessa obrigação de conferir que a suposta economia de trabalho muda de mãos.

Texto produzido não equivale a problema resolvido. Às vezes, é só uma tarefa encaminhada a alguém que não concordou em recebê-la.

A fila também tem custo

Programas de recompensa procuram aproximar dois interesses: a organização quer encontrar falhas, e o pesquisador quer reconhecimento ou remuneração por uma descoberta válida. O acordo depende, contudo, de uma capacidade limitada de avaliação. A caixa de entrada não respeita o tamanho da equipe.

Quando fica mais fácil preparar relatos, um canal de resultados de pesquisa pode se tornar um depósito de possibilidades. Nem é preciso haver má-fé. Basta que o colaborador considere suficiente enviar uma hipótese plausível e espere que a organização faça o teste.

Em projetos de código aberto, essa conta pode cair sobre o mesmo mantenedor que precisa corrigir defeitos e publicar versões. A investigação improdutiva ocupa o tempo que poderia ser dedicado a uma correção. Receber mais colaboração, nessas condições, pode significar entregar menos.

Por isso, eu não trataria uma eventual suspensão temporária de relatos como prova automática de hostilidade aos pesquisadores. Ela poderia ser uma medida de contenção. Mas fechar a entrada sem rever o que tornou a fila insustentável apenas adia o problema.

Colocar outra IA na triagem tampouco resolve a questão por decreto. Ela pode organizar informações e ajudar a encontrar duplicatas, por exemplo. Ainda assim, se tomar uma explicação plausível por uma demonstração válida, repetirá o erro que deveria filtrar.

A diretoria vê atividade. A equipe vê retrabalho

Um gráfico de submissões em alta pode render uma boa apresentação para a diretoria. Para quem avalia os relatos, o mesmo gráfico pode representar uma semana perdida tentando reproduzir falhas que ninguém demonstrou.

Eu prefiro saber quanto esforço é necessário para chegar a uma decisão confiável. E se as vulnerabilidades relevantes estão sendo corrigidas ou esperando atrás de alegações frágeis. O número de mensagens recebidas diz pouco sobre essas duas coisas.

Esse critério muda o desenho do programa. Em vez de estimular qualquer participação, a organização passa a facilitar contribuições que tragam informação verificável. Um relato curto, com ambiente identificado e comportamento demonstrado, pode ser muito mais útil do que páginas de prosa técnica.

Há um limite nessa cobrança: exigir evidências não significa pedir que o pesquisador explore uma vulnerabilidade até causar dano. Aprofundar um teste pode ser invasivo ou contrariar as regras do programa. Deve haver espaço para demonstrar o risco sem acessar dados de terceiros.

Também discordo da ideia de usar o estilo do texto como filtro de qualidade. Um excelente pesquisador pode recorrer à IA para escrever em outro idioma ou explicar melhor o que encontrou. O critério é a relação entre alegação e evidência, não uma tentativa de adivinhar quem digitou cada frase.

A porta pode continuar aberta, mas precisa de regras

Restringir a participação a pesquisadores conhecidos parece uma saída simples. Pode reduzir ruído, mas também deixa de fora gente competente que ainda não construiu reputação. Para um brasileiro tentando contribuir com um programa internacional, instruções claras são mais justas do que prestígio como senha de entrada.

Um bom canal explica o que precisa receber para avaliar o caso. Pede que o pesquisador identifique o componente afetado e descreva as condições em que observou o problema, com uma demonstração mínima quando isso for possível e seguro. Também prevê o que fazer quando só a própria organização dispõe dos recursos necessários para reproduzir a falha.

Os incentivos precisam acompanhar essa exigência. Enviar variações superficiais da mesma hipótese não deveria trazer vantagem; melhorar uma evidência ou responder de forma útil às dúvidas da triagem deveria contar a favor do colaborador. Reconhecer os limites do que foi testado também é sinal de qualidade, não de fraqueza.

A organização, por sua vez, não pode cobrar precisão enquanto mantém um escopo ambíguo e documentação desatualizada. Respostas genéricas da triagem também geram retrabalho. A responsabilidade pela qualidade da troca existe dos dois lados.

A IA pode ajudar pesquisadores e avaliadores. O erro é celebrar a velocidade de quem envia sem contabilizar o esforço de quem recebe.

Se o seu programa recompensa quem ocupa a fila, em vez de quem ajuda a resolver um problema, talvez a produtividade anunciada seja só uma conta enviada ao mantenedor.

Fontes consultadas

Não foram disponibilizados links de fontes para consulta. A pauta mencionava uma reportagem atribuída ao TechCrunch sobre uma suposta suspensão de um programa do Google. Sem a reportagem ou uma manifestação da empresa, o episódio não pôde ser confirmado e foi retirado da análise.