Google pausa bug bounty de open source após alta de relatórios gerados por IA

O que aconteceu

O Google pausou, a partir de 1º de outubro de 2026, o seu Open Source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → Software Vulnerability Rewards Program (OSS VRP), o bug bounty voltado a falhas de segurança em projetos de código aberto mantidos ou usados pela empresa. O anúncio foi feito em posts no X e na página oficial do programa, conforme reportou o TechCrunch. A promessa é dar uma atualização sobre o futuro do programa só no primeiro trimestre de 2027.

A justificativa é direta: volume desproporcional de submissões automatizadas, a maioria sem validade.

Esta pausa se deve a um aumento significativo de submissões automatizadas, das quais a grande maioria não é válida.

This pause is due to a significant rise in automated submissions, the vast majority of which are not valid.Google, em comunicado no X e no site do programa

Segundo o TechCrunch, que cita reportagem do Tom's Hardware, engenheiros do Google e mantenedores de projetos open source estavam sendo soterrados por relatórios inválidos ou com alucinações, ou seja, descrições de vulnerabilidades que simplesmente não existem no código analisado.

O aviso que já vinha de 2025

Esse colapso não surgiu do nada. Já em 2025, o próprio TechCrunch havia reportado que especialistas em cibersegurança↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → alertavam para o risco do "AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → slop" (lixo gerado por IA) sobre programas de bug bounty. A lógica é simples de entender: ferramentas de IA generativa baratearam a produção de texto técnico plausível, mas não garantem que o conteúdo técnico seja correto.

Um agente de IA pode ler um repositório, gerar uma hipótese de vulnerabilidade com aparência de relatório profissional, citar linhas de código reais e até sugerir um CVE, sem que exista de fato uma falha explorável ali. Para quem recebe esses relatórios, cada um precisa ser triado manualmente antes de ser descartado, o que consome o mesmo tempo de um relatório legítimo, só que sem o mesmo retorno.

Por que isso pesa mais sobre open source

Programas de bug bounty corporativos fechados, como os de produtos proprietários, normalmente têm equipes de segurança dedicadas e processos de triagem mais maduros. Já o OSS VRP do Google premia achados em projetos de código aberto que a empresa usa ou mantém, muitos deles com manutenção enxuta e dependente de poucas pessoas.

Isso cria uma assimetria importante:

• Empresas grandes conseguem pausar o programa, redirecionar pesquisadores para outras iniciativas e esperar o cenário amadurecer.
• Mantenedores independentes de bibliotecas e frameworks open source, que não têm bounty próprio nem equipe de triagem, continuam expostos ao mesmo tipo de submissão automatizada, só que sem a opção de "pausar" nada, porque muitas vezes recebem esses relatórios por e-mail, issue no GitHub ou formulário de divulgação responsável.

Na prática, o episódio do Google funciona como um sinal de alerta amplificado para quem cuida de projeto aberto no Brasil ou em qualquer lugar: a enxurrada de relatórios gerados por IA não é um problema exclusivo de big tech, é um problema estrutural de qualquer canal de divulgação de vulnerabilidade que aceita submissão externa.

O que muda na prática para quem mantém projeto aberto

Para times que rodam ou pensam em rodar programas de recompensa por bugs em repositórios próprios, o caso do Google reforça algumas decisões que já vinham sendo discutidas no setor:

1. Exigir prova de conceito reproduzível: relatório sem passo a passo que de fato explore a falha vira descarte automático mais rápido.
2. Triagem em camadas: uma primeira análise automatizada (inclusive com IA) para filtrar duplicatas e padrões óbvios de alucinação, antes de chegar a um humano.
3. Taxa de entrada ou reputação mínima: algumas plataformas de bug bounty já discutem cobrar um filtro de reputação do pesquisador para reduzir o volume de submissões de baixa qualidade.
4. Comunicação clara de critérios de validade: deixar explícito, no README de divulgação de segurança, o que conta como relatório aceitável evita parte do ruído gerado por quem só está testando se um agente de IA consegue "achar" uma falha.

Nenhuma dessas medidas resolve o problema de raiz, que é a facilidade de gerar relatórios plausíveis em escala. Mas reduzem o custo de triagem, que foi exatamente o ponto de ruptura citado pelo Google.

O que ainda está em aberto

O Google não detalhou publicamente que mudanças estruturais planeja fazer até a atualização prometida para o primeiro trimestre de 2027. Não há, pelas fontes disponíveis, número oficial de quantos relatórios foram recebidos nem qual a proporção exata de submissões inválidas, apenas a caracterização de "grande maioria".

Enquanto o OSS VRP está parado, a empresa orienta pesquisadores a considerar seus outros programas de bug bounty, que seguem ativos. Para a comunidade de segurança e para mantenedores de projetos abertos, o episódio deixa uma pergunta sem resposta pronta: se até o Google, com toda a capacidade de triagem e infraestrutura que tem, precisou congelar um programa inteiro por causa do volume de relatórios gerados por IA, o que resta para o mantenedor de um projeto pequeno que não tem esse músculo?

Fonte: TechCrunch