Google pausa programa de recompensas open source após onda de envios automatizados

O Google suspendeu em 1º de outubro de 2026 as novas submissões do seu programa de recompensas para vulnerabilidades em projetos open source, o OSS VRP, após uma alta de envios automatizados — em sua maioria inválidos. A pausa vai até uma atualização prometida para o primeiro trimestre de 2027. Para mantenedores, a decisão torna explícito um problema que já vinha crescendo: IA pode ampliar a descoberta de falhas, mas também pode transferir para equipes pequenas o custo de revisar relatórios plausíveis, longos e errados.

O que foi suspenso — e o que continua funcionando

O Open Source Software Vulnerability Reward Program recompensa pesquisadores que reportam vulnerabilidades em projetos open source mantidos pelo Google, incluindo exemplos como Go, Angular e Fuchsia. Segundo as regras atualizadas do programa, as novas submissões ficaram pausadas a partir de 1º de outubro. O Google informou que a causa é uma “alta significativa” de submissões automatizadas, cuja grande maioria não é válida.

Não se trata de uma interrupção geral dos programas de recompensa da empresa. Pesquisadores continuam podendo recorrer a outros programas do Google, e a suspensão não significa que falhas em software aberto deixaram de merecer comunicação responsável. O ponto específico é o canal e o fluxo de triagem do OSS VRP: o volume recebido deixou de ser administrável nas condições atuais.

Essa distinção importa. Um programa de bug bounty é uma interface operacional entre quem encontra uma possível falha e quem precisa verificar, reproduzir, corrigir e coordenar a divulgação. Quando a entrada cresce mais rápido que a capacidade de validação, até relatos bem-intencionados perdem prioridade no meio do ruído.

Por que relatórios gerados com IA sobrecarregam a segurança

Modelos de linguagem conseguem ler código, formular hipóteses e produzir relatórios com linguagem técnica convincente. Isso reduz a barreira para descrever uma vulnerabilidade, mas não garante que exista uma condição explorável, que ela esteja no escopo do projeto ou que a versão afetada seja real. Em segurança, essas são justamente as perguntas que exigem mais trabalho humano.

Um relatório útil normalmente apresenta componente e versão afetados, passos de reprodução, impacto demonstrável, evidência de explorabilidade e, quando possível, um teste ou correção. Um texto automático pode imitar essa estrutura sem conseguir executar o código ou comprovar a cadeia de ataque. O resultado é um falso positivo que parece mais completo do que é — e que consome tempo de engenheiros e mantenedores antes de ser descartado.

O Google já vinha alterando seus programas de recompensa para a era da IA. Em abril de 2026, a empresa explicou que os programas de Android e Chrome passariam a priorizar evidência concreta de bugs e achados menos acessíveis a automação. A justificativa foi direta: a IA tornou simples criar relatórios extensos, enquanto as ferramentas internas também passaram a automatizar parte da explicação e das sugestões de correção. A consequência é uma mudança de incentivo: volume de texto não substitui prova técnica.

O contraste: automação para encontrar falhas e automação para criar ruído

O problema não é que IA seja incompatível com pesquisa de segurança. O próprio Google tem investido no uso de automação para encontrar e corrigir falhas. Em iniciativas ligadas ao OSS-Fuzz e ao CodeMender, a empresa descreve uma cadeia na qual um problema encontrado é analisado, recebe uma correção candidata, passa por testes e é revisado antes de chegar ao mantenedor.

A diferença está no controle de qualidade. Uma ferramenta que executa testes em ambiente isolado, verifica compilação e demonstra que um crash foi resolvido produz evidência verificável. Já uma submissão que apenas infere um risco a partir da leitura de código exige que o destinatário faça toda a validação. A primeira reduz trabalho; a segunda pode aumentá-lo.

Essa distinção também evita uma conclusão simplista: “IA encontrou muitos bugs” não é equivalente a “IA melhorou a segurança”. A métrica relevante é quantas descobertas chegam a uma correção confirmada sem criar uma fila impossível de auditar.

O que muda para pesquisadores e projetos open source

Para pesquisadores, a pausa é um aviso de que relatórios assistidos por IA precisam ter uma camada humana de validação antes do envio. Uma boa prática é reproduzir o comportamento em uma versão identificada, anexar logs mínimos, remover conjecturas que não foram testadas e explicar o impacto sem inflá-lo. Se uma ferramenta gerou a hipótese, isso não elimina a responsabilidade de demonstrá-la.

Para projetos, o episódio reforça a necessidade de uma política clara de recebimento. Projetos podem definir canal de segurança, exigir prova de conceito não destrutiva, delimitar versões e componentes em escopo e explicar como lidam com contribuições produzidas com assistência de IA. Isso não é hostilidade a automação; é um mecanismo para proteger a capacidade de responder a falhas reais.

No Brasil, onde muitas equipes de produto dependem de bibliotecas open source mantidas por comunidades globais, o efeito é indireto, mas concreto. Uma fila de triagem saturada pode atrasar correções upstream, aumentar o tempo de exposição e dificultar a participação de pesquisadores independentes que fazem divulgação responsável. Empresas que consomem componentes críticos devem acompanhar avisos de segurança, manter inventário de dependências e não presumir que um relatório de IA equivale a uma vulnerabilidade confirmada.

Limitações e perguntas em aberto

O Google não divulgou a quantidade de envios automatizados, a taxa exata de falsos positivos nem critérios detalhados para reabrir o OSS VRP. Portanto, não é possível medir ainda a dimensão da sobrecarga ou concluir que todos os relatórios assistidos por IA sejam inúteis. Também não foi anunciado um mecanismo público que diferencie automaticamente submissões verificadas de material gerado sem reprodução.

A atualização prevista para o primeiro trimestre de 2027 será importante porque pode indicar se a resposta será apenas reduzir a superfície de entrada ou criar um processo que premie evidência reproduzível, patches testados e pesquisa humana apoiada por ferramentas.

Análise do NoticIA: a escassez agora é triagem confiável

Na análise do NoticIA, a suspensão mostra que a segurança de software entrou em uma fase em que produzir alegações ficou barato, mas verificar alegações continua caro. O gargalo não é mais somente encontrar padrões suspeitos em milhões de linhas de código; é estabelecer quais deles são reais, relevantes e corrigíveis. Programas de recompensa que não ajustarem seus filtros tendem a punir tanto mantenedores quanto pesquisadores sérios, porque todos disputam a mesma atenção operacional.

O caminho mais sustentável não parece ser proibir IA, mas vincular seu uso a evidências que uma equipe consiga reproduzir. Ferramentas que testam, isolam o defeito e propõem correções verificadas podem ampliar a defesa. Ferramentas que apenas geram relatórios bem redigidos deslocam custo para quem mantém o software. Essa diferença deve orientar políticas de contribuição, contratos de bug bounty e a avaliação de qualquer promessa de “segurança autônoma”.

Resumo

• O Google pausou novas submissões ao OSS VRP em 1º de outubro de 2026 devido ao aumento de envios automatizados inválidos.
• A suspensão é específica do programa open source e não encerra os demais canais de recompensa da empresa.
• Relatórios úteis precisam de reprodução, impacto demonstrável e evidência técnica, não apenas linguagem convincente.
• O episódio evidencia que a validação humana continua sendo o recurso escasso na segurança assistida por IA.