Programa de Recompensas por Bugs Open Source do Google é Pausado enquanto Relatórios de IA Sobrecarregam Revisores

O Google pausou seu programa de recompensas por bugs open source após uma onda de relatórios automatizados, afirmando que a grande maioria era inválida. A suspensão começou em 1º de outubro de 2026 e afeta novos envios de vulnerabilidades de produtos ao Open Source Software Vulnerability Reward Program.

A decisão cria uma contradição marcante para a pesquisa de segurança assistida por IA. Os modelos agora podem inspecionar mais código e produzir relatórios convincentes em uma velocidade sem precedentes. Ainda assim, cada envio continua exigindo que uma pessoa determine se a falha alegada existe, é relevante e pode ser reproduzida.

O Google não está sozinho. O Curl encerrou suas recompensas monetárias depois que sua taxa de vulnerabilidades confirmadas caiu abaixo de 5% em 2025. Mantenedores do Linux também mudaram suas práticas de divulgação após receberem ondas de descobertas de IA duplicadas. Juntos, esses casos mostram que a descoberta de vulnerabilidades cresceu mais rápido do que sua revisão.

Programa de Recompensas por Bugs Open Source do Google Deixa de Aceitar Relatórios de Produtos

O Google fechou temporariamente um importante canal de recebimento porque os envios automatizados geravam mais trabalho de revisão do que descobertas úteis de segurança.

O Google OSS VRP, sigla para Open Source Software Vulnerability Reward Program, recompensa pesquisadores que divulgam de forma responsável falhas de segurança em projetos open source elegíveis. O Google lançou o programa em 2022 para cobrir softwares mantidos em seus repositórios públicos e projetos externos selecionados.

Esse canal para vulnerabilidades de produtos deixou de aceitar novos relatórios em 1º de outubro. O Google afirmou que espera fornecer outra atualização durante o primeiro trimestre de 2027.

“Esta pausa se deve a um aumento significativo nos envios automatizados, dos quais a grande maioria não é válida”, disse o Google em seu comunicado. A formulação é importante porque distingue a automação da pesquisa de vulnerabilidades verificada.

A pausa não elimina relatórios enviados antes da data de corte. Ela também não fecha todos os caminhos associados ao programa mais amplo. Envios de vulnerabilidades na cadeia de suprimentos continuam elegíveis, de acordo com as regras do programa atualizadas.

Algumas vulnerabilidades envolvendo repositórios do Google Cloud ainda podem se qualificar pelo Cloud VRP. O Google também direcionou pesquisadores a seus outros programas de recompensa enquanto revisa o processo de recebimento de relatórios open source.

Esse escopo mais restrito torna “congelamento” uma descrição mais precisa do que “encerramento”. O Google suspendeu novos envios de vulnerabilidades de produtos dentro do programa OSS, mas não abandonou a pesquisa externa de segurança em toda a empresa.

A empresa não publicou uma contagem de envios, taxa de relatórios inválidos ou o total de pendências de triagem do canal afetado. Portanto, alegações de que os revisores receberam um número específico de relatórios ruins continuam não verificadas.

O que o Google divulgou é o sinal decisivo. Os relatórios automatizados haviam se tornado numerosos e pouco confiáveis o suficiente para tornar o processo existente insustentável.

Esse processo depende de mais do que receber um documento bem elaborado. Um revisor precisa inspecionar o caminho do código, recriar as condições, avaliar a possibilidade de exploração, procurar duplicatas e identificar a equipe responsável pelo projeto.

Um relatório plausível pode consumir muito tempo mesmo quando está errado. Grandes modelos de linguagem tornam esse problema mais difícil porque podem produzir explicações detalhadas, trechos de código e alegações confiantes de gravidade sem provar a vulnerabilidade subjacente.

O Google já havia endurecido suas regras no início de 2026 após observar um “aumento massivo” em relatórios gerados por IA. A pausa de outubro sugere que apenas os requisitos de filtragem não restauraram uma relação sinal-ruído aceitável.

O programa de recompensas por bugs open source do Google tornou-se, portanto, um caso de teste para um problema mais amplo de segurança. Gerar uma alegação agora é barato, enquanto refutá-la continua caro.

