Google suspende relatos de falhas no open source: o custo dos alertas de IA sem prova

O Google suspendeu o recebimento de relatos de vulnerabilidades de produto no seu programa de recompensas para software open source. A empresa atribuiu a pausa ao aumento de envios automatizados, com uma maioria de relatos inválidos, no comunicado oficial do Google VRP.

A notícia voltou à cobertura em 4 de outubro. A mudança entrou em vigor em 1º de outubro de 2026, segundo as regras do programa.

Essa diferença de datas importa: a repercussão é de hoje, a decisão não. E o alcance também importa: o Google interrompeu uma categoria de relatos, não todos os seus programas de recompensa.

O que o Google suspendeu?

O OSS VRP é o programa do Google que recompensa pesquisadores por identificar falhas de segurança em software de código aberto da empresa. A pausa atinge novos relatos de vulnerabilidades de produto: defeitos no software que podem comprometer dados de usuários, conforme as regras oficiais.

O anúncio do Google VRP preserva os relatos de cadeia de fornecimento e os que já estavam pendentes. Cadeia de fornecimento é o caminho pelo qual código e pacotes chegam a quem usa o software.

O Google prometeu uma atualização no primeiro trimestre de 2027. Isso não equivale a uma data confirmada de reabertura.

Para alguns repositórios ligados a produtos Google Cloud, as regras ainda admitem relatos pelo Cloud VRP. A empresa também indica outros programas de recompensa e o Patch Rewards, voltado a melhorias de segurança, como alternativas.

Por que os relatórios automatizados viraram problema?

O motivo declarado pelo Google é o crescimento significativo de envios automatizados, cuja grande maioria não era válida. O comunicado oficial não informa quantos relatos chegaram, qual foi a taxa exata de rejeição ou quais modelos foram usados.

No trecho que explica a pausa, a empresa escreveu:

This pause is due to a significant rise in automated submissions, the vast majority of which are not valid.

Em português: a pausa ocorreu por um aumento significativo de envios automatizados, a grande maioria sem validade.

A reportagem do Tom’s Hardware associa esse volume a relatórios produzidos com IA e relata sobrecarga de engenheiros e mantenedores na checagem de falhas inexistentes ou sem exploração demonstrada. Essa descrição da sobrecarga vem da reportagem; o comunicado do Google confirma o volume automatizado e a baixa validade.

Um modelo pode descrever uma hipótese com linguagem convincente. Quem recebe precisa descobrir se o defeito existe, se alguém consegue explorá-lo e qual seria o impacto. Gerar a descrição e demonstrar a falha são trabalhos diferentes.

Que prova um relato de segurança precisa trazer?

As orientações do Google para reportar bugs pedem versão afetada, passos de reprodução, demonstração do problema e explicação do impacto. Esses elementos permitem que outra pessoa confira o resultado, em vez de depender da conclusão escrita pelo autor.

Um exemplo hipotético ajuda a enxergar a diferença. Um agente aponta que o cliente A consegue abrir um pedido do cliente B. O relatório só fica demonstrado quando um teste reproduz esse acesso nas condições descritas.

Se o sistema bloqueia a tentativa, a hipótese não se confirmou naquele teste. Um texto mais longo ou mais confiante não muda o resultado observado.

As regras também exigem que falhas na cadeia de fornecimento sejam exploráveis. Uma acusação de risco, sozinha, não demonstra o caminho até o dano.

O que isso muda para quem cria com IA?

Para quem desenvolve apps com IA, o caso sugere uma separação útil entre alerta levantado e problema reproduzido. Essa é a nossa leitura do episódio: o ganho de velocidade precisa incluir a checagem do resultado antes de transferir trabalho para outra pessoa.

Num app de vendas, por exemplo, um agente pode sugerir testes para permissões, descontos e acesso a pedidos. Cada hipótese pode ficar registrada junto da ação executada e do resultado observado. Assim, o criador consegue distinguir o que foi testado do que continua sendo uma suspeita.

O comunicado não demonstra que toda análise feita por IA seja inválida. Ele descreve um problema específico de volume e validade dos envios recebidos naquele programa.

Para aprender a construir seu próprio produto com IA, a Formação em Vibe Coding do ibe.IA é o caminho dedicado à criação de apps e sistemas.

Mais análises sobre ferramentas e criação com IA saem no Instagram do ibe.IA, @ibe.ia.