O ecossistema de segurança ofensiva e recompensas por vulnerabilidades enfrenta um ponto de inflexão operacional. A partir de 1 de outubro de 2026, o Google suspendeu temporariamente a aceitação de vulnerabilidades de produto submetidas ao Google Open Source Software Vulnerability Reward Program (abre em nova aba) (OSS VRP). A decisão foi motivada por um aumento expressivo no volume de submissões automatizadas de baixa qualidade, produzidas em larga escala por ferramentas de inteligência artificial, cuja imensa maioria carece de validade técnica.
A paralisação operacional afeta diretamente o fluxo de trabalho de desenvolvedores e pesquisadores que auditam o ecossistema de software mantido pela companhia em repositórios públicos. O congelamento não atinge relatórios já protocolados antes do início de outubro de 2026, tampouco compromete a análise de riscos voltados à integridade da cadeia de suprimentos de software (supply chain), que continuam ativos sob faixas específicas de remuneração.
Histórico e funcionamento do programa OSS VRP
Criado originalmente em 2022, o OSS VRP foi estruturado para incentivar a pesquisa e a correção de falhas em projetos de código aberto fundamentais para o ecossistema tecnológico global. Em termos de escopo de cobertura, a iniciativa contempla as versões mais recentes dos softwares armazenados nas organizações públicas do GitHub sob administração do Google, além de repositórios específicos hospedados em outras plataformas.
O modelo operacional do OSS VRP distribui os repositórios em níveis de criticidade (tiers), variando entre projetos classificados de OT0 a OT3. Os projetos categorizados como OT0 representam os ativos centrais de maior impacto estrutural, onde os comprometimentos de cadeia de suprimentos chegam a pagar recompensas que variam entre 3.133,70 dólares e 31.337,00 dólares.
Durante a evolução das diretrizes do programa, ajustes estruturais já vinham sendo implementados pela equipe de governança. Em março de 2026, a organização publicou alterações substanciais em suas regras de conformidade. Entre as restrições anunciadas naquele momento, os projetos alocados nos níveis inferiores (OT2 e OT3) deixaram de conceder créditos ou remunerações financeiras para a categoria de vulnerabilidades de produto e outros problemas genéricos de segurança.
Simultaneamente, para as categorias de topo (OT0 e OT1), o programa passou a exigir critérios analíticos mais rigorosos para validar corrupções de memória (memory corruption), exigindo a apresentação de passos exatos de reprodução via OSS-Fuzz ou a submissão de um patch de correção já integrado e aprovado no projeto. Essas mudanças pretendiam conter análises puramente teóricas ou incompletas, antecipando parte dos desafios que mais tarde levariam à paralisação total dos envios de produtos.
O impacto das submissões geradas por IA na triagem de segurança
A proliferação de modelos de linguagem aplicados à exploração de código fonte alterou de maneira substancial o perfil dos dados recebidos pelas equipes de triagem. Em vez de análises aprofundadas com vetores de ataque comprováveis, os canais de recebimento foram inundados por milhares de relatórios rasos. Engenheiros de segurança corporativos e mantenedores comunitários de projetos de código aberto ficaram sobrecarregados com o processamento diário dessa carga de dados.
A triagem de uma vulnerabilidade técnica exige verificação meticulosa: o analista precisa clonar o repositório, analisar o trecho apontado, compilar as dependências de acordo com o ambiente correto e executar uma prova de conceito (PoC). Quando esse processo precisa ser executado repetidamente sobre submissões sintéticas que não possuem lógica funcional, a produtividade técnica cai drasticamente, desviando horas de trabalho de falhas reais e críticas.
Para oficializar a interrupção aos participantes da comunidade de caçadores de bugs, a conta oficial do programa detalhou publicamente os motivos da pausa operacional:
📢 Aviso para caçadores de bugs em código aberto Não estamos mais aceitando, temporariamente, envios de vulnerabilidades de produto no OSS VRP. Isso não afeta os relatórios de cadeia de suprimentos do OSS VRP, nem relatórios pendentes. Como alternativa, incentivamos você a buscar impacto em nossos outros programas VRP e enviar por lá, ou buscar o Programa de Recompensas por Correções. Por que isso está acontecendo? Esta pausa se deve a um aumento significativo no envio de submissões automatizadas, cuja grande maioria não é válida. Continuaremos a reformatar e trabalhar neste aspecto do OSS VRP e nos comprometemos a fornecer uma atualização no primeiro trimestre de 2027.
Alucinações de modelos e problemas técnicos em relatórios automatizados
O fenômeno que culminou na saturação do OSS VRP está diretamente ligado às deficiências intrínsecas dos modelos geradores de texto e código. Na tentativa de encontrar falhas de forma indiscriminada, usuários passaram a alimentar códigos-fonte inteiros em prompts analíticos genéricos. Isso gerou duas classes principais de relatórios sem valor técnico:
- Submissões contendo alucinações técnicas completas: o modelo de IA inventa variáveis, funções inexistentes, chamadas de sistema incorretas ou fluxos de execução impossíveis, declarando vulnerabilidades hipotéticas que não encontram respaldo na arquitetura da biblioteca ou binário analisado.
- Relatórios com impacto irrelevante no mundo real: apontamentos mecânicos de más práticas teóricas ou advertências de compilador que não representam superfície de ataque executável nem geram desvios de privilégio, vazamentos de memória utilizáveis ou negações de serviço viáveis sob condições de produção.
A presença de alucinações é particularmente desgastante porque, visualmente, esses relatórios costumam apresentar formatação impecável. Ferramentas de IA redigem relatórios estruturados, detalhando seções de descrição teórica, cálculos de pontuação CVSS arbitrários e cenários de mitigação prolixos. Contudo, na hora da reprodução determinística por parte do engenheiro humano, constata-se a inconsistência total dos argumentos apresentados.
| Componente da Submissão | Relatório Técnico Tradicional | Envio Automatizado por IA |
|---|---|---|
| Validação de Prova de Conceito | Passos determinísticos, exploits funcionais ou casos de teste verificados | Textos conceituais ou scripts com bibliotecas e funções inventadas |
| Contexto do Ambiente | Especificação precisa de arquitetura, flags de compilação e dependências | Parâmetros vagos ou comandos genéricos copiados de documentações |
| Impacto Prático no Alvo | Demonstração clara de comprometimento no modelo de ameaça | Suposições de severidade máxima para divergências sintáticas menores |
| Esforço de Triagem Humana | Verificação focada na severidade e desenvolvimento da correção | Tempo consumido na refutação de afirmações factualmente inexistentes |
Limitações do escopo mantido e rotas alternativas
A suspensão em vigor desde 1 de outubro de 2026 delimita com precisão o que está paralisado e o que permanece operacional dentro da infraestrutura de recompensas mantida pela organização. Pesquisadores e mantenedores precisam observar os canais válidos para não terem seus envios descartados sumariamente.
Em primeiro lugar, relatórios com foco em comprometimentos da cadeia de suprimentos continuam em escopo. Ataques dessa natureza envolvem adulterações em infraestruturas de integração contínua (CI/CD), envenenamento de dependências ou manipulação maliciosa de artefatos de compilação, onde a tabela de prêmios de até 31.337,00 dólares permanece vigente para alvos OT0.
Em segundo lugar, a restrição de produtos abertos do OSS VRP não extinguiu completamente as vias para certos repositórios específicos. Para alguns repositórios ligados ao Google Cloud que impactem de fato os produtos corporativos dessa divisão, os relatórios de vulnerabilidades de produto ainda podem ser encaminhados por meio do Cloud VRP. Adicionalmente, a companhia orientou a comunidade técnica a focar em iniciativas complementares, tais como o Patch Rewards Program, que remunera o envio e merge de correções proativas de segurança no ecossistema de software livre.
Reestruturação e perspectivas para a triagem automatizada
A interrupção formal nas submissões estender-se-á por todo o período restante de 2026. A equipe do Google assumiu o compromisso formal de emitir um posicionamento com as diretrizes atualizadas no primeiro trimestre de 2027. O tempo de inatividade será usado para reestruturar completamente a infraestrutura de recebimento e avaliação do OSS VRP.
O desafio central enfrentado pela plataforma consiste no desenvolvimento de mecanismos de filtragem avançados capazes de barrar o ruído automatizado sem afastar pesquisadores de segurança legítimos. Enquanto regras sintáticas simples não se mostram mais suficientes para mitigar submissões superficiais geradas por IA, o programa busca reformular seu arcabouço para priorizar envios munidos de validações automáticas, a exemplo das exigências de harness de reprodução via OSS-Fuzz instituídas nos níveis OT0 e OT1.
O congelamento operacional do OSS VRP exemplifica como o barateamento da automação textual por meio de inteligência artificial desequilibrou a economia dos programas de recompensas por bugs. Sem a capacidade de aferir empiricamente o comportamento do software antes de protocolar um relatório, a facilidade de gerar textos complexos transformou canais abertos de colaboração em gargalos intransponíveis para a engenharia de segurança humana.