Por Que Relatórios de Bugs de IA Criam um Custo Assimétrico

A IA muda a economia da divulgação porque uma máquina pode gerar relatórios mais rápido do que os mantenedores conseguem validá-los.

A busca tradicional por bugs impõe custos significativos ao pesquisador. Uma pessoa precisa entender uma base de código, isolar um comportamento inesperado, testar se ele gera impacto de segurança e documentar um caso reproduzível.

A IA generativa reduz partes dessa carga de trabalho. Um agente pode examinar repositórios, rastrear funções, comparar padrões, elaborar código de prova de conceito e transformar descobertas preliminares em relatórios com aparência profissional.

Essas capacidades podem ajudar pesquisadores legítimos. Também podem permitir que usuários inexperientes enviem alegações que não entendem e não conseguem defender durante perguntas de acompanhamento.

A assimetria surge após o envio. Produzir mais um relatório pode exigir pouco esforço adicional, mas triá-lo ainda consome atenção escassa de engenharia.

Christopher Robinson, diretor de tecnologia da Open Source Security Foundation, descreveu essa carga em uma reportagem de segurança de março. Projetos populares costumavam receber dois ou três relatórios em uma semana média, estimou ele. Alguns posteriormente receberam centenas de uma vez.

Robinson disse que um relatório individual pode exigir de duas a oito horas de trabalho não planejado de um mantenedor. Esse custo existe mesmo quando a conclusão final é que não há vulnerabilidade.

Falsos positivos não são o único problema. Sistemas automatizados podem enviar descobertas duplicadas, interpretar erroneamente comportamentos documentados, ignorar modelos de ameaça ou exagerar defeitos de baixo impacto.

Uma vulnerabilidade alucinada é especialmente custosa porque o relatório pode parecer internamente coerente. Revisores podem seguir um argumento técnico detalhado antes de descobrir que uma função, caminho de controle ou condição de exploração citada foi inventada.

Vlad Ionescu, cofundador da empresa de segurança de IA RunSybil, descreveu essa experiência em uma investigação anterior sobre AI slop. Ele disse que os relatórios podem parecer tecnicamente sólidos até que revisores investiguem e descubram que o modelo fabricou os detalhes.

Isso cria um gargalo de verificação. A IA amplia a oferta de possíveis descobertas, mas não expande automaticamente o número de revisores confiáveis.

Programas de recompensa por bugs também criam um incentivo financeiro para enviar alegações incertas. Um pesquisador pode enviar muitos relatórios especulativos enquanto os mantenedores absorvem a maior parte do custo de validação.

Sistemas de reputação e limites de taxa podem reduzir abusos, mas introduzem seus próprios trade-offs. Barreiras rígidas podem excluir novos pesquisadores sem histórico na plataforma, mas que possuem uma descoberta legítima.

Requisitos de identidade podem desencorajar a divulgação responsável por pessoas que enfrentam riscos legais, profissionais ou geográficos. Taxas de envio criariam uma barreira ainda maior.

A triagem automatizada apresenta outra complicação. Um filtro que rejeita relatórios por parecerem gerados por máquina pode descartar vulnerabilidades genuínas encontradas ou documentadas com assistência de IA.

A distinção essencial não é se a IA participou do relatório. É se o remetente verificou o comportamento e consegue sustentar a alegação com evidências reproduzíveis.

Esse padrão se torna mais difícil de impor quando agentes podem criar documentos persuasivos em escala. A qualidade do texto já não oferece um sinal confiável da qualidade da pesquisa.

A resposta prática provavelmente envolverá exigências de evidência mais fortes. Os programas podem exigir reproduções mínimas, detalhes da versão afetada, rastros de exploração, casos de teste ou patches funcionais antes de atribuir uma revisão humana.

Esses requisitos transferem parte do custo de verificação de volta ao remetente. Eles também favorecem pesquisadores que entendem o código e permanecem disponíveis para responder a perguntas.

O Problema dos Relatórios de Bugs de IA do Google Também é um Sucesso da Segurança de IA

