Google suspende recompensas por bugs em vulnerabilidades de produtos de seu programa de segurança para projetos de código aberto após uma forte alta no volume de submissões automatizadas. A mudança entrou em vigor em 1º de outubro de 2026 e interrompe temporariamente a aceitação de novos relatórios de vulnerabilidades de produto pelo Open Source Software Vulnerability Reward Program (OSS VRP).
A decisão coloca em evidência um dos efeitos colaterais mais controversos da popularização da Inteligência Artificial na pesquisa de segurança. Modelos de linguagem podem ajudar pesquisadores a analisar grandes bases de código e identificar possíveis falhas, mas também conseguem produzir uma quantidade enorme de relatórios incorretos, especulativos ou sem impacto real. O próprio Google já havia endurecido as regras do OSS VRP em 2026 por causa do aumento de relatórios de baixa qualidade associados à IA.
A suspensão afeta projetos importantes mantidos pelo Google, incluindo Go, Angular, Flutter, Bazel e Protocol Buffers, mas não significa o encerramento completo do programa. Relatórios de comprometimento da cadeia de suprimentos continuam sendo aceitos, assim como submissões feitas antes de 1º de outubro.
O que mudou no programa de recompensas de código aberto do Google
O OSS VRP foi criado para incentivar pesquisadores a encontrar vulnerabilidades em projetos de código aberto mantidos pelo Google. A iniciativa cobre componentes amplamente utilizados por desenvolvedores e empresas, o que faz com que uma falha em um desses projetos possa ter impacto muito além dos produtos diretamente mantidos pela companhia.
A partir de 1º de outubro de 2026, porém, o Google deixou de aceitar novos relatórios classificados como vulnerabilidades de produto dentro do programa. A empresa afirma que a interrupção é temporária e pretende apresentar uma atualização sobre a reformulação do mecanismo no primeiro trimestre de 2027. Não existe, entretanto, uma data definida para a retomada dos pagamentos regulares.
A medida também precisa ser entendida no contexto das mudanças anteriores. Em março, o Google já havia aumentado as exigências de comprovação para determinadas categorias de vulnerabilidades, incluindo a necessidade de reproduções mais robustas ou de um patch incorporado ao projeto em alguns casos.
Google suspende recompensas por bugs de produto
A principal mudança está no componente financeiro do programa. Antes da suspensão, vulnerabilidades de produto podiam receber recompensas que começavam em US$ 101 e chegavam a US$ 7.500, dependendo da classificação do projeto e da natureza da falha. Atualmente, a tabela do programa não apresenta mais pagamentos para essa categoria.
Nos projetos classificados como Flagship, a faixa anterior chegava a US$ 7.500. Já projetos importantes tinham valores que começavam em US$ 101 e chegavam a US$ 3.133,70. A alteração, portanto, não representa simplesmente uma redução nos valores, mas uma suspensão da recompensa para novos relatórios de vulnerabilidades de produto.
Isso não significa que qualquer descoberta de segurança relacionada aos projetos do Google deixou de ter valor.
Os comprometimentos de cadeia de suprimentos continuam elegíveis a recompensas. Essa categoria inclui situações em que um invasor poderia alterar o código-fonte, comprometer processos de compilação ou adulterar pacotes distribuídos aos usuários. Também permanecem relevantes determinados casos de vazamento de credenciais com privilégios de escrita.
A diferença é importante porque esses problemas representam riscos sistêmicos. Uma vulnerabilidade comum pode afetar aplicações que utilizam determinado componente, enquanto uma falha na cadeia de fornecimento pode permitir que um atacante comprometa diretamente a distribuição do software.
Prazos e promessas de reestruturação
O Google não estabeleceu uma data para reabrir a categoria suspensa. A empresa se comprometeu apenas a apresentar uma atualização durante o primeiro trimestre de 2027, enquanto reformula esse aspecto do OSS VRP.
Também continuam válidos os relatórios enviados antes de 1º de outubro. Portanto, pesquisadores que já haviam apresentado vulnerabilidades antes da mudança não tiveram suas submissões automaticamente anuladas pela suspensão.
Esse detalhe mostra que o Google está tratando a decisão como uma pausa operacional e uma revisão do modelo, e não como o abandono da pesquisa de segurança em código aberto.
O papel da IA no colapso da triagem de vulnerabilidades
A explicação oficial para a suspensão é direta: houve um aumento significativo das submissões automatizadas, e a grande maioria delas não era válida. O anúncio de outubro não informa quantos relatórios foram recebidos nem afirma que todos foram produzidos por IA. No entanto, a decisão acontece depois de mudanças específicas feitas pelo Google para enfrentar o crescimento de relatórios gerados por modelos de linguagem.
O problema está menos na capacidade da IA de encontrar bugs e mais na facilidade com que ela pode gerar hipóteses de vulnerabilidade em escala.
Um LLM pode analisar uma função, identificar um possível estouro de memória e produzir uma explicação aparentemente convincente sobre como um atacante poderia explorá-la. O problema é que o modelo pode não compreender completamente o contexto da aplicação, os mecanismos de proteção existentes ou se aquele trecho de código é realmente alcançável em condições práticas.
O resultado pode ser um relatório tecnicamente sofisticado, mas que descreve uma vulnerabilidade inexistente.
Foi justamente esse comportamento que o Google destacou ao alterar o OSS VRP em março. A empresa relatou um aumento expressivo de relatórios gerados por IA que apresentavam informações incorretas, alucinações sobre exploração ou problemas que não tinham impacto de segurança significativo.
A situação chegou a afetar diretamente o projeto Go. Sua política de segurança passou a alertar pesquisadores para que não enviem relatórios produzidos por LLMs sem uma etapa adequada de revisão e curadoria humana. O projeto reconhece que esses modelos conseguem encontrar problemas reais, mas também podem produzir vulnerabilidades imaginárias ou transformar erros de implementação sem impacto em supostas falhas de segurança.
O ponto central é a triagem.
Para cada relatório inválido, uma equipe precisa gastar tempo verificando código, reproduzindo cenários, analisando impacto e determinando se existe realmente uma vulnerabilidade. Quando milhares de submissões são produzidas automaticamente, o custo passa a ser transferido do pesquisador para o mantenedor.
Isso cria uma situação paradoxal: uma tecnologia apresentada como ferramenta para aumentar a produtividade dos pesquisadores pode acabar reduzindo a capacidade operacional das equipes de segurança.
As rotas alternativas para pesquisadores e o futuro da segurança Open Source
A suspensão não fecha todas as portas para pesquisadores interessados em encontrar problemas nos projetos do Google.
Uma das alternativas é o Cloud VRP, que pode continuar aceitando determinadas vulnerabilidades em repositórios relacionados ao Google Cloud quando o problema afeta produtos da plataforma. O Google também recomenda que pesquisadores avaliem seus outros programas de recompensas para verificar se uma vulnerabilidade pode ser enquadrada em outra iniciativa.
Outra possibilidade é o Patch Rewards Program, voltado para recompensar correções de segurança em projetos elegíveis. Nesse modelo, o foco deixa de ser simplesmente apontar um problema e passa a ser entregar uma correção efetiva, aceita pelos mantenedores e submetida dentro das condições do programa. As recompensas podem chegar a US$ 15 mil, dependendo do caso.
Para pesquisadores do Go, também existe o canal próprio da equipe de segurança da linguagem. A política recomenda relatórios objetivos, com descrição da falha, explicação de como ela pode ser explorada e, quando possível, uma pequena reprodução do problema.
Ainda assim, existe uma questão mais delicada: o que acontece com pesquisadores legítimos que dependiam do OSS VRP como incentivo financeiro?
A suspensão pode reduzir temporariamente o interesse de alguns pesquisadores em analisar projetos do Google, especialmente aqueles que investem muitas horas em auditorias manuais. Por outro lado, manter o sistema aberto sem filtros poderia produzir um efeito ainda pior, com pesquisadores competindo contra uma avalanche de relatórios automatizados.
O desafio para 2027 será encontrar um meio-termo.
O futuro dos programas de bug bounty provavelmente dependerá de mecanismos capazes de diferenciar pesquisa assistida por IA de spam automatizado produzido sem validação. Exigir provas de conceito reproduzíveis, patches, testes automatizados e demonstrações concretas de impacto pode ser parte dessa solução.
A questão não deveria ser simplesmente proibir IA. Ferramentas baseadas em modelos de linguagem podem ser extremamente úteis na análise de código, geração de testes e investigação de comportamentos inesperados. O problema aparece quando a automação elimina justamente a etapa que continua sendo essencial: a validação humana do resultado.
Impacto na comunidade e o dilema do código aberto
A suspensão do Google mostra que o problema dos relatórios automatizados deixou de ser uma preocupação teórica. Ele já está afetando a operação de programas de segurança em larga escala.
Para o ecossistema Open Source, a situação é especialmente sensível. Projetos como Go, Angular, Flutter, Bazel e Protocol Buffers são utilizados por uma quantidade enorme de desenvolvedores e integram cadeias de software muito maiores. Reduzir o fluxo de pesquisas pode representar uma perda de oportunidades para encontrar vulnerabilidades reais, mas manter uma fila dominada por relatórios inválidos também consome recursos que poderiam ser usados para corrigir problemas importantes.
O caso também deixa uma lição importante para a comunidade de segurança: quantidade não é sinônimo de pesquisa de qualidade.
A IA pode acelerar a descoberta de candidatos a vulnerabilidade, mas transformar cada hipótese em um relatório sem reprodução, análise de impacto ou revisão humana apenas desloca o trabalho para quem precisa fazer a triagem.
O Google agora terá alguns meses para decidir como reconstruir esse equilíbrio. A atualização prometida para o primeiro trimestre de 2027 será particularmente importante para entender se o novo OSS VRP exigirá provas mais fortes, mudará o sistema de recompensas ou criará mecanismos específicos para lidar com submissões automatizadas.
No fim, o dilema é maior do que o programa de recompensas do Google. A mesma tecnologia que pode ajudar a proteger o software livre também pode inundar seus mantenedores com ruído. O desafio da próxima fase da segurança assistida por IA será descobrir como aproveitar sua capacidade de análise sem transformar velocidade em spam de vulnerabilidades.
