Google pausou relatos de falhas de produto em sua recompensa por bugs de OSS

Em 4 de outubro de 2026, o Google parou temporariamente de aceitar relatos de falhas de produto em sua recompensa por bugs de código aberto, enquanto manteve abertas as submissões sobre cadeia de suprimentos. Quatro anos antes, havia oferecido até US$ 31.337 para atrair relatos de vulnerabilidades de agentes externos. Uma parte desse convite agora estava suspensa.

Em 2022, o Google lançou seu OSS Vulnerability Reward Program para recompensar relatos sobre projetos de código aberto. Seu Vulnerability Reward Program mais amplo e separado pagou US$ 10 milhões a 632 pesquisadores em 2023. Os dois programas tinham escopos distintos, mas ambos usavam recompensas para direcionar atenção externa a falhas que um fornecedor poderia deixar passar.

Agentes de IA podem gerar relatos de bugs plausíveis a um custo menor sem necessariamente reduzir o trabalho necessário para verificá-los. Recompensas por bugs foram criadas para disputar descobertas escassas; sua restrição mais difícil está se tornando a capacidade de autenticar, reproduzir, eliminar duplicidades e agir sobre o que os pesquisadores submetem.

A recompensa comprava atenção quando encontrar uma falha era caro

Antes, um pesquisador precisava investir esforço considerável para inspecionar um alvo, desenvolver uma descoberta crível e prepará-la para divulgação coordenada antes que um fornecedor considerasse um pagamento. O fornecedor ainda precisava testar o relato, mas o trabalho do pesquisador filtrava muitas possibilidades fracas antes que chegassem à fila de entrada. As recompensas davam aos pesquisadores um lugar legítimo para enviar uma descoberta, um processo de divulgação e uma razão para examinar o software de um fornecedor em vez do de outro.

O programa de OSS do Google de 2022 aplicou esse acordo a projetos de código aberto. Uma recompensa maior poderia tornar um alvo difícil digno de inspeção, mas não ajudaria um revisor a reproduzir um relato falho.

A DARPA lançou seu AI Cyber Challenge em 2023 para desenvolver sistemas que examinam código aberto em busca de falhas de segurança. Em abril de 2026, a Bloomberg informou que a 360 Digital Security Group havia usado um agente movido por IA para descobrir cerca de 1.000 vulnerabilidades antes desconhecidas, incluindo falhas no Microsoft Office. Nenhuma das iniciativas prova que descobertas automatizadas sejam ruído. Ambas mostram como está ficando mais fácil produzir mais um candidato para revisão.

O Google fechou uma via de entrada, não o programa

Em 4 de outubro, o Google disse que temporariamente deixaria de aceitar submissões de vulnerabilidades de produto ao OSS VRP. Relatos sobre cadeia de suprimentos e relatos pendentes não foram afetados, e o Google planejava uma atualização até o primeiro trimestre de 2027. O Google restringiu uma categoria específica de entrada, em vez de abandonar a divulgação externa ou declarar sem valor a pesquisa gerada por IA.

O motivo relatado foi uma enxurrada de relatos inválidos movidos por IA. Alegações de que engenheiros e mantenedores de código aberto foram sobrecarregados por milhares de submissões descuidadas permanecem não verificadas. A pausa do Google não estabelece nem seu volume de submissões nem uma taxa de relatos inválidos para todo o setor.

Outros operadores encontraram o mesmo tipo de problema de capacidade. O projeto curl planejava encerrar seu programa de recompensas no HackerOne, citando relatos de baixa qualidade gerados por IA. O Financial Times informou que operadores de recompensas por bugs estavam adicionando verificações de antecedentes e criando agentes de triagem por IA. Um mantenedor que recebe uma alegação plausível ainda precisa estabelecer a versão afetada, reproduzir o comportamento, avaliar o impacto e determinar se alguém já o relatou. Mesmo um relato que falha nessas verificações consome tempo antes de poder ser descartado.

Uma descoberta ganha valor quando outra pessoa consegue testá-la

Um relato em prosa pode citar uma função real e descrever uma falha plausível sem estabelecer que o software se comporta como alegado. Uma submissão mais forte entrega ao destinatário uma versão afetada, um caminho para reproduzir o comportamento, evidências de impacto e proveniência suficiente para compará-la com relatos anteriores. Esses materiais permitem que um mantenedor conteste a alegação sem primeiro reconstruir toda a investigação do pesquisador.

