Um programa de recompensas que deixou de aceitar relatórios
A Google deixou de aceitar novos relatórios de vulnerabilidades de produto através do seu Open Source Software Vulnerability Reward Program, e a razão que apresenta é o volume de submissões escritas por máquinas que chegam ao programa. A suspensão entrou em vigor a 1 de outubro de 2026. A Google não indicou data para reabrir, dizendo apenas que dará uma atualização no primeiro trimestre de 2027.
A empresa atribuiu a decisão a “um aumento significativo de submissões automatizadas, a grande maioria das quais não é válida”, segundo o aviso do programa noticiado pela Help Net Security. O programa cobre vulnerabilidades no software de código aberto da própria Google, incluindo projetos como Go, Angular e Protocol Buffers, que sustentam uma enorme quantidade de software que a Google não controla.
É um programa de recompensas que desiste de pagar para que alguém olhe. É essa a parte que importa: o estrangulamento já não está na oferta de pessoas dispostas a caçar falhas, mas na capacidade dos engenheiros que têm de ler o que entra.
O que continua no âmbito
A suspensão é mais estreita do que um encerramento. Os relatórios submetidos antes de 1 de outubro não são afetados e continuarão a ser processados. Os relatórios sobre a cadeia de fornecimento dirigidos ao mesmo programa — a categoria que cobre como o código aberto da Google é construído e distribuído, e não o que o próprio código faz de errado — continuam a ser aceites. Algumas vulnerabilidades de produto que afetam repositórios do Google Cloud podem ainda ser submetidas através do Cloud Vulnerability Reward Program, de acordo com a informação publicada.
Os investigadores que encontrarem algo neste intervalo são encaminhados para o Patch Rewards Program da Google, que paga melhorias de segurança em vez da descoberta de uma falha concreta. É uma proposta diferente. Uma recompensa por correção exige que o investigador faça também o trabalho de engenharia, o que filtra precisamente as submissões que a Google diz estarem a inundá-la — mas também eleva a fasquia para quem fazia o trabalho como devia.
Uma queixa que o ecossistema já vinha fazendo
A Google não é a primeira mantenedora a dizê-lo em voz alta. O padrão — relatórios longos, confiantes e bem escritos a descrever vulnerabilidades que não existem — está documentado em projetos de código aberto há cerca de dois anos, e o projeto curl e a Linux Foundation estão entre os que descrevem o mesmo desgaste do tempo de revisão. O que é novo é o tamanho da organização que age e a franqueza do remédio.
A economia não perdoa. Gerar hoje um relatório de vulnerabilidade plausível custa quase nada e refutá-lo continua a custar tempo real a um engenheiro humano. Qualquer programa que pague por achado válido está exposto a essa assimetria, e um programa que não consegue triar mais depressa do que os relatórios chegam só tem duas saídas: contratar ou fechar a porta.
Quanto isto custa
O custo não se vê de fora, porque nada se parte. Os projetos de código aberto da Google não ficam menos seguros no dia em que o formulário deixa de aceitar submissões. O que muda é o ritmo a que falhas reais são encontradas por pessoas fora da empresa, em código do qual milhares de outras organizações dependem e que poucas auditam por si.
Resta ver se a prometida atualização do primeiro trimestre de 2027 reabre o programa com um filtro, uma taxa, uma exigência de reputação ou outra coisa. As recompensas por falhas foram construídas sobre o pressuposto de que as submissões eram caras de produzir e baratas de verificar. Esse pressuposto inverteu-se, e a Google é o maior operador a admiti-lo em público.
