Bug bounty com IA: o gargalo é comprovar o achado, não gerar o relatório

O Google pausou seu Open Source Software Vulnerability Rewards Program em 01/10/2026 após um aumento significativo de submissões automatizadas.[9] Segundo a empresa, a grande maioria desses relatos não era válida.[9] A TechCrunch relaciona o problema à sobrecarga de engenheiros e mantenedores com descrições incorretas ou contendo alucinações.[9]

O problema de engenharia não está em produzir texto convincente. Está em separar uma hipótese de uma vulnerabilidade demonstrável antes de transferir o custo dessa separação para outra pessoa. Um relatório mais longo não é necessariamente uma evidência melhor.

O que muda para quem desenvolve

A notícia descreve a pausa do programa open source citado, não o encerramento de todos os programas de recompensas do Google.[9] A empresa prometeu uma atualização no primeiro trimestre de 2027, sem confirmar uma data de retomada.[9]

Minha leitura é que um fluxo de auditoria assistida por IA precisa de uma fronteira entre descoberta e submissão. O modelo pode sugerir um caminho suspeito. A equipe precisa verificar se esse caminho existe, se é alcançável nas condições descritas e se viola uma propriedade de segurança.

Essa distinção muda o que medir. Contar suspeitas geradas premia volume. Prefira acompanhar achados únicos confirmados, tempo de revisão e hipóteses descartadas com motivo. Não transforme uma chamada ao modelo em uma solicitação automática para o mantenedor investigar.

Também diferencie comportamento inesperado de impacto de segurança. Uma operação disponível a um administrador autorizado pode ser intencional. A pergunta é quem consegue executá-la, sob quais condições e qual fronteira foi atravessada sem permissão.

Como aplicar

Organize o fluxo em quatro estados: hipótese, reproduzido, impacto confirmado e pronto para revisão. Só avance quando houver evidência correspondente. Para cada candidato, registre versão afetada, pré-condições, caminho de execução, resultado observado e resultado esperado.

Como experimento, use uma aplicação de teste própria com papéis distintos de usuário. Peça à análise assistida para apontar uma possível falha de autorização. Antes de aceitar a conclusão, transforme a hipótese em um teste isolado que tente a operação com o papel indevido e compare com o papel autorizado.

Se a hipótese não se reproduzir, preserve o motivo do descarte. Se reproduzir, confirme que o resultado representa acesso indevido, não uma regra intencional. Acrescente um teste de regressão e verifique a correção nas mesmas condições. Esse exercício não exige atacar um serviço externo.

Antes de qualquer submissão, elimine duplicatas, confira o escopo autorizado e reduza o relatório ao que outra pessoa consegue revisar. Uma explicação útil mostra o elo entre entrada, execução e impacto. Não precisa repetir todas as especulações produzidas durante a investigação.

Cuidados e limites

A reportagem não informa uma contagem de submissões nem uma taxa precisa de falsos positivos.[9] Portanto, não use a expressão “grande maioria” para inventar um percentual ou comparar ferramentas.

A pausa também não demonstra que IA seja incapaz de encontrar vulnerabilidades reais.[9] Ela evidencia um problema de qualidade das submissões. Automatizar a descoberta pode ajudar; automatizar a transferência de suspeitas sem prova apenas muda quem paga pela incerteza. O critério de qualidade deve continuar sendo reprodução segura e impacto verificável.

Fonte

[9] Fonte: TechCrunch