Suspensão do Google OSS VRP mostra que relatórios de bugs por IA têm um problema de verificação

O Google suspendeu uma categoria de seu programa de vulnerabilidades de código aberto em 1º de outubro, depois que relatos inválidos gerados por IA supostamente sobrecarregaram seu processo de revisão.

A suspensão do Google OSS VRP interrompe novas submissões de “Vulnerabilidade de Produto” enquanto a empresa reformula essa parte do programa. O Google espera fornecer uma atualização durante o primeiro trimestre de 2027.

A decisão não encerra todos os programas de vulnerabilidades do Google. Tampouco proíbe pesquisadores de usar inteligência artificial para investigar código.

Em vez disso, ela expõe um conflito crescente entre descoberta automatizada e verificação humana. A IA pode gerar possíveis descobertas muito mais rápido do que os mantenedores conseguem reproduzi-las, avaliá-las e corrigi-las.

A ação do Google ocorre após meses de pressão crescente em toda a segurança de código aberto. Mantenedores do Linux e de outros projetos enfrentaram ondas semelhantes de relatórios duplicados, especulativos ou mal testados.

Esse padrão mais amplo importa mais do que um único formulário de submissão pausado. Tradicionalmente, os programas de segurança recompensam pesquisadores por encontrarem problemas que as equipes internas não detectaram. A IA muda esse modelo ao tornar a geração de candidatos excepcionalmente barata.

O recurso escasso já não é a suspeita inicial. É a atenção especializada necessária para provar que uma falha é alcançável, explorável e relevante para um modelo de ameaça real.

O que a suspensão do Google OSS VRP realmente muda

O Google pausou uma categoria de relatórios, não abandonou a pesquisa de vulnerabilidades em código aberto nem encerrou toda a sua operação de recompensas.

O Open Source Software Vulnerability Reward Program, conhecido como OSS VRP, abrange problemas de segurança qualificados em repositórios de código aberto pertencentes ao Google. O Google introduziu o programa em 2022.

Relatórios de vulnerabilidade de produto identificam defeitos no código, na lógica ou no design de um projeto. Um relatório válido precisa fazer mais do que apontar para um código suspeito.

Em geral, os pesquisadores precisam mostrar uma versão afetada, um caminho de execução alcançável, etapas de reprodução e uma consequência de segurança significativa. Esses requisitos distinguem vulnerabilidades exploráveis de erros comuns de programação.

Segundo os detalhes da suspensão, a pausa entrou em vigor quando o Google a anunciou em 1º de outubro. Relatórios de vulnerabilidade de produto enviados antes dessa data continuam elegíveis para revisão.

Relatórios de cadeia de suprimentos também permanecem abertos. Esses relatórios dizem respeito a comprometimentos que afetam a forma como dependências de software, código-fonte, compilações ou lançamentos chegam aos usuários.

Algumas vulnerabilidades que afetam produtos Google Cloud ainda podem se qualificar por meio do Cloud VRP separado. A elegibilidade depende do repositório e de sua ligação com um produto de nuvem coberto.

Pesquisadores também podem participar de outros programas de recompensa do Google. Eles incluem programas que abrangem Chrome, Android, dispositivos Google, serviços em nuvem e questões específicas de segurança em IA.

Essa distinção de escopo é importante. Chamar a medida de encerramento completo exageraria o evento e obscureceria a resposta mais direcionada do Google.

A empresa está, na prática, fechando um canal de recebimento de alto volume enquanto mantém canais mais restritos disponíveis. Ela planeja reformular esse canal antes de discutir seu futuro.

A substituição exata permanece desconhecida. O Google não detalhou publicamente se adicionará requisitos mais rigorosos de identidade, reprodução, ritmo de envio ou evidências.

O Google já havia endurecido o programa antes da suspensão. Suas regras do OSS VRP exigiam que pesquisadores validassem descobertas assistidas por IA e demonstrassem impacto real de segurança.

As regras descreviam vários problemas recorrentes. Alguns relatórios gerados por IA incluíam condições de acionamento incorretas ou detalhes técnicos inventados.

