Google pausa programa de recompensas por vulnerabilidades em código aberto após aumento de relatórios gerados por IA

Em 1 de outubro de 2026, o Google anunciou uma interrupção temporária dos novos envios de vulnerabilidades de produtos dentro do seu Programa de Recompensas por Vulnerabilidades em Software de Código Aberto (OSS VRP). A empresa afirmou que publicará uma atualização detalhada até o primeiro trimestre de 2027, mas a pausa permanece em vigor apenas para a categoria de vulnerabilidade de produto, não para todo o conjunto de programas de recompensas geridos pelo Google.

O que a pausa cobre e o que não cobre

A suspensão aplica‑se exclusivamente à categoria de vulnerabilidade de produto do OSS VRP. Outros programas de recompensas do Google, como o Cloud Vulnerability Reward Program, continuam aceitando relatos, e as submissões de cadeia de suprimentos de código aberto também permanecem intactas. Vulnerabilidades relatadas antes do corte de 1 de outubro continuam elegíveis, e certas falhas em repositórios do Google Cloud que afetam produtos Cloud ainda podem ser tratadas através do programa separado de recompensas Cloud.

A análise interna do Google vinculou a pausa a um “aumento significativo de envios automatizados e gerados por IA, a grande maioria dos quais foi descrita como inválida”. O surto sobrecarregou os mantenedores de código aberto, que se viram gastando tempo valioso reproduzindo e rejeitando relatos que descreviam falhas imaginárias, não exploráveis ou simplesmente inexistentes, em vez de corrigir questões de segurança confirmadas.

Por que o ruído gerado por IA se tornou um problema

A redução do custo de varredura e geração de relatórios democratizou a pesquisa de vulnerabilidades, permitindo que mais pesquisadores descubram defeitos reais. Contudo, a mesma diminuição de esforço também eliminou uma barreira natural que antes filtrava envios de baixa qualidade. Ferramentas automatizadas agora podem produzir milhares de relatórios sintéticos com supervisão humana mínima, inflando o volume de ruído que os administradores do programa precisam triagear.

• Scripts automatizados geram relatórios em escala
• Modelos de linguagem grande criam caminhos de código plausíveis, mas falsos
• Pesquisadores podem submeter sem verificação manual
• Mantenedores precisam dedicar tempo para reproduzir e rejeitar cada relatório

Mantenedores de código aberto, muitos deles voluntários, relataram que o influxo de relatórios inválidos desviou recursos do trabalho de segurança genuíno. O tempo gasto reproduzindo falhas imaginárias não apenas atrasou o desenvolvimento de patches, mas também aumentou o esgotamento entre os colaboradores da comunidade.

Resposta do Google e planos futuros

O Google esclareceu que a pausa é uma medida temporária enquanto reestrutura a parte afetada do OSS VRP. A empresa ainda não divulgou novas regras de validação, mas enfatizou que o programa não será encerrado permanentemente. Em vez disso, pretende introduzir critérios mais rigorosos para aceitação de envios, possivelmente exigindo evidências reproduzíveis, impacto verificado e uma etapa de revisão humana antes que um relatório entre no fluxo de recompensas.

TechCrunch e Tom’s Hardware relacionaram a decisão a um desafio mais amplo enfrentado por Linux e outros ecossistemas de código aberto, onde os mantenedores estão cada vez mais sobrecarregados por relatórios de baixa qualidade. Ambas as publicações relataram o mesmo cronograma e justificativa, mas quaisquer alegações adicionais sobre outros programas são atribuídas exclusivamente a esses veículos.

Para equipes de segurança que dependem de divulgações externas de vulnerabilidades, a pausa serve como lembrete para reforçar processos internos de triagem. Exigir evidências reproduzíveis, declarações claras de impacto e revisão manual antes de abrir um ticket pode ajudar a filtrar o ruído gerado por IA e proteger analistas de perseguir ameaças fantasma.

A situação também evidencia a necessidade de melhor coordenação entre plataformas de recompensas e projetos de código aberto. Diretrizes claras sobre o que constitui um relatório válido, combinadas com pré‑triagem automatizada que sinalize possíveis alucinações, poderiam reduzir a carga sobre os mantenedores enquanto preservam os benefícios de um ecossistema vibrante de bounty.

Para organizações brasileiras que participam de programas de segurança de código aberto, a pausa significa ajustar fluxos de trabalho de gerenciamento de vulnerabilidades. As equipes devem antecipar um período de validação mais longo para relatórios de vulnerabilidade de produto enviados ao OSS VRP do Google, priorizar envios ricos em evidências e considerar canais alternativos — como o Cloud VRP ou a coordenação direta com mantenedores de projetos — para descobertas críticas. Na prática, isso se traduz em uma desaceleração temporária na obtenção de incentivos por bugs de código aberto, mas também abre oportunidade para focar em divulgações de alta qualidade que podem ser tratadas mais rapidamente.