A OpenAI apresentou o Codex Security como um agente que encontra, valida e propõe correções para vulnerabilidades. A OpenAI também afirmou que sua beta privada do Aardvark melhorou a qualidade do sinal, a precisão de severidade e as taxas de falsos positivos. As mesmas ferramentas que barateiam candidatos podem ajudar a testá-los. As alegações da OpenAI não estabelecem quanto trabalho de revisão desaparece na base de código de outra organização, mas colocam a validação dentro do produto, em vez de deixá-la para quem abre a caixa de entrada.

A Artificial Analysis e seus parceiros fizeram uma escolha relacionada na medição. Sua Cyber Index Alliance avalia agentes em encontrar e corrigir vulnerabilidades; o CWE-Bench-AA inclui 120 tarefas reservadas de auditoria e correção. Como ocorre com os benchmarks de programação com IA de forma mais ampla, uma pontuação só é útil na medida em que o teste captura o trabalho em que um destinatário precisa confiar. Encontrar uma linha suspeita é diferente de reproduzir um bug, e produzir um patch é diferente de mostrar que o patch não quebra o software.

Alguém ainda precisa decidir que nível de impacto justifica uma correção de emergência, quem é responsável pelo projeto afetado e quando a divulgação é responsável. Essas decisões exigem um registro que outro mantenedor possa inspecionar.

Descoberta mais rápida torna a passagem para o reparo mais importante

A iniciativa Daybreak da OpenAI combina modelos, Codex Security e parceiros de segurança para ajudar organizações a encontrar, validar e corrigir vulnerabilidades continuamente. Esse desenho conecta tarefas que um programa de recompensas pode, de outro modo, separar em filas diferentes: um pesquisador submete uma alegação, um revisor a verifica, um responsável a recebe e um mantenedor prepara uma correção. Quando qualquer passagem perde as etapas de reprodução ou a razão de uma decisão de severidade, a pessoa seguinte precisa repetir o trabalho.

Um verificador pode registrar o ambiente e o comportamento observado; um revisor pode anexar as decisões sobre duplicidade e severidade; um mantenedor pode testar um patch proposto contra o mesmo caso. Essa cadeia é o trabalho prático de garantia operacional de IA, embora ainda não se tenha demonstrado que os agentes atuais concluam todas as etapas de forma confiável.

O atraso também tem um custo adversarial. O Threat Intelligence Group do Google relatou o que descreveu como o primeiro caso conhecido de hackers usando IA para descobrir e transformar em arma uma vulnerabilidade zero-day. Esse relato não diz a um operador de recompensas que aceite submissões fracas mais rápido. Ele torna submissões precisas e reproduzíveis mais úteis: um fornecedor que não consegue distinguir uma falha real de um falso alarme persuasivo gasta tempo com ambos, enquanto um atacante precisa apenas da falha real.

O acesso confiável economiza tempo de revisão ao limitar quem entra

A triagem de participantes antecede a onda de relatos por IA. Em 2020, a empresa de tecnologia eleitoral ES&S fez parceria com a Synack para permitir que profissionais avaliados pela Synack testassem alguns de seus produtos. A avaliação deu à ES&S uma forma de permitir escrutínio externo enquanto decidia quem poderia conduzi-lo. A empresa aceitou uma participação mais restrita em troca de uma relação que podia governar.

O planejado programa de recompensas em dois níveis do GitHub faz essa troca na remuneração: recompensas menores para submissões públicas e pagamentos maiores para pesquisadores apenas por convite, em meio ao volume de relatos gerados por IA. A Apple introduziu um limite de submissões e um período de espera de 30 dias, permitindo que pesquisadores solicitem cotas maiores. Cada regra limita o trabalho que entra na fila de um revisor antes que ele saiba se uma alegação específica é válida.

Um pesquisador desconhecido pode encontrar uma falha que um grupo avaliado deixa passar, e um canal aberto pode alcançar partes de uma base de código que uma lista de convites não alcança. Verificações de antecedentes, cotas e reputação podem proteger o tempo dos mantenedores enquanto excluem trabalho útil. A validação assistida por máquina oferece outra forma de manter a porta mais aberta, desde que forneça evidências que um humano possa inspecionar, em vez de mais um veredito confiante a investigar.

O teto de US$ 31.337 do Google anunciava o valor de encontrar uma falha. Sua via fechada para falhas de produto mostrou o quanto uma alegação ainda precisa provar antes que esse prêmio signifique algo.