Outros relatórios identificavam erros reais de codificação, mas não conseguiam estabelecer consequências de segurança. Um estouro de buffer, por exemplo, poderia existir apenas em código inalcançável ou atrás de uma barreira de segurança eficaz.

O Google também encerrou recompensas monetárias e crédito público para certas vulnerabilidades de produto de menor nível e outros problemas de segurança. Essa mudança de abril de 2026 tentou remover incentivos para submissões de baixo impacto.

A suspensão posterior sugere que esses controles mais restritos não reduziram suficientemente a carga de revisão. O Google passou de desestimular relatórios fracos para recusar temporariamente a categoria.

A suspensão do Google OSS VRP representa, portanto, uma decisão operacional. Os revisores do programa já não podiam tratar cada possibilidade enviada como um ponto de partida acessível.

Relatórios de bugs por IA mudaram o custo de fazer uma alegação

A IA reduz o custo de alegar uma vulnerabilidade sem reduzir o custo de comprová-la.

A pesquisa tradicional de vulnerabilidades exigia esforço manual substancial antes que um pesquisador pudesse produzir um relatório plausível. Era necessário inspecionar o código, compreender os caminhos de execução e construir um teste.

Modelos de linguagem modernos e agentes autônomos de código podem examinar repositórios e gerar hipóteses muito mais rapidamente. Eles também podem produzir relatórios bem elaborados que se parecem com análises humanas cuidadosas.

Essa aparência cria uma assimetria perigosa. Um documento convincente pode levar segundos para ser gerado, enquanto refutar suas alegações pode consumir horas de atenção especializada.

Um relatório pode identificar uma operação de memória suspeita e prever execução remota de código. Em seguida, o modelo pode criar uma narrativa detalhada de ataque em torno dessa previsão.

No entanto, a função afetada talvez nunca processe entrada controlada por um invasor. O compilador pode eliminar o caminho, ou a validação existente pode bloquear o acionamento proposto.

O modelo de ameaça do projeto também pode excluir os privilégios de invasor assumidos. Em cada caso, o relatório parece sério, mas não consegue demonstrar uma vulnerabilidade.

Mantenedores não podem rejeitar com segurança todo relatório automatizado à primeira vista. Uma submissão mal escrita ainda pode conter uma falha real, enquanto uma submissão bem elaborada pode ser inteiramente especulativa.

Os revisores precisam inspecionar o código, recriar o ambiente, testar a entrada alegada e avaliar as defesas existentes. Também podem precisar entrar em contato com o autor do relatório para obter evidências ausentes.

Essa carga de trabalho cresce com cada relatório, inclusive os inválidos. Submissões automatizadas, portanto, transferem o custo da validação dos autores dos relatórios para os mantenedores.

O efeito se assemelha mais ao spam de e-mail do que à pesquisa tradicional de segurança. Enviar outra mensagem quase não custa nada, mas as organizações destinatárias ainda precisam filtrar cada alegação potencialmente importante.

Recompensas financeiras podem intensificar esse desequilíbrio. Se um resultado aceito cobrir o custo de gerar milhares de submissões, o volume se torna uma estratégia racional para participantes pouco rigorosos.

Esse comportamento prejudica pesquisadores que realizam um trabalho cuidadoso. Suas descobertas entram na mesma fila e competem pelos mesmos revisores.

Também prejudica os usuários quando os mantenedores passam menos tempo corrigindo vulnerabilidades confirmadas. A triagem se torna o gargalo antes mesmo de a correção poder começar.

O problema não é simplesmente que os modelos alucinam. Pesquisadores humanos também cometem erros, exageram o impacto e enviam duplicatas.

A IA muda a escala, a velocidade e a apresentação dessas falhas. Ela permite que uma pessoa produza alegações mais plausíveis do que consegue validar pessoalmente.

Essa distinção explica por que proibir textos gerados por IA resolveria pouco. Um pesquisador poderia reescrever uma saída não verificada de um modelo e enviar a mesma alegação sem suporte.

Em vez disso, os programas precisam de barreiras baseadas em evidências. A questão relevante é se o autor do relatório testou o resultado, não se um modelo contribuiu para sua descoberta.

