Cibersegurança e IA · Caso Google OSS VRP

O Google pausou as recompensas por falhas em software livre: relatórios demais para conferir

Publicado em 19/10/2026 · Última revisão: 19/10/2026 · Leitura de 10 a 12 minutos

Quando alguém encontra uma falha de segurança num software livre, o Google pagava uma recompensa por ela. Desde 1º de outubro, esse pagamento para falhas de produto está pausado. O motivo é uma curiosidade com consequência: ficou fácil demais mandar relatório, e conferir continua sendo trabalho de gente.

Em 30 segundos

Desde 01/10/2026, o Google não aceita novos relatórios de falhas de produto no OSS VRP, o programa de recompensas para software livre criado em agosto de 2022. A notícia veio a público em 05/10.
O motivo, segundo o Google (em publicação no X citada pela imprensa): um aumento significativo de envios automáticos, a grande maioria inválida. A tradução é nossa.
A pausa é temporária. O Google promete uma atualização no 1º trimestre de 2027. Seguem valendo os relatórios enviados antes de 01/10, os de cadeia de suprimentos, o Patch Rewards (até US$ 15 mil) e o Cloud VRP.
Leitura nossa: o custo de gerar um relatório despencou, e o custo de conferi-lo não. Quem confere é gente.
Decisão para os próximos 30 dias: quais componentes de código aberto sustentam os sistemas da empresa e quem acompanha os avisos de segurança deles?

O que aconteceu

Um programa de recompensas por falhas (bug bounty) funciona assim: uma empresa promete pagar a quem achar um defeito de segurança e avisá-la antes que um criminoso o explore. O OSS VRP (Open Source Software Vulnerability Reward Program) é a versão do Google para projetos de código aberto mantidos por ela. Foi lançado em agosto de 2022, com recompensas de US$ 100 a US$ 31.337.

Em 2025, segundo a BleepingComputer, o Google pagou um recorde de US$ 17,1 milhões a mais de 700 pesquisadores, somando todos os seus programas, 40% a mais que os US$ 12 milhões de 2024. Ou seja, o canal estava aquecido. Em outubro de 2026, uma parte dele foi pausada.

01/10/2026: o OSS VRP deixa de aceitar novos relatórios de falhas de produto. Relatórios enviados antes dessa data não são afetados.
05/10/2026: BleepingComputer e Help Net Security noticiam a pausa e citam a explicação do Google: "uma alta significativa de envios automáticos, a grande maioria sem validade".
Segue valendo: relatórios de cadeia de suprimentos (supply chain) do OSS VRP; o Patch Rewards, que paga até US$ 15 mil por melhorias de segurança em projetos abertos do Google; falhas em repositórios abertos do Google Cloud, que podem seguir pelo Cloud VRP; e os demais programas de recompensa do Google.
1º trimestre de 2027: prazo que o Google dá para uma atualização do programa.

Linha do tempo

Linha do tempo montada a partir das matérias citadas nas fontes. Intel e curl entram como contexto, sem ligação causal com o caso do Google.

O que se sabe e o que não se sabe

Confirmado nas matérias que citam o Google	Não se sabe, ou é leitura nossa
Pausa para falhas de produto no OSS VRP desde 01/10/2026.	Quantos relatórios chegaram e que fração era inválida: o Google não divulgou números.
Motivo declarado: aumento de envios automáticos, a grande maioria inválida.	Se esses envios foram gerados por IA. A imprensa fala em "lixo de IA" (AI slop), mas a palavra do Google é "automáticos".
Pausa temporária, com atualização prometida para o 1º trimestre de 2027.	Como o programa volta e se haverá novas regras de envio.
Patch Rewards, supply chain, Cloud VRP e relatórios anteriores a 01/10 seguem.	Se a pausa reduz de fato o número de falhas corrigidas. Não há dado.
curl encerrou seu bounty na HackerOne em janeiro de 2026 por relatórios de IA de baixa qualidade. A Intel retirou recompensas em dinheiro na Intigriti em meados de setembro.	O motivo da Intel: ela não explicou, e não dá para ligar o caso à IA.

