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, a Google anunciou uma suspensão temporária das submissões de vulnerabilidades de produto no âmbito do seu Open Source Software Vulnerability Reward Program (OSS VRP). A empresa afirmou que publicará uma atualização detalhada até ao primeiro trimestre de 2027, mas a pausa continua em vigor apenas para o fluxo específico de vulnerabilidades de produto, não para todo o conjunto de programas de recompensas geridos pela Google.

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

A suspensão aplica‑se exclusivamente à categoria de vulnerabilidades de produto do OSS VRP. Outros programas de recompensas da Google, como o Cloud Vulnerability Reward Program, continuam a aceitar relatórios, e as submissões relacionadas com a cadeia de suprimentos de código aberto também permanecem inalteradas. As vulnerabilidades reportadas antes do corte de 1 de outubro continuam elegíveis, e determinadas falhas em repositórios do Google Cloud que afetam produtos Cloud ainda podem ser tratadas através do programa Cloud VRP separado.

A análise interna da Google vinculou a pausa a um “aumento significativo de submissões automatizadas e geradas por IA, a grande maioria das quais foi descrita como inválida”. O volume excessivo sobrecarregou os mantenedores de código aberto, que se viram a gastar tempo precioso a reproduzir e rejeitar relatórios que descreviam falhas imaginárias, inexplotáveis ou simplesmente inexistentes, em vez de corrigir problemas de segurança confirmados.

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 investigação de vulnerabilidades, permitindo que mais investigadores descubram defeitos reais. Contudo, a mesma diminuição de esforço eliminou uma barreira natural que anteriormente filtrava submissões de baixa qualidade. Ferramentas automatizadas podem agora produzir milhares de relatórios sintéticos com supervisão humana mínima, inflando o volume de ruído que os administradores do programa têm de triage.

• Scripts automatizados geram relatórios em grande escala
• Modelos de linguagem grande fabricam caminhos de código plausíveis mas falsos
• Investigadores podem submeter sem verificação manual
• Mantenedores têm de destinar tempo para reproduzir e rejeitar cada relatório

Muitos dos mantenedores de código aberto, que são voluntários, relataram que o influxo de relatórios inválidos desviou recursos do trabalho de segurança genuíno. O tempo gasto a reproduzir falhas imaginárias não só atrasou o desenvolvimento de patches como também aumentou o esgotamento entre os contribuidores da comunidade.

Resposta da Google e planos futuros

A Google esclareceu que a pausa é uma medida temporária enquanto reestrutura a parte afectada 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 aceitar submissões, provavelmente exigindo evidência reproduzível, impacto verificado e uma etapa de revisão humana antes de um relatório ser inserido na cadeia de recompensas.

TechCrunch e Tom’s Hardware associaram 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 a mesma cronologia e justificativa, mas quaisquer alegações adicionais sobre outros programas são atribuídas exclusivamente a esses meios.

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

A situação também sublinha a necessidade de melhor coordenação entre plataformas de recompensas e projectos de código aberto. Directrizes 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 ao mesmo tempo que preservam os benefícios de um ecossistema de bug‑bounty vibrante.

Para organizações de língua portuguesa que participam em programas de segurança de código aberto, a pausa implica ajustar os fluxos de gestão de vulnerabilidades. As equipas deverão prever um prazo de validação mais longo para relatórios de vulnerabilidades de produto submetidos ao OSS VRP da Google, priorizar submissões ricas em evidências e considerar canais alternativos — como o Cloud VRP ou a coordenação direta com os mantenedores dos projectos — para descobertas críticas. Na prática, isto traduz‑se num ritmo temporariamente reduzido de receção de incentivos por certas falhas de código aberto, mas também oferece a oportunidade de focar em divulgações de maior qualidade que podem ser tratadas mais rapidamente.