A pausa do Google indica que suas regras existentes não conseguiam impor essa distinção de forma eficiente. Requisitos por escrito eram mais fáceis de publicar do que de aplicar diante de um volume industrializado de relatórios.

A estratégia de segurança em IA do Google agora enfrenta seu próprio dilema

O Google promove a descoberta de segurança assistida por IA, mas seu programa de recompensas não consegue absorver toda descoberta produzida pela mesma onda de automação.

A suspensão do Google OSS VRP não significa que a empresa considere a IA inútil para a segurança. O Google continua investindo em descoberta e correção automatizadas de vulnerabilidades.

Suas equipes de segurança usam ferramentas como OSS-Fuzz, Big Sleep e CodeMender. Esses sistemas combinam análise automatizada com testes controlados e revisão especializada.

O Google também reformulou seus programas de recompensa do Android e do Chrome para o que chama de era da IA. A empresa espera que a automação descubra vulnerabilidades que a pesquisa convencional deixa passar.

Isso torna a suspensão uma reversão significativa. O Google não está recuando da pesquisa de segurança em IA, mas está limitando um canal externo afetado pelos menores custos de submissão proporcionados pela IA.

A divisão central não é entre pesquisa humana e pesquisa por máquinas. É entre automação validada internamente e alegações enviadas externamente com validação desigual.

O Google controla o ambiente em torno de seus próprios sistemas. Os engenheiros podem definir alvos, executar testes, coletar falhas e medir se os patches gerados preservam o comportamento.

Um programa de recompensas aberto não tem esse controle. Os participantes usam ferramentas, prompts, modelos, versões de código e definições de impacto de segurança diferentes.

Os revisores recebem a alegação final sem ver cada etapa que a produziu. Eles precisam reconstruir suposições ausentes antes de decidir se a descoberta importa.

Essa diferença transforma a procedência em uma questão prática de segurança. As equipes precisam saber qual revisão foi testada, qual entrada acionou o resultado e se um humano o reproduziu.

O sistema mais amplo de recompensas do Google continua substancial. A empresa afirmou que seus programas pagaram mais de US$ 17 milhões a mais de 700 pesquisadores durante 2025.

Sua revisão anual do VRP descreveu esse total como um recorde histórico. O valor aumentou mais de 40% em relação a 2024.

Esses números mostram que o Google ainda valoriza a pesquisa externa. Eles também demonstram por que é importante manter canais de submissão confiáveis.

Um programa de recompensas depende de confiança mútua. Pesquisadores precisam acreditar que descobertas válidas receberão atenção justa, enquanto as empresas precisam confiar que os autores dos relatórios testem suas alegações.

A automação sem filtragem enfraquece ambos os lados. Atrasos na revisão frustram pesquisadores competentes, e relatórios inválidos recorrentes tornam os revisores mais céticos em relação a colaboradores desconhecidos.

A resposta do Google protege a capacidade de triagem, mas também restringe o acesso. Pesquisadores independentes não podem atualmente enviar vulnerabilidades comuns de produto pela categoria suspensa do OSS VRP.

Essa limitação pode suprimir descobertas valiosas junto com o ruído. Um novo pesquisador com uma questão válida pode não ter um programa alternativo evidente.

O desafio é, portanto, um equilíbrio entre abertura e verificação. O acesso amplo aumenta as oportunidades de descoberta, enquanto barreiras rígidas protegem o tempo limitado dos revisores.

Qualquer programa reformulado precisa preservar ambos os objetivos. Se os requisitos de entrada se tornarem excessivamente onerosos, o Google corre o risco de concentrar a participação entre pesquisadores estabelecidos e empresas especializadas.

Se os requisitos permanecerem frouxos demais, a fila de submissões poderá retornar à mesma sobrecarga. A atualização do primeiro trimestre de 2027 revelará onde o Google traça essa linha.

A enxurrada de relatórios por IA é um problema de toda a indústria

A decisão do Google faz parte de uma mudança mais ampla, na qual comunidades de segurança estão reescrevendo regras de divulgação em torno da descoberta automatizada.