Dois cuidados de leitura. (1) Lemos a explicação oficial por meio das matérias, que citam a publicação do Google no X. A página do programa não pôde ser lida por nós na íntegra, então tratamos o texto como citado, não como visto na origem. (2) "Envio automático" não quer dizer, necessariamente, "feito por IA". As matérias usam as duas ideias, mas o Google só diz "automático".

A conta que não fecha, em imagem

Esquema explicativo nosso. O Google não divulgou números de relatórios recebidos nem de inválidos.

Visão executiva: risco, ganho e decisão

Risco

Quem usa software livre perde, por ora, um canal que pagava gente para achar e avisar falhas nos projetos do Google. Como o prêmio some, é possível (inferência nossa) que parte dos pesquisadores leve os avisos a outros programas ou os deixe de enviar.
Quem tem seu próprio canal de recebimento de falhas, mesmo que só um e-mail de segurança, corre o mesmo risco em escala menor: encher a caixa de entrada e esconder o aviso que importa.

Ganho

O caso é um bom espelho. Um processo de triagem bem desenhado (quem lê, com que critério, em quanto tempo) vira vantagem de velocidade quando o volume sobe.
Exigir o mínimo no formulário de entrada (versão afetada, passos para reproduzir, prova de que a falha existe) reduz o ruído sem fechar a porta aos relatórios bons. Recomendação nossa, não prática confirmada do Google.

Decisão para os próximos 30 dias

Quais componentes de código aberto sustentam os nossos sistemas e quem responde por eles?
Quem acompanha os avisos de segurança desses componentes?
Se recebemos relatórios de falhas (de clientes, parceiros ou pesquisadores), quem lê e em quanto tempo responde?

Aplicação comercial: onde há receita, economia, vantagem ou risco de marca e contrato

Marca: uma empresa que promete recompensa e deixa a fila sem resposta perde credibilidade com quem pesquisa segurança. O Google, ao menos, informou a data em que dará notícias.
Contrato: quem compra ou vende software deve saber se o fornecedor mantém um canal para receber falhas e qual prazo de resposta promete. É uma pergunta simples de fazer numa renovação.
Economia: corrigir uma falha achada cedo costuma custar menos que tratar um incidente. É uma regra de bom senso e, aqui, sem número de fonte.

Visão operacional: processos, pessoas e rotinas

Responsável: um dono para o canal de segurança, com substituto.
Rotina de triagem: critérios escritos para separar relatório completo de relatório vazio, e resposta padrão para cada caso.
Amostragem: se parte da triagem for automática, alguém confere uma amostra do que foi descartado. É o mesmo cuidado do caso BeyondTrust, visto do outro lado: lá uma máquina fechou alertas verdadeiros; aqui uma máquina gera relatórios em excesso.
Limite de capacidade: saber quantos relatórios por semana o time consegue ler com qualidade, e o que fazer quando passa disso.

Visão de infraestrutura: nuvem, rede, servidores e dependências

Inventário de componentes: uma lista do que o sistema usa por baixo, incluindo bibliotecas de código aberto e suas versões. Esse tipo de lista é chamado de SBOM.
Dependências indiretas: um componente pode depender de outros. A falha pode estar no segundo ou terceiro nível.
Atualização: processo para aplicar correções de componentes abertos, com janela, teste e plano de volta.
Nuvem: o Cloud VRP segue valendo para repositórios abertos do Google Cloud. Quem usa esses componentes deve acompanhar os avisos do fornecedor.

Visão de segurança: prevenir, detectar e responder

Prevenir

Manter o inventário de componentes e escolher projetos com mantenedores ativos.
Quando fizer sentido, apoiar o projeto: o Patch Rewards do Google continua pagando por correções.

Detectar

Assinar os avisos de segurança dos componentes que a empresa usa.
Acompanhar anúncios de mudança nos programas de recompensa dos fornecedores. A pausa do Google é um desses sinais.

Responder

Ter um plano para quando uma falha for achada num componente aberto: quem avalia, quem atualiza, quem comunica.
Ter um plano B se o canal de recompensa de um fornecedor mudar ou parar.

Visão de tecnologia: como funciona por dentro

O caminho de um relatório

Um pesquisador acha um comportamento suspeito no código.
Escreve um relatório: o que acontece, em que versão, como reproduzir e qual o impacto.
A equipe de triagem tenta reproduzir. Se não consegue, o relatório volta ou é recusado.
Se a falha é real, recebe uma gravidade, uma correção e, no fim, a recompensa.