A mesma tecnologia que cria envios de baixa qualidade está encontrando vulnerabilidades reais que pesquisadores humanos não detectaram.

Tratar todo relatório assistido por IA como lixo interpretaria mal as evidências. Modelos avançados demonstraram capacidades significativas de análise de código sob condições controladas.

A Anthropic afirmou que o Claude Opus 4.6 encontrou mais de 500 vulnerabilidades anteriormente desconhecidas em projetos open source durante testes internos. Pesquisadores humanos ou externos de segurança validaram cada descoberta antes da divulgação, segundo a empresa.

A Mozilla recebeu 112 relatórios desse esforço ao longo de duas semanas. Ela emitiu 22 avisos de segurança, incluindo 14 sobre falhas de alta gravidade, enquanto classificou muitas das descobertas restantes como bugs sem impacto de segurança.

Esses resultados ilustram um processo diferente do envio automatizado em massa. A Anthropic combinou a descoberta por máquina com validação humana, divulgação coordenada e comunicação focada com os mantenedores.

Em um caso, o modelo teria criado uma prova de conceito para estabelecer que uma falha suspeita era real. Essa etapa transforma um padrão especulativo em evidência que os revisores podem testar.

As descobertas do Firefox também mostram por que proibir completamente a pesquisa com IA seria contraproducente. Os modelos podem examinar código maduro e amplamente testado e ainda revelar defeitos relevantes.

O conflito, portanto, não é entre humanos e IA. É entre pesquisa verificada e geração irresponsável de relatórios.

Um fluxo de trabalho de alta qualidade assistido por IA mantém um responsável humano. Essa pessoa verifica a saída, remove falsos positivos, entende o impacto e assume a responsabilidade de se comunicar com os mantenedores.

Um fluxo de trabalho de baixa qualidade trata o ponto final da divulgação como outro destino automatizado. O agente identifica um padrão, redige uma narrativa de gravidade e a envia sem reprodução independente.

Ambos os fluxos de trabalho podem produzir prosa bem elaborada. Apenas um reduz a carga de trabalho do destinatário.

Essa distinção explica por que a pausa do Google não prova que a busca por bugs com IA fracassou. Ela mostra que sua arquitetura de envio não conseguia absorver a mistura atual de descobertas valiosas, duplicatas e alucinações.

A segurança assistida por IA pode eventualmente melhorar ambos os lados dessa arquitetura. Os programas podem usar modelos para agrupar duplicatas, comparar alegações com problemas conhecidos, testar caminhos de exploração e identificar evidências ausentes.

A HackerOne e outras plataformas começaram a introduzir assistência de triagem baseada em IA. Essas ferramentas podem priorizar relatórios, mas seu desempenho precisa ser medido em relação às taxas de rejeição incorreta e de vulnerabilidades não detectadas.

Um revisor automatizado também pode alucinar. Se os programas colocarem um modelo entre pesquisadores e mantenedores, precisarão de rotas de escalonamento para descobertas que o filtro não possa classificar com segurança.

O modelo mais robusto provavelmente será em camadas. Máquinas realizam verificações de baixo custo, triadores experientes analisam os relatórios restantes e mantenedores de projetos lidam apenas com descobertas críveis.

Essa abordagem se assemelha à integração contínua para contribuições de software. Testes rejeitam falhas óbvias antes que um mantenedor dedique tempo a uma revisão detalhada.

Alegações de segurança continuam mais difíceis de testar do que mudanças comuns de código. A possibilidade de exploração depende de contexto, configuração, limites de confiança e capacidades de atacantes que verificações automatizadas podem interpretar incorretamente.

Ainda assim, exigir evidências verificáveis por máquina pode melhorar o nível básico. Um relatório com um teste que falha, rastro de execução ou falha reproduzível oferece aos revisores algo concreto para avaliar.

As organizações também precisam de registros duradouros para esse trabalho. Uma base de conhecimento de engenharia pesquisável pode ajudar as equipes a comparar novas descobertas com relatórios, decisões e correções anteriores.

O objetivo não é desacelerar descobertas legítimas. É impedir que uma geração ilimitada consuma um orçamento limitado de revisão humana.