HackerOne relatou um aumento de mais de 100% no volume de relatórios do setor após o surgimento de ferramentas de IA mais capazes em fevereiro de 2026.

Sua análise de volume de relatórios constatou que alguns envios continham descobertas úteis. Outros eram duplicados, alegações impossíveis de verificar ou relatórios sem profundidade acionável.

A plataforma não respondeu proibindo o uso responsável de assistência por IA. Em vez disso, reforçou a obrigação do pesquisador de validar as descobertas e demonstrar impacto real.

As regras da HackerOne exigem uma prova de conceito reproduzível, classificação de severidade precisa e consideração das defesas existentes. Grandes lotes de relatórios não verificados podem levar a medidas de aplicação.

Essa abordagem coloca a responsabilidade no operador, e não na ferramenta. Um pesquisador continua responsável por cada endpoint gerado, etapa de ataque e alegação de impacto.

A comunidade do kernel Linux adotou uma abordagem semelhante, focada em evidências. Suas regras de relato de segurança agora abordam diretamente a revisão de código assistida por IA.

A documentação afirma que relatórios de IA frequentemente se tornam excessivamente longos e obscurecem fatos críticos. Ela pede que os relatores forneçam descrições concisas, revisões afetadas, condições de acionamento e reprodutores testados.

O Linux também alerta que ferramentas podem inventar impactos teóricos sem compreender o modelo de ameaça do kernel. Em vez disso, pede que os relatores indiquem consequências verificáveis.

O projeto trata descobertas automatizadas amplamente reproduzíveis de forma diferente das descobertas tradicionalmente privadas. Vários pesquisadores frequentemente encontram o mesmo problema porque executam ferramentas semelhantes.

Isso cria trabalho duplicado dentro de canais de divulgação projetados para vulnerabilidades escassas, descobertas de forma independente. A automação altera os pressupostos por trás desses canais.

O mantenedor do Curl, Daniel Stenberg, descreveu outra versão do problema em 2025. Seu argumento de “morte por mil lamas” concentrou-se no custo cumulativo de revisar envios fracos.

Um único relatório ruim pode parecer administrável. Repetir esse custo em centenas de alegações geradas pode esgotar um projeto mantido por voluntários.

Esses casos compartilham um mesmo mecanismo. A IA amplia a oferta de hipóteses de vulnerabilidade mais rápido do que a oferta de trabalho qualificado de triagem.

O impacto varia entre organizações. O Google pode designar engenheiros de segurança remunerados, enquanto projetos menores frequentemente dependem de voluntários com tempo limitado.

Mantenedores de código aberto enfrentam uma estrutura de incentivos especialmente difícil. Código público é fácil de ser absorvido por scanners automatizados, mas os mantenedores não recebem recursos equivalentes.

Recompensas podem acrescentar outro desequilíbrio. Uma empresa pode premiar descobertas aceitas, enquanto mantenedores da comunidade lidam com discussões iniciais ou correções upstream sem compensação.

Isso não torna a pesquisa automatizada inerentemente prejudicial. A IA pode inspecionar componentes obscuros, traduzir código pouco familiar e ajudar pesquisadores a criar testes.

Ela também pode melhorar a qualidade dos relatórios quando usada após a verificação. Um modelo pode organizar etapas de reprodução ou explicar fluxos de controle complexos com mais clareza.

As mesmas capacidades se tornam destrutivas quando substituem a verificação. Gerar uma narrativa plausível não equivale a demonstrar uma condição explorável.

O consenso emergente no setor é, portanto, de aceitação condicional. A assistência por IA continua bem-vinda quando um operador humano consegue reproduzir e defender cada alegação importante.

A suspensão temporária do Google é mais restritiva do que esse princípio. Ainda assim, ela reflete o mesmo juízo sobre onde a responsabilidade deve recair.

A pessoa que envia um relatório deve assumir custo de validação suficiente para proteger quem o recebe. Caso contrário, o programa se torna uma fila terceirizada de testes para resultados especulativos de máquinas.

Barreiras Mais Rigorosas Podem Ajudar, Mas Introduzem Novos Riscos

