A segurança por IA chegou a um ponto curioso: a mesma tecnologia capaz de acelerar a descoberta de vulnerabilidades agora também está criando trabalho suficiente para sobrecarregar as equipes responsáveis por verificar e corrigir essas falhas. O Google acaba de expor esse paradoxo ao suspender temporariamente parte de seu programa de recompensas para vulnerabilidades em projetos de código aberto.
A partir de 1º de outubro de 2026, o Open Source Software Vulnerability Reward Program (OSS VRP) deixou de aceitar novos relatórios de vulnerabilidades de produtos. A decisão veio depois de uma forte alta nas submissões automatizadas, sendo que, segundo o próprio Google, a grande maioria não era válida.
O problema vai além de simplesmente receber alguns relatórios ruins. Com ferramentas de IA capazes de analisar grandes quantidades de código e produzir relatórios convincentes em segundos, a triagem humana passou a enfrentar um novo gargalo: separar uma vulnerabilidade realmente explorável de uma hipótese criada por um modelo que parece tecnicamente correta, mas não corresponde ao funcionamento real do software.
O paradoxo da segurança por IA e a suspensão do OSS VRP
Lançado em 2022, o OSS VRP foi criado para recompensar pesquisadores que encontrassem vulnerabilidades nos projetos de código aberto do Google. O programa contempla projetos importantes do ecossistema, incluindo Go, Angular e Protocol Buffers, além de questões relacionadas à cadeia de suprimentos e à infraestrutura dos repositórios.
Em março de 2026, porém, o Google já havia identificado uma mudança importante no comportamento das submissões. A empresa informou ter observado um forte aumento nos relatórios gerados por IA, incluindo explicações incorretas sobre como uma vulnerabilidade poderia ser explorada e problemas encontrados em trechos de código que sequer eram alcançáveis.
Na ocasião, o Google endureceu os critérios do programa. Para determinadas categorias de vulnerabilidades, passou a exigir evidências mais fortes, como uma reprodução utilizando OSS-Fuzz ou um patch efetivamente incorporado ao projeto. Também reorganizou os projetos em diferentes níveis de criticidade e retirou determinadas recompensas de vulnerabilidades em projetos classificados nos níveis inferiores.
A estratégia, entretanto, não resolveu completamente o problema. Em outubro, o Google decidiu interromper temporariamente o recebimento de novos relatórios de vulnerabilidades de produtos, enquanto reformula essa parte do programa. A empresa prometeu apresentar uma atualização no primeiro trimestre de 2027.
A enxurrada de relatórios e bugs alucinados
O ponto mais preocupante é que nem todo relatório tecnicamente plausível representa uma vulnerabilidade de segurança.
Um modelo de IA pode identificar, por exemplo, um possível buffer overflow e construir uma explicação detalhada sobre sua exploração. O problema aparece quando o trecho analisado não pode ser alcançado em condições reais ou quando o modelo ignora as proteções existentes no projeto.
É justamente esse tipo de situação que o Google descreveu em março. A empresa relatou casos de alucinações sobre a forma de exploração, além de erros de programação que, embora parecessem problemas legítimos em uma análise superficial, apresentavam impacto de segurança insignificante diante do modelo de ameaça do projeto.
Isso cria uma situação particularmente ruim para os mantenedores. Um pesquisador humano pode gastar horas validando uma hipótese antes de enviá-la. Um sistema automatizado pode gerar dezenas ou centenas de hipóteses em pouco tempo.
O custo, então, simplesmente muda de lugar.
A IA reduz o custo da descoberta de possíveis falhas, mas aumenta potencialmente o custo da validação humana. Se milhares de relatórios chegam simultaneamente, a equipe responsável precisa investigar cada alegação, reproduzir o comportamento, avaliar o impacto e determinar se existe realmente uma vulnerabilidade.
O resultado é uma espécie de inflação de relatórios: mais descobertas potenciais não significam necessariamente mais vulnerabilidades reais corrigidas.
Quais programas continuam funcionando
A suspensão não significa que o Google tenha encerrado todos os seus mecanismos de recompensa.
O bloqueio atinge especificamente novas submissões de vulnerabilidades de produtos dentro do OSS VRP. Relatórios relacionados a comprometimento da cadeia de suprimentos continuam sendo aceitos, assim como os relatórios que já haviam sido enviados antes da suspensão.
O Google também orienta pesquisadores a procurar impacto em outros programas de recompensa ou utilizar o Patch Rewards Program. Para determinados repositórios relacionados ao Google Cloud, vulnerabilidades que afetam produtos da nuvem podem continuar sendo avaliadas pelo Cloud VRP, conforme as regras específicas do programa.
Portanto, não se trata de fechar as portas para pesquisadores de segurança, mas de colocar em pausa uma categoria específica de entrada enquanto o Google tenta encontrar uma forma sustentável de lidar com o novo volume de submissões.
A ironia das ferramentas de IA do Google e o alerta do GrapheneOS
O episódio se torna ainda mais interessante porque o próprio Google está entre as empresas que mais investem em ferramentas de IA para segurança.
Um exemplo é o PageBreak, agente interno desenvolvido pela equipe de segurança de produtos do Google. O projeto começou como um piloto em novembro de 2025 e evoluiu para uma iniciativa mais ampla em janeiro de 2026, com o objetivo de automatizar a descoberta de vulnerabilidades em aplicações web próprias da empresa.
O Google reconhece exatamente o problema que agora aparece no OSS VRP: modelos de linguagem podem gerar uma quantidade enorme de possíveis vulnerabilidades, mas existe uma diferença fundamental entre encontrar uma hipótese e produzir uma prova de exploração válida.
O PageBreak foi desenvolvido justamente com mecanismos para reduzir esse ruído e produzir evidências mais concretas. Segundo informações divulgadas pelo Google, o projeto já ajudou a encontrar centenas de vulnerabilidades de cross-site scripting em aplicações internas.
A ironia é evidente. Quando a IA é controlada dentro de um ambiente com infraestrutura, dados, contexto e mecanismos de validação, ela pode ampliar a capacidade de uma equipe de segurança. Quando a mesma capacidade é usada para gerar relatórios em massa sem validação suficiente, ela pode transformar o sistema de recompensas em uma fila de triagem.
O GrapheneOS alerta para uma consequência ainda mais ampla desse fenômeno. O projeto afirma que o Google foi fortemente pressionado pelo volume de vulnerabilidades descobertas por modelos de IA, tanto internamente quanto externamente, e relaciona essa realidade a mudanças na política de disponibilização e retroportabilidade de correções do Android.
Segundo o projeto, o Google passou a restringir a retroportabilidade das correções mais importantes para versões mais recentes do Android, enquanto a descoberta acelerada de vulnerabilidades por IA aumenta a quantidade de trabalho necessário para analisar, corrigir e distribuir esses patches.
Para projetos independentes como o GrapheneOS, isso representa um desafio significativo. O projeto precisa acompanhar não apenas o código do Android, mas também um fluxo crescente de correções e vulnerabilidades relacionadas ao kernel Linux e a componentes externos.
A situação mostra que o problema não está limitado ao bug bounty. A IA está alterando o próprio ritmo da engenharia de segurança.
O futuro dos programas de bug bounty na era da inteligência artificial
A pausa do OSS VRP provavelmente não será um caso isolado. Programas de recompensas precisam se adaptar a uma realidade na qual produzir um relatório tecnicamente sofisticado deixou de ser uma tarefa necessariamente cara ou demorada.
O diferencial de um pesquisador, portanto, tende a migrar de encontrar algo suspeito para provar que aquilo representa um risco real.
Isso pode levar a programas de bug bounty mais exigentes, com maior utilização de provas de conceito, reproduções automatizadas, patches, testes de exploração e evidências que demonstrem impacto concreto. A própria reformulação iniciada pelo Google em março aponta nessa direção.
Também existe uma lição importante para o ecossistema de código aberto. Projetos com equipes pequenas não podem simplesmente absorver um crescimento ilimitado de relatórios de baixa qualidade. Cada falso positivo consome tempo que poderia ser usado para corrigir uma vulnerabilidade verdadeira, revisar código ou preparar uma atualização de segurança.
O paradoxo da segurança por IA, portanto, não está em a inteligência artificial ser ruim para a segurança. O problema está em tratá-la como uma máquina de produzir respostas definitivas quando, em muitos cenários, ela ainda funciona melhor como uma ferramenta para gerar hipóteses que precisam de validação especializada.
O Google agora tem até o primeiro trimestre de 2027 para mostrar como pretende resolver essa equação. A grande questão será descobrir como manter a velocidade proporcionada pela IA sem permitir que o volume de relatórios automatizados de bugs ultrapasse a capacidade humana de verificar aquilo que realmente importa.
No fim, a tecnologia que prometia ajudar pesquisadores a encontrar mais vulnerabilidades pode acabar obrigando os programas de recompensas a perguntar algo mais básico: quem vai verificar todas elas?
E essa talvez seja uma das principais questões de segurança da era da inteligência artificial. A IA pode acelerar a descoberta, mas ainda é necessária experiência humana para transformar uma suspeita em uma vulnerabilidade comprovada e uma vulnerabilidade em uma correção confiável.