Curl e Linux Mostram que Este é um Problema da Indústria

A pausa do Google segue um padrão em que projetos de código aberto restringem os canais de divulgação depois que a IA sobrecarrega os sistemas de confiança existentes.

O Curl oferece o exemplo anterior mais claro. O amplamente utilizado projeto de transferência de dados encerrou sua recompensa monetária por bugs em 31 de janeiro de 2026, após manter o programa desde 2019.

O mantenedor Daniel Stenberg afirmou que o programa havia produzido 87 vulnerabilidades confirmadas. No entanto, a tendência de qualidade se deteriorou acentuadamente durante 2025.

Anteriormente, o Curl confirmava mais de 15% das submissões como vulnerabilidades. A taxa caiu para menos de 5% em 2025, o que significa que menos de um em cada vinte relatórios se mostrou válido.

Stenberg atribuiu o problema a três tendências interligadas: conteúdo ruim gerado por IA, queda de qualidade em outras submissões e pesquisadores focados em recompensas, em vez de melhorar o projeto.

“As submissões ruins intermináveis cobram um sério custo mental para serem gerenciadas”, escreveu ele ao anunciar a decisão do curl.

O Curl não deixou de aceitar divulgações de segurança. Ele retirou as recompensas monetárias, manteve o HackerOne como canal recomendado e direcionou pesquisadores para relatórios privados no GitHub ou e-mail.

Essa resposta mirou os incentivos, e não a tecnologia em si. Stenberg argumentou que as recompensas atraíam descobertas legítimas, mas também tornavam excessivamente fácil enviar alegações especulativas.

Ele reconheceu a contrapartida. Remover pagamentos pode reduzir o ruído, mas também pode enfraquecer os incentivos para pesquisadores independentes qualificados que dedicam tempo significativo a investigações difíceis.

A comunidade do kernel Linux enfrentou um problema relacionado envolvendo descobertas duplicadas. Vários pesquisadores executaram ferramentas de IA semelhantes sobre o mesmo código e enviaram os mesmos problemas por meio de um canal privado.

A divulgação privada impediu que pesquisadores vissem que outra pessoa já havia relatado ou discutido uma descoberta. Os mantenedores redirecionaram repetidamente duplicatas ou apontaram para correções já disponíveis publicamente.

Linus Torvalds descreveu a lista privada de segurança como “quase totalmente impossível de gerenciar”. Ele argumentou que descobertas detectadas por IA geralmente deveriam seguir os canais públicos do projeto, a menos que o sigilo fosse realmente necessário.

A documentação do Linux também elevou o padrão esperado dos remetentes. Pesquisadores devem fornecer evidências concisas, contatar os mantenedores relevantes e contribuir com um patch quando possível.

Essa política preserva a responsabilização humana. A IA pode auxiliar na descoberta, mas uma pessoa precisa compreender o relatório e continuar responsável por suas consequências.

Google, curl e Linux escolheram intervenções diferentes porque seus programas têm estruturas distintas. O Google pausou uma categoria de submissão. O Curl removeu as recompensas. O Linux redirecionou muitos relatórios e enfatizou o tratamento público.

A conclusão compartilhada é mais importante do que os detalhes de cada política. Uma entrada aberta, sem custos significativos para submissão, não funciona quando agentes automatizados podem criar alegações quase ilimitadas.

Projetos menores enfrentam o maior risco. O Google pode alocar engenheiros e redesenhar infraestrutura, enquanto mantenedores voluntários podem não ter uma equipe dedicada à triagem.

Softwares de código aberto frequentemente estão presentes em produtos comerciais, serviços de nuvem, ferramentas de desenvolvimento e sistemas críticos. Ainda assim, a responsabilidade de revisar relatórios de segurança pode recair sobre poucos colaboradores não remunerados.

A IA amplifica esse descompasso. Ela permite que pessoas externas examinem código importante continuamente sem fornecer o trabalho necessário para validar, corrigir e coordenar cada possível descoberta.

O resultado se assemelha a um problema de negação de serviço, mesmo quando os remetentes têm boas intenções. Cada relatório exige atenção dos mantenedores, e o volume combinado pode deslocar vulnerabilidades genuínas.