Um programa redesenhado precisa incorporar o custo da verificação em cada envio sem excluir pesquisadores independentes legítimos.

O Google não divulgou o substituto final para os envios de vulnerabilidades de produtos. Vários controles se encaixariam nos problemas identificados em suas regras anteriores.

O primeiro é um reprodutor testado obrigatório. Um reprodutor fornece um pequeno programa, entrada ou procedimento que aciona de forma consistente o comportamento alegado.

O Google poderia exigir que os relatores indiquem a revisão exata do repositório e o ambiente. Essas informações reduziriam o tempo perdido testando código desatualizado ou incompatível.

Os relatórios também poderiam exigir um argumento explícito de alcançabilidade. O relator precisaria mostrar como dados controlados pelo atacante chegam à operação vulnerável.

Um campo estruturado de modelo de ameaça poderia obrigar pesquisadores a identificar privilégios necessários, limites de confiança e mitigações existentes. Alegações de severidade sem suporte se tornariam mais fáceis de detectar.

Limites de taxa oferecem outra opção. O Google poderia restringir quantos relatórios não resolvidos uma conta envia durante um período fixo.

Isso desencorajaria envios indiscriminados, preservando o acesso para pesquisadores cuidadosos. Limites maiores poderiam seguir um histórico de trabalho aceito.

Depósitos ou requisitos de reputação poderiam fornecer filtragem mais forte, mas apresentam maiores riscos de equidade. Novos pesquisadores poderiam ter dificuldade para entrar no programa.

A pré-triagem automatizada é outro componente provável. O Google poderia usar análise estática, execução em sandbox ou revisão baseada em modelos para sinalizar duplicados e evidências ausentes.

No entanto, a triagem automatizada não pode se tornar com segurança a autoridade final. Ela pode rejeitar pesquisas incomuns, porém válidas, ou favorecer padrões de vulnerabilidade conhecidos.

Um modelo revisando o relatório de outro modelo também pode reproduzir as mesmas suposições equivocadas. Evidências de execução independente continuam sendo mais valiosas do que concordância textual.

Privacidade e confidencialidade criam complicações adicionais. Pesquisadores podem expor detalhes ainda não corrigidos a serviços de IA de terceiros ao pedir análises a modelos.

Um programa revisado poderia exigir a divulgação do uso de modelos externos em torno de descobertas confidenciais. Também poderia restringir quais materiais sensíveis entram em sistemas hospedados.

O Google também precisa esclarecer como mantenedores de código aberto participam da triagem. Um relatório pode afetar um repositório do Google enquanto impõe trabalho a uma comunidade mais ampla de colaboradores.

A empresa deveria evitar resolver seu problema de fila transferindo as responsabilidades de verificação para upstream. Isso deslocaria a carga, em vez de reduzi-la.

A transparência será importante durante a pausa. O Google não forneceu publicamente uma divisão detalhada entre relatórios aceitos, duplicados, inválidos e assistidos por IA.

A Tom’s Hardware descreveu engenheiros e mantenedores enfrentando milhares de envios de baixa qualidade. O aviso publicado pelo Google, porém, não forneceu um volume preciso nem uma taxa de aceitação.

Essa distinção limita o que observadores externos podem concluir. As evidências disponíveis sustentam a existência de um problema sério de qualidade, mas não um quadro quantitativo completo.

O Google deveria publicar dados agregados suficientes para explicar os limites redesenhados. Métricas úteis incluem o tempo mediano de revisão e a parcela de relatórios sem reprodutores funcionais.

Taxas de rejeição indevida também importam. Uma fila mais rápida não é um sucesso se descobertas fortes desaparecem porque filtros automatizados as classificam incorretamente.

O programa deveria distinguir assistência à descoberta de envio autônomo. Uma descoberta de IA revisada por humanos pode ser valiosa, enquanto um fluxo não supervisionado de relatórios cria risco não gerenciado.

O projeto mais robusto do Google tornaria a prova mais barata de avaliar do que a prosa. Testes legíveis por máquina, modelos restritos e ambientes reproduzíveis poderiam apoiar esse objetivo.

