O Google deixou de aceitar novas submissões de vulnerabilidades de produto no Open Source Software Vulnerability Reward Program em 1º de outubro de 2026. A justificativa foi um grande aumento de relatos automatizados, em sua maioria inválidos. A empresa espera publicar outra atualização no primeiro trimestre de 2027.
É a pausa de uma categoria, não o encerramento de todo o sistema de recompensas nem uma proibição de pesquisa assistida por IA. O problema é mais específico: gerar uma alegação plausível ficou barato, mas demonstrar sua realidade ainda exige especialistas escassos.
O que fechou e o que permanece disponível
O Google criou o OSS VRP em 2022 para problemas elegíveis de segurança de código aberto. Vulnerabilidades de produto envolvem falhas de código, lógica ou projeto. A pausa de outubro vale para novas submissões dessa categoria; as anteriores continuam elegíveis à análise.
Relatos de cadeia de suprimentos permanecem abertos. Alguns problemas em repositórios Google Cloud podem entrar no Cloud VRP, conforme produto e regras. Outros programas, como Chrome, Android, dispositivos e segurança de IA, também continuam. Pesquisadores precisam verificar o escopo real em vez de presumir a mesma alternativa para todo repositório.
A suspensão veio depois de outras mudanças. As regras de 2026 exigiam validar achados assistidos por IA e demonstrar impacto real. Em abril, o Google retirou recompensas e reconhecimento público de certas categorias inferiores de vulnerabilidades de produto e outros problemas. Esses incentivos e requisitos mais estreitos não impediram a pausa posterior.
O Google não publicou contagem exata, taxa de aceitação ou tamanho da fila afetada. Reportagens secundárias mencionaram milhares de submissões fracas, mas esse número não aparece no aviso oficial. “Maioria inválida” demonstra um problema grave sem fornecer uma base estatística completa.
A substituição permanece indefinida publicamente. Reproduções testadas, limites de envio, identidade e triagem automática são possibilidades, não condições anunciadas de reabertura.
Um relato convincente pode não conter vulnerabilidade
Um modelo pode apontar uma operação suspeita, redigir uma narrativa de ataque e acrescentar uma avaliação profissional de gravidade. A operação talvez nunca receba dados controlados pelo atacante, seja inalcançável ou já esteja protegida. Um erro real de programação também pode não produzir consequência de segurança no modelo de ameaça do projeto.
Revisores precisam reconstruir essas condições. Inspecionam revisões, reproduzem o comportamento, avaliam proteções e procuram duplicatas. Uma função ou condição inventada pode ficar escondida numa explicação coerente. Boa apresentação já não substitui evidência de pesquisa.
Christopher Robinson, da Open Source Security Foundation, estimou em reportagem de março que projetos antes acostumados a dois ou três relatos semanais passaram a receber centenas de uma vez. Uma investigação poderia consumir de duas a oito horas inesperadas de manutenção. São observações atribuídas sobre vários projetos, não medições da fila do Google.
Recompensas podem agravar a assimetria. O remetente gera muitas hipóteses enquanto o destinatário assume a maior parte da validação. Duplicatas, gravidade exagerada e comportamento documentado mal interpretado competem com falhas reais. Mesmo volume bem-intencionado pode deslocar reparos.
A distinção relevante não é se um modelo ajudou a escrever. Tradução, explicação e geração de testes podem melhorar pesquisa séria. Uma pessoa ainda deve compreender o caminho alcançável, reproduzir o resultado e responder perguntas. Reescrever uma hipótese não testada em estilo humano não a valida.
Pesquisa validada impede uma rejeição geral da IA
O Google continua desenvolvendo defesas assistidas, incluindo OSS-Fuzz, Big Sleep e CodeMender. Equipes internas podem definir alvos, coletar evidência de execução e revisar patches. Um programa externo recebe materiais de diferentes ferramentas e ambientes sem a mesma cadeia controlada.
As recompensas gerais continuam significativas. O balanço anual registra mais de US$ 17 milhões para mais de 700 pesquisadores em 2025, aumento superior a 40% sobre 2024. São totais dos programas mais amplos, não orçamento ou produtividade da categoria OSS suspensa.
As reportagens oferecem outro contraste. A Anthropic afirmou que Claude Opus 4.6 encontrou mais de 500 vulnerabilidades desconhecidas em código aberto, todas validadas por pessoas ou especialistas externos antes da divulgação. A Mozilla recebeu 112 relatos em duas semanas e publicou 22 avisos, incluindo 14 de alta gravidade. Muitos achados restantes foram classificados como erros sem impacto de segurança.
As unidades precisam permanecer separadas: relatos, avisos e vulnerabilidades validadas não são contagens intercambiáveis. O exemplo apoia descoberta automatizada com validação especializada, não uma garantia para qualquer texto de modelo.
Triagem automatizada pode agrupar duplicatas e pedir evidência ausente, mas também erra. Dois modelos concordando oferecem menos suporte que um teste reproduzível de modo independente. Achados incomuns e divergências ainda exigem escalonamento humano.
Curl, Linux e HackerOne mudaram etapas diferentes
O curl encerrou recompensas monetárias em 31 de janeiro de 2026, após um programa iniciado em 2019. Daniel Stenberg relatou 87 vulnerabilidades confirmadas durante sua existência. Porém, a parcela de relatos confirmados caiu de mais de 15% anteriormente para menos de 5% em 2025.
Sua explicação combinou ruído de IA, piora de outros relatos e foco excessivo nas recompensas. O fim dos pagamentos não encerrou divulgação responsável: GitHub privado e e-mail continuaram disponíveis. A mudança mirou incentivos, aceitando o risco de desmotivar também pesquisadores independentes cuidadosos.
O Linux recebeu repetidamente os mesmos achados de pessoas usando ferramentas semelhantes. A divulgação privada escondia discussões e correções de outros pesquisadores, levando mantenedores a revisar o mesmo problema. Torvalds defendeu canais públicos para muitos achados facilmente redescobertos, salvo necessidade real de sigilo.
Isso não pede publicação de todo exploit sem correção. As regras do kernel enfatizam descrição concisa, revisão afetada, condições, reproduções testadas e impacto realista. Relatores devem entender o código, procurar os responsáveis corretos e contribuir com patch quando possível.
O HackerOne relatou crescimento superior a 100% no volume do setor após ferramentas mais capazes surgirem em fevereiro de 2026. Sua análise inclui achados úteis, duplicatas e alegações não verificáveis. A plataforma exige prova reproduzível, gravidade correta e consideração das defesas; grandes lotes não verificados podem gerar medidas de aplicação. É uma observação da plataforma, não a taxa de invalidade do Google.
As intervenções diferem: Google pausou uma categoria, curl removeu dinheiro e Linux ajustou expectativas e encaminhamento. A restrição comum é tempo especializado, sobretudo quando dependências comerciais são mantidas por voluntários.
Reabrir exige evidência e acesso para novos pesquisadores
Barreiras fortes protegem revisores, mas podem esconder falhas reais. Reputação favorece participantes estabelecidos. Depósitos e convites opacos excluem iniciantes. Exigir exploração completa também pode incentivar testes perigosos quando uma reprodução mínima controlada já demonstraria o problema.
Um bom pacote identifica commit, ambiente, influência do atacante, entrada e fronteira de segurança cruzada. Documenta o que foi realmente testado, separa inferência e observação e protege detalhes confidenciais. Não deveria exigir danos nem o envio de código sensível a um serviço hospedado não autorizado.
Filtros devem rejeitar ausência de evidência, não tratar estilo de IA como prova de invalidade. Não existe teste confiável de escrita para determinar se uma vulnerabilidade é real. Recursos e especialistas importam porque cadeias incomuns nem sempre cabem em formulários simples.
A próxima atualização mostrará se o Google reabre com exigências claras ou participação menor. Resultados úteis incluem confirmações, duplicatas, tempo de revisão e correção, carga e falsos rejeitados, não apenas menos mensagens. Experiências variam: a Mozilla antes relatou uma taxa estável de rejeição de materiais inválidos. O Google não define todo o ecossistema.
A separação construtiva é entre escala de descoberta e de submissão. Agentes podem investigar amplamente, mas pessoas devem receber achados validados, deduplicados e com responsáveis. A pausa não prova que IA não encontra bugs. Mostra que hipóteses ilimitadas só viram valor de segurança depois de demonstradas.
Fontes
Regras Google OSS · Carga dos mantenedores · Investigação de relatos falsos · Resultados validados da Mozilla · Decisão do curl · Base de engenharia · Notícia sobre a pausa · Mudanças anteriores do Google · Prêmios Google de 2025 · Análise de volume HackerOne · Regras de segurança Linux · TechCrunch sobre a pausa do Google · Techmeme sobre a pausa do Google