Barreiras Mais Rígidas Também Podem Ocultar Vulnerabilidades Reais

Os programas precisam reduzir o volume de baixa qualidade sem criar um sistema de segurança acessível apenas a pesquisadores estabelecidos.

A pausa do Google protege os revisores no curto prazo, mas também remove uma via de denúncia para descobertas legítimas. Uma vulnerabilidade válida em um produto, encontrada após 1º de outubro, pode precisar de outro programa elegível ou canal de divulgação.

Esse atrito importa porque pesquisadores nem sempre compreendem os limites organizacionais de uma empresa. Uma falha em um repositório de código aberto pode afetar um produto de nuvem, uma dependência ou uma aplicação downstream.

Regras complexas de encaminhamento aumentam o risco de divulgação atrasada ou direcionada incorretamente. Elas também podem incentivar a publicação pública quando pesquisadores não conseguem identificar um canal privado aceito.

O acesso baseado em reputação cria outro risco. Pesquisadores experientes são mais fáceis de confiar, mas novos participantes historicamente contribuíram com descobertas importantes para programas de recompensa.

Um sistema que favorece identidades estabelecidas pode reproduzir lacunas de acesso já existentes. Ele pode desfavorecer pesquisadores independentes, estudantes e pessoas fora das principais comunidades de segurança.

Exigências rígidas de prova de conceito também podem se tornar perigosas. Demonstrar a explorabilidade pode exigir lidar com dados reais, contornar salvaguardas ou realizar testes que violam as regras do programa.

Por isso, os programas precisam de padrões de evidência fortes, mas seguros. Um reprodutor mínimo, teste controlado ou caminho de código detalhado pode estabelecer credibilidade sem exigir exploração prejudicial.

Também não há um detector confiável de texto gerado por IA. Pesquisadores frequentemente usam modelos para tradução, edição, explicação de código ou formatação, mesmo quando o trabalho subjacente é legítimo.

Rejeitar relatórios com base no estilo puniria uma divulgação cuidadosa e criaria incentivos para ocultar o uso de IA. Isso não estabeleceria se a falha relatada é real.

A declaração pública do Google deixa várias perguntas sem resposta. A empresa não divulgou quais medidas de triagem falharam, quantas descobertas legítimas foram capturadas durante o aumento de volume ou qual reformulação está considerando.

Também não está claro se a pausa terminará com mais automação, limites de evidência mais altos, acesso restrito ou um modelo de recompensa diferente.

A falta de números limita a avaliação externa. “A vasta maioria” comunica gravidade, mas não revela se a validade caiu ligeiramente abaixo de um limite já existente ou desabou quase completamente.

Os leitores também devem evitar tratar a experiência do Google como universal. A Mozilla afirmou anteriormente que sua taxa de rejeição de relatórios inválidos havia permanecido estável durante um período anterior, apesar da preocupação mais ampla da indústria.

O desenho do programa, a visibilidade do projeto, os incentivos de recompensa e as regras de submissão afetam o volume e a qualidade dos relatórios. Uma política que funciona para um projeto pode falhar para outro.

Os próprios sistemas de IA estão mudando rapidamente. Modelos melhores podem produzir falsos positivos mais convincentes, mas também podem gerar provas mais robustas e reduzir alucinações.

Esse movimento duplo torna regras estáticas frágeis. Os programas precisam de controles de qualidade mensuráveis que avaliem evidências, em vez de tentar adivinhar qual ferramenta as produziu.

Para líderes de segurança, a métrica central não deve ser o volume bruto de relatórios. Medidas úteis incluem taxa de vulnerabilidades confirmadas, taxa de duplicatas, tempo mediano de triagem, tempo de correção e carga de trabalho dos revisores.

Um programa pode receber mais relatórios e ainda assim se tornar menos eficaz. Por outro lado, uma entrada mais rigorosa pode reduzir o volume e aumentar a parcela de descobertas sérias que chega aos mantenedores.

A pausa do OSS VRP do Google deve, portanto, ser julgada pelo que a substituirá. Fechar uma fila sobrecarregada é compreensível, mas um resultado de segurança duradouro exige um caminho confiável para relatórios válidos.

