Google pausa bug bounty open source após aumento de relatórios inválidos gerados por IA

O Google interrompeu em 1º de outubro o recebimento de submissões em seu programa de recompensas para vulnerabilidades em software open source. A empresa atribuiu a decisão a um “aumento significativo” de envios automatizados e afirmou que a grande maioria não era válida. Uma atualização está prevista para o primeiro trimestre de 2027.

Segundo o relato do TechCrunch, participantes foram orientados a considerar outros programas de bug bounty do Google durante a pausa. A medida expõe um custo pouco visível da geração automática de relatórios: mesmo uma descoberta falsa precisa ser triada antes de ser descartada.

O que foi suspenso

O Open Source Software Vulnerability Rewards Program recompensava pesquisadores que encontrassem vulnerabilidades no software open source do Google. A suspensão atinge o recebimento de relatos relacionados a vulnerabilidades de produto dentro desse programa.

Há uma diferença de escopo entre as reportagens disponíveis. O TechCrunch descreve a pausa do programa open source, enquanto o Tom’s Hardware informa que parte do OSS VRP foi suspensa e que as submissões de vulnerabilidades de produto terminaram em 1º de outubro.

Fato da fonte: o Google confirmou a pausa e vinculou a decisão ao crescimento de submissões automatizadas inválidas. A empresa prometeu uma atualização, mas o material disponível não informa quais regras, filtros ou modalidades poderão mudar.

Também não é possível concluir que todos os outros canais de segurança do Google foram interrompidos. Ao contrário, a orientação aos participantes para procurar outros programas indica que a suspensão não deve ser interpretada como encerramento geral das recompensas por vulnerabilidades.

Como a automação pressiona a triagem

Um relatório de vulnerabilidade não se torna válido porque contém uma descrição tecnicamente plausível. A equipe responsável ainda precisa verificar se o componente indicado existe, se o comportamento pode ser reproduzido, se há impacto de segurança e se a condição reportada não é apenas comportamento esperado.

Segundo o Tom’s Hardware, engenheiros e mantenedores ficaram sobrecarregados por relatos inválidos ou contendo alucinações. O problema, portanto, não está apenas no volume. Relatórios produzidos por IA podem combinar termos corretos, trechos de código e cenários convincentes sem demonstrar uma vulnerabilidade real.

Interpretação editorial: a automação desloca o gargalo da descoberta para a validação. Gerar mais hipóteses fica barato, mas refutá-las continua consumindo atenção especializada. Se o remetente não executar essa etapa antes do envio, o custo é transferido para quem mantém o projeto.

Esse desequilíbrio é especialmente relevante em programas abertos: uma submissão pode ser produzida em escala, enquanto a análise exige contexto sobre o código, o modelo de ameaça e o comportamento pretendido do sistema.

O que muda para mantenedores

A pausa mostra que formulários e políticas criados para submissões humanas podem não ser suficientes quando relatórios passam a ser gerados em massa. Para tech leads, a consequência prática é tratar a entrada de relatos como uma fila potencialmente adversarial, mesmo quando não há intenção maliciosa.

Recomendação prática: antes de aceitar um relato para análise completa, vale exigir evidências mínimas e estruturadas:

• identificação precisa do componente afetado;
• passos reproduzíveis, sem depender apenas de uma explicação textual;
• resultado observado e resultado esperado;
• demonstração do impacto de segurança;
• separação entre fatos verificados e hipóteses geradas por ferramentas;
• declaração sobre o uso de automação ou IA na produção do relatório.

Esses requisitos não provam que a descoberta é válida. Eles apenas criam uma barreira inicial contra submissões que apresentam uma narrativa de vulnerabilidade sem evidência verificável.

Outra medida é separar classificação de confirmação. A primeira etapa verifica completude, duplicidade aparente e possibilidade de reprodução. Só depois o caso segue para análise de impacto. Isso evita que especialistas consumam o mesmo nível de esforço com todo conteúdo recebido.

IA não é o mesmo que evidência

O material apurado não demonstra que relatórios assistidos por IA sejam necessariamente ruins. A afirmação do Google é mais específica: houve crescimento significativo de submissões automatizadas, e a grande maioria delas não era válida.

Também não foram divulgados números absolutos, proporção exata de relatórios inválidos, custo da triagem ou taxa anterior de falsos positivos. Sem esses dados, não é possível medir a dimensão operacional do problema nem comparar a qualidade de envios humanos e automatizados.

A distinção importante para equipes de segurança é entre usar IA para auxiliar uma investigação e usar sua saída como substituta da investigação. Uma hipótese gerada automaticamente ainda precisa ser confrontada com o código e transformada em um caso reproduzível.

Quando automatizar faz sentido

A automação faz sentido quando ajuda a organizar achados, formular hipóteses e preparar evidências que o pesquisador efetivamente validou. Ela não faz sentido quando gera submissões em volume sem reprodução, impacto demonstrável ou revisão humana.

Para mantenedores, filtros mais rígidos fazem sentido quando a triagem ameaça consumir a capacidade destinada a corrigir problemas reais. Mas bloquear toda contribuição assistida por IA seria uma conclusão que as fontes não sustentam. Até a atualização prevista para o primeiro trimestre de 2027, o caso do Google deve ser lido como um alerta operacional: escala de geração sem escala equivalente de validação pode tornar um canal de segurança impraticável.