Bug bounty não aguenta flood de IA

Bug bounty open source virou gargalo operacional no Google. O programa que pagava por vulnerabilidades em projetos abertos foi pausado porque a equipe não conseguia mais separar sinal de ruído. O motivo oficial foi um aumento significativo de submissões automatizadas, a grande maioria inválida. Na prática, isso significa fila cheia de reports gerados por IA, com formato perfeito, linguagem confiante e conteúdo vazio. Quem já triou vulnerabilidade sabe como isso dói: cada ticket ruim custa tempo de engenheiro sênior, que poderia estar corrigindo falha real.

O fato

O programa Open Source Software Vulnerability Rewards foi congelado em 1 de outubro, com promessa de atualização apenas no primeiro trimestre de 2027. É uma pausa longa, quase um ano e meio sem operação. Nesse intervalo, o Google orienta pesquisadores a focarem em outros programas de recompensa da empresa, que cobrem produtos como nuvem, Android e web. Ou seja, o open source ficou descoberto no modelo crowdsourced. Os mantenedores, muitos deles voluntários ou com time enxuto, foram os primeiros a sentir o impacto, com caixas de entrada lotadas de achados que não se sustentavam em teste manual.

Isso não foi surpresa para quem acompanha segurança. No ano passado já havia alerta de que 'AI slop' ia poluir programas de bug bounty. A previsão se confirmou. Relatos de engenheiros citam submissões com alucinações, cadeias de exploração impossíveis, PoCs que não compilam e descrições que misturam arquivos e versões diferentes. O padrão é conhecido: a IA lê o repositório, inventa uma condição de corrida ou um XSS teórico, monta um relatório bem escrito e dispara em massa. O custo para gerar é quase zero, o custo para refutar é alto. E quando o volume multiplica por mil, o sistema quebra.

Como funciona na visão de quem opera

Um programa de bug bounty open source opera como um funil com três etapas: ingestão, triagem e validação. Na ingestão, o pesquisador manda título, severidade, passos para reproduzir e impacto. Na triagem, alguém do time decide se vale investigar. Na validação, um engenheiro tenta reproduzir em ambiente controlado e define o pagamento pela tabela de severidade. O modelo assume escassez: poucos reports bons, alto valor por report. IA inverte essa lógica e cria abundância falsa. De repente você tem 10 mil tickets com CVSS alto alegado, todos urgentes no papel, nenhum reproduzível na prática.

Em termos de custo e latência, a conta é brutal. Suponha que um triador leve 20 a 40 minutos para descartar um falso positivo bem escrito, porque precisa checar código, versão, dependência e contexto. Multiplique por milhares de submissões por mês e você precisa de um time inteiro só para dizer 'não'. Sem telemetria automática, sem reprodução determinística, sem penalidade para quem envia lixo, o incentivo fica perverso. Quem usa IA para spammar não perde nada se errar, mas o mantenedor perde horas. É um ataque de negação de serviço contra atenção humana, mesmo sem intenção maliciosa direta.

Pela arquitetura, dá para inferir o que está acontecendo. A maioria desses agentes provavelmente combina varredura de repositório com LLM para gerar narrativa. Eles não executam fuzzer de verdade, não constroem ambiente, não provam exploitabilidade. Apenas correlacionam padrões como 'função usa memcpy' ou 'endpoint reflete input' e concluem vulnerabilidade. Falta o elo mais caro: prova de conceito executável, com container, commit hash, comando e output. Sem esse artefato, o report é só hipótese. E hipótese sem prova, em segurança, vale zero. O Google percebeu que ajustar threshold não bastava, era preciso pausar e redesenhar o funil.

O que isso muda na prática

Para quem caça bug de verdade, a pausa fecha uma fonte de renda e de reputação no open source. Para mantenedor, dá alívio imediato, mas cria ponto cego: vulnerabilidade real em biblioteca crítica pode demorar mais para aparecer sem o olhar externo. Para empresas que rodam programa próprio, o recado é direto. Se seu formulário aceita texto livre sem reprodução obrigatória, você será o próximo a inundar. O spam de IA não escolhe marca, escolhe processo frágil. Quem tem escopo amplo, pagamento por volume e triagem manual está mais exposto.

  • Exija PoC executável: só aceite report com repositório, commit, Dockerfile ou script que reproduz a falha em um comando.
  • Pontue reputação: priorize quem tem histórico de acerto e coloque novato com alta taxa de erro em fila lenta com validação automática.
  • Automatize o descarte: crie um bot que tenta compilar e rodar o PoC antes de acionar humano, e rejeite sem log de execução.

A ação prática para hoje é simples. Se você pesquisa vulnerabilidades com ajuda de IA, mude seu fluxo. Não envie o output direto do modelo. Rode localmente, grave tela ou log, fixe versão e mostre impacto real com leitura ou escrita fora do escopo permitido. Um report com 'testei no commit 9f3a2, com Python 3.11, e obtive RCE com este trace' passa na frente de cem teorias. Se você defende um programa, publique exemplos de report bom e ruim, com motivo da rejeição. Transparência educa mais que aumentar valor do bounty. E reduz drasticamente o retrabalho nas próximas rodadas.

A tensão real: escala ou só move o gargalo

Aqui fica a dúvida que ninguém quer admitir. Ferramentas de IA para achar bug vão melhorar, mas ferramentas para spammar melhoram mais rápido porque gerar é mais fácil que provar. Dá para criar filtro com IA para barrar IA, só que isso vira corrida armamentista com custo crescente dos dois lados. Vale a pena pagar engenheiro sênior para brigar com bot? Ou o modelo de bounty aberto, do jeito que existe hoje, simplesmente não escala em mundo de geração infinita. Talvez a saída seja menos crowdsourcing aberto e mais auditoria assistida, com agentes auditores rodando dentro do CI do projeto, com acesso a testes e poder de abrir PR, não só issue.

Conclusão

O Google não pausou o programa por falta de bugs, pausou por excesso de confiança automatizada sem prova. É um sintoma de um processo que foi desenhado para escassez humana e quebrou na abundância sintética. A pergunta que fica é incômoda: quantos outros programas só continuam abertos porque ainda não admitiram que a fila já é majoritariamente lixo?