O que Acontece Depois com a Recompensa por Bugs de Código Aberto do Google

Três sinais revelarão se a pausa do Google se transforma em um sistema de divulgação melhor ou em um recuo duradouro da participação aberta.

O primeiro sinal é a atualização prometida pelo Google durante o primeiro trimestre de 2027. Os detalhes mais importantes dirão respeito à elegibilidade, aos padrões de evidência, à triagem automatizada e aos procedimentos de recurso.

Uma reabertura com requisitos claros de reprodução reforçaria a ideia de que o Google usou a pausa para reformular a entrada. Uma extensão indefinida sugeriria que a submissão aberta continua economicamente difícil.

Observe se o Google exigirá que os remetentes forneçam testes executáveis, commits afetados, rastros de exploração ou correções propostas. Essas regras transfeririam a responsabilidade para os pesquisadores sem proibir a assistência de IA.

O segundo sinal é a taxa de relatórios confirmados após qualquer reabertura. O Google não publicou uma base de referência atual, portanto a transparência sobre futuras taxas de validade e duplicação ajudaria a avaliar o novo sistema.

Uma taxa maior de confirmações com acesso estável à divulgação apoiaria uma filtragem mais rigorosa. Uma queda acentuada na participação poderia indicar que as barreiras estão excluindo pesquisadores legítimos junto com o spam.

O tempo de triagem também importa. Se os revisores puderem avaliar relatórios confiáveis mais rapidamente, o Google terá evidências de que a reformulação reduziu o trabalho oculto, em vez de apenas reduzir o volume visível.

O terceiro sinal é como outros projetos e plataformas responderão. O Curl removeu recompensas, o Linux redirecionou descobertas automatizadas e o Google pausou uma categoria de submissão.

Se mais programas adotarem reproduções verificadas, requisitos de patch ou limites de reputação, essas práticas poderão se tornar o padrão para divulgação assistida por IA.

As plataformas também podem criar defesas compartilhadas. Detecção de duplicatas entre programas, evidências padronizadas e legíveis por máquina, além de identidades responsáveis para agentes, poderiam reduzir o trabalho repetido.

O resultado mais construtivo separaria a escala de descoberta da escala de submissão. Pesquisadores poderiam executar agentes amplamente, mas apenas descobertas validadas e sem duplicação entrariam nas filas de revisão humana.

Esse modelo exige responsabilidade em cada transferência. Desenvolvedores de ferramentas precisam projetar para verificação, pesquisadores precisam testar descobertas, plataformas precisam filtrar com cuidado e mantenedores precisam de caminhos claros de escalonamento.

Desenvolvedores que usam ferramentas de segurança com IA já deveriam se comportar como se essas regras existissem. Eles devem reproduzir cada alegação, compreender o código afetado, verificar o histórico público de issues e documentar um impacto realista.

Eles também devem permanecer disponíveis após a submissão. Um remetente que não consegue responder a perguntas técnicas básicas transfere todo o custo da investigação para o projeto.

Para empresas, a lição vai além das recompensas por bugs. Qualquer sistema público de entrada pode ficar sobrecarregado quando a IA torna a geração de conteúdo barata e a avaliação continua cara.

Filas de suporte, candidaturas a empregos, programas de subsídios, pull requests e relatórios de conformidade enfrentam o mesmo desequilíbrio básico. O recurso escasso já não é a escrita. É a revisão confiável.

A pausa na recompensa por bugs de código aberto do Google torna esse desequilíbrio visível em um contexto de alto risco. Um falso relatório de segurança desperdiça tempo, enquanto deixar passar uma vulnerabilidade real pode expor milhões de usuários downstream.

O desafio não é escolher entre IA e pesquisadores humanos. É projetar um sistema de divulgação em que a automação aumente o trabalho de segurança verificado, em vez de multiplicar alegações sem comprovação.

O Google agora tem até sua próxima atualização para mostrar como esse sistema será. Ele reabrirá com barreiras de evidência mais fortes e acesso significativo, ou a participação aberta continuará se estreitando à medida que o volume de relatórios cresce?