A empresa também deveria preservar um caminho de escalonamento para descobertas não convencionais. Algumas vulnerabilidades importantes resistem a casos de teste simples ou envolvem cadeias complexas.

Nenhuma barreira isolada equilibrará esses requisitos. A resposta provável é acesso em camadas, baseado na qualidade das evidências, no histórico do pesquisador e no impacto de segurança demonstrado.

O Que Observar Antes da Atualização do Google no 1º Trimestre de 2027

A próxima fase mostrará se o Google consegue reabrir os envios com melhores padrões de evidência, em vez de simplesmente aceitar menos pesquisadores.

O primeiro sinal é o escopo do programa substituto. O Google precisa explicar se os envios de vulnerabilidades de produtos serão totalmente reabertos ou retornarão por meio de um canal mais restrito.

Uma reabertura completa sugeriria que novos filtros restauraram a confiança no processo de revisão. Um sistema limitado a convites indicaria que a capacidade de triagem continua restrita.

O segundo sinal são as evidências exigidas dos relatores. Reprodutores testados, commits afetados e caminhos concretos de ataque abordariam as fraquezas que o Google já identificou.

Esses requisitos fortaleceriam o programa se permanecessem acessíveis. Eles o enfraqueceriam se apenas pesquisadores estabelecidos conseguissem atender a padrões opacos de revisão.

O terceiro sinal é como outros programas de segurança respondem. HackerOne, Linux e grandes fornecedores estão todos experimentando regras de envio conscientes de IA.

Se convergirem em torno de reprodutibilidade e responsabilidade humana, o setor poderá desenvolver uma base compartilhada. Isso poderia reduzir a confusão para pesquisadores que trabalham em vários programas.

Se, em vez disso, os programas adotarem restrições incompatíveis, a divulgação se tornará mais difícil. Pesquisadores poderão precisar de diferentes pacotes de evidências, políticas de IA e práticas de confidencialidade para cada alvo.

Desenvolvedores também deveriam observar as próprias ferramentas. Agentes melhores podem produzir testes funcionais, mas podem gerar evidências inválidas com maior confiança.

O parâmetro-chave não é quantos alertas um agente encontra. É quantas descobertas relevantes para a segurança, reproduzíveis de forma independente, sobrevivem à revisão de especialistas.

Mantenedores deveriam acompanhar o tempo gasto por vulnerabilidade aceita, e não a contagem bruta de envios. Essa métrica capta se a automação melhora a segurança ou apenas amplia a fila.

Equipes de pesquisa podem se preparar documentando cada etapa do trabalho assistido por IA. Salvem o commit testado, a configuração, os logs, as entradas e as tentativas de reprodução malsucedidas.

As equipes também precisam de um registro pesquisável de descobertas anteriores. Uma base de conhecimento de engenharia estruturada pode ajudar a identificar duplicados antes que cheguem aos mantenedores.

Pesquisadores deveriam conseguir explicar a falha sem depender de texto gerado. Devem saber por que o caminho de código é alcançável e qual controle existente falha.

Se essa explicação estiver ausente, a descoberta ainda é uma hipótese. Ela não está pronta para um programa de recompensas por vulnerabilidades.

A suspensão do Google OSS VRP é, portanto, um alerta sobre o desenho do fluxo de trabalho, não um veredito contra a pesquisa de segurança com IA. A descoberta acelerou, mas a verificação não desapareceu.

A atualização do Google no 1º trimestre de 2027 testará se um grande fornecedor consegue reconstruir um programa aberto em torno dessa realidade. O melhor resultado não maximizaria os envios.

Ele maximizaria o valor de segurança verificado por hora de atenção do revisor. Esse padrão dá aos pesquisadores sérios um alvo claro e protege mantenedores contra volume especulativo.

Antes de enviar uma descoberta assistida por IA a qualquer lugar, faça três perguntas. Outra pessoa consegue reproduzi-la, ela atravessa um limite de segurança real e você testou cada alegação principal?

Se alguma resposta for não, continue investigando. O relatório mais barato de gerar pode se tornar o mais caro para um mantenedor refutar.