Onde a automação entra

Ferramentas automáticas e modelos de linguagem conseguem produzir textos que parecem relatórios completos, com nome de arquivo, trecho de código e explicação. O que nem sempre conseguem é provar que a falha existe e pode ser explorada. Para quem confere, um relatório que parece bom e não se sustenta custa quase o mesmo tempo que um bom. Esta é uma explicação geral nossa, coerente com o motivo que o Google deu, mas sem números dele.

Casos parecidos

Em janeiro de 2026, o curl, projeto de código aberto muito usado, encerrou seu programa de recompensas na HackerOne por relatórios de IA de baixa qualidade, segundo a BleepingComputer. Em meados de setembro, a Intel retirou as recompensas em dinheiro do seu programa na Intigriti, sem explicar o motivo. Para o caso da Intel não há base para ligar a decisão à IA.

Opinião: o mais interessante é a inversão. Durante anos, o problema de segurança era achar poucas falhas. Aqui, o problema é separar as poucas verdadeiras de uma enxurrada que se parece com elas.

Para o leitor comum: o que fazer hoje

Deixe as atualizações automáticas ligadas no celular, no computador e nos aplicativos. Muitas correções de falhas chegam por aí.
Baixe aplicativos só das lojas oficiais.
Lembre que boa parte dos aplicativos e sites usa peças de código aberto. Quando uma falha é achada, a correção chega pela atualização.

Termos desta matéria

Estes termos devem entrar no glossário do canal. Até a inclusão, ficam definidos aqui.

Programa de recompensas por falhas (bug bounty): Programa em que uma empresa paga quem encontra e comunica uma falha de segurança.
OSS VRP: Programa do Google que pagava por falhas em projetos de código aberto mantidos por ela. Desde 01/10/2026, não aceita novos relatórios de falhas de produto.
Software livre e código aberto: Programas cujo código pode ser lido, usado e alterado por outras pessoas, conforme a licença de cada projeto.
Triagem: Separar o que é grave, o que é ruído e o que precisa de mais informação, antes de agir.
Falso positivo: Aviso que parece uma falha, mas não é.
Cadeia de suprimentos de software (supply chain): O conjunto de componentes, ferramentas e fornecedores de que um software depende.
Patch Rewards: Programa do Google que paga, até US$ 15 mil, por melhorias de segurança em projetos abertos.
Cloud VRP: Programa de recompensas do Google Cloud.
SBOM: Lista dos componentes que compõem um software, com suas versões.

Fontes

Primárias

Google Bughunters, seção de segurança em código aberto (página dos programas): bughunters.google.com/open-source-security. Não conseguimos ler o aviso da pausa na íntegra; o texto oficial está citado nas matérias abaixo.

Jornalísticas

BleepingComputer, 05/10/2026: Google halts open-source bug bounty program amid AI spam surge
Help Net Security, 05/10/2026: AI slop submissions force Google to freeze its open-source bug bounty
Technews, 05/10/2026: Google suspends open source vulnerability reward program
Gigazine, 05/10/2026: Google froze open source bug bounty program

Discussões técnicas (contexto, não fonte de fatos)

Hacker News (news.ycombinator.com) e r/netsec (reddit.com/r/netsec) costumam debater o excesso de relatórios de baixa qualidade em programas de recompensa.

Conferência cruzada: onde as fontes divergem

Data de início: a BleepingComputer não dá a data exata da pausa e diz que relatórios enviados antes de 01/10 não são afetados. A Help Net Security e a Technews indicam 01/10/2026. Adotamos 01/10.
Cloud VRP: a BleepingComputer diz que falhas em repositórios abertos do Google Cloud podem seguir pelo Cloud VRP; a Help Net Security diz que alguns relatórios de certos repositórios podem seguir. Por isso usamos "podem".
Números: nenhuma fonte traz quantos relatórios chegaram nem quantos eram inválidos. Não usamos nenhum número sobre isso.

Pergunta final

Quando a IA produz mais do que dá para ler, quem decide o que importa? Responda no direct do Instagram @techtraduzida e conte como o seu time trata esse ponto. Se este conteúdo ajudou, siga o perfil, curta e compartilhe: isso ajuda a desenvolver e divulgar o canal.