Suspensão do Google OSS VRP expõe o custo oculto dos relatos de bugs por IA

O Google deixou de aceitar novos envios de vulnerabilidades de produtos por meio de seu programa de recompensa para código aberto em 1º de outubro, após relatos inválidos gerados por IA sobrecarregarem seu processo de revisão. A suspensão do Google OSS VRP não encerra todas as partes do programa. No entanto, ela fecha uma importante via de reporte até que o Google conclua uma reformulação.

O problema imediato não é que a inteligência artificial não consiga encontrar falhas de software. Sistemas de IA já estão descobrindo defeitos válidos em grandes bases de código amplamente revisadas. O problema é que gerar um relato plausível agora custa muito menos do que provar seu impacto na segurança.

Esse desequilíbrio transformou a triagem de vulnerabilidades no recurso escasso. O Google precisa separar descobertas reais de caminhos de ataque alucinados, código inacessível, duplicatas e erros comuns de programação. O GitHub, os mantenedores do Linux e projetos menores de código aberto enfrentam a mesma pressão.

O Google afirma que os relatos enviados antes do prazo ainda serão considerados. Relatos de cadeia de suprimentos continuam abertos, enquanto determinadas falhas em repositórios do Google Cloud podem usar o Cloud Vulnerability Reward Program. A empresa espera fornecer outra atualização até o primeiro trimestre de 2027.

A pausa expõe um conflito revelador. A IA promete ampliar a pesquisa defensiva em segurança, mas a automação não verificada pode consumir a atenção humana necessária para corrigir vulnerabilidades genuínas. O futuro da caça a bugs com assistência de IA agora depende menos do volume bruto de descobertas e mais da qualidade das evidências.

A suspensão do Google OSS VRP é limitada, mas imediata

O Google congelou uma categoria de envios, sem abandonar sua relação mais ampla com pesquisadores externos de segurança.

O programa afetado é o Open Source Software Vulnerability Reward Program, normalmente chamado de OSS VRP. O Google o lançou em 2022 para recompensar pesquisadores que divulgassem de forma responsável vulnerabilidades que afetassem projetos elegíveis de código aberto.

O programa abrange software mantido em repositórios públicos pertencentes ao Google e projetos selecionados hospedados em outros lugares. Seu escopo incluiu tanto vulnerabilidades de produtos quanto comprometimentos da cadeia de suprimentos. Essas categorias tratam de riscos diferentes e agora seguem caminhos de envio distintos.

Vulnerabilidades de produtos dizem respeito a defeitos no código, na lógica ou no design de um projeto. Um relato convincente precisa demonstrar que atacantes podem alcançar o defeito e produzir consequências significativas para a segurança. Apenas identificar uma função aparentemente insegura não comprova exploração.

Relatos de cadeia de suprimentos dizem respeito a ameaças à forma como o software é compilado, empacotado, assinado ou distribuído. Um pipeline de lançamento comprometido pode disseminar código malicioso mesmo quando o código-fonte subjacente parece legítimo. O Google manteve essa categoria de relatos aberta.

A suspensão se aplica a novos relatos de vulnerabilidades de produtos enviados em ou após 1º de outubro de 2026. Envios anteriores continuam elegíveis para revisão sob o processo anterior. O Google também direcionou pesquisadores a seus outros programas de recompensa por vulnerabilidades, quando aplicável.

Alguns relatos envolvendo repositórios do Google Cloud ainda podem se qualificar pelo Cloud VRP. Essa exceção depende de a questão afetar um produto do Google Cloud, e não apenas de o repositório de código pertencer ao Google.

O Google anunciou a mudança por meio de sua conta Bug Hunters no X. Segundo o primeiro relato detalhado publicado, a empresa vinculou sua decisão a um influxo de envios inválidos impulsionados por IA.

A pausa segue meses de endurecimento, e não uma reviravolta repentina. Em uma atualização de regras de abril, o Google descreveu um aumento de relatos inválidos e de baixa qualidade chegando ao OSS VRP.

O Google identificou dois padrões recorrentes. Alguns envios continham explicações alucinadas sobre como uma suposta vulnerabilidade poderia ser acionada. Outros encontravam erros reais de codificação, mas não conseguiam demonstrar código alcançável ou impacto material na segurança.

Essa distinção importa porque defeitos de software e vulnerabilidades de segurança não são intercambiáveis. Uma falha em um utilitário de teste inacessível tem consequências diferentes da execução remota de código em um serviço de produção.

O Google já havia deixado de oferecer recompensas ou crédito por determinadas vulnerabilidades de produtos e outras questões de segurança em níveis de projetos de menor prioridade. Também enfatizou descobertas acionáveis, etapas verificadas de reprodução e demonstrações de impacto.

A ação de outubro, portanto, amplia um esforço existente para reduzir o ruído. Em vez de ajustar a elegibilidade enquanto os relatos continuavam chegando, o Google fechou o canal de recebimento afetado durante uma reformulação mais ampla.

A empresa não divulgou o número exato de relatos rejeitados, o tamanho de seu acúmulo ou sua taxa de aceitação. Alegações sobre milhares de envios continuam sendo números reportados, e não estatísticas completas do programa.

Essa ausência de dados limita a análise externa. Ainda assim, a sequência de mudanças nas regras, avisos públicos e o congelamento final mostra que a filtragem incremental não resolveu o problema de carga de trabalho.

Por que relatos inválidos de bugs por IA comprometem a triagem de segurança

A IA altera a economia dos relatos porque os envios escalam automaticamente, enquanto a validação ainda exige julgamento humano escasso.

A pesquisa tradicional de vulnerabilidades exige várias etapas custosas. Um pesquisador precisa entender o alvo, identificar uma fraqueza, construir um ataque reproduzível, avaliar o impacto e comunicar o resultado com clareza.

Grandes modelos de linguagem podem acelerar partes desse trabalho. Eles podem inspecionar código-fonte, sugerir fluxos de dados perigosos, redigir casos de teste e transformar anotações preliminares em texto polido. Agentes automatizados podem repetir essas etapas em muitos repositórios.

As mesmas ferramentas também podem produzir explicações confiantes, mas falsas. Um modelo pode presumir que atacantes controlam uma entrada que permanece confiável. Pode ignorar uma verificação de permissões, interpretar mal uma configuração de implantação ou inventar um caminho de execução alcançável.

Essas falhas se tornam caras após o envio. Um engenheiro de segurança não pode rejeitar um relato de aparência crível com base no tom. Ele precisa inspecionar o código citado, reproduzir as condições, rastrear os dados e testar se o impacto alegado existe.

Assim, um relato falso pode levar minutos para ser criado e horas para ser descartado. Mil relatos semelhantes transformam esse desequilíbrio em uma negação de serviço operacional, mesmo sem intenção maliciosa.

A apresentação do relato pode agravar o problema. Modelos de linguagem produzem facilmente narrativas extensas de vulnerabilidades, rótulos de severidade, diagramas de ataque e recomendações de mitigação. Nenhum desses acréscimos substitui uma reprodução funcional.

Uma linguagem polida pode até elevar os custos de triagem. Revisores precisam localizar a alegação factual em meio a páginas de contexto gerado. Também precisam determinar quais afirmações vieram de testes e quais vieram de inferência do modelo.

As regras anteriores do Google se concentravam nessa diferença entre detecção e validação. Um alerta de um analisador estático pode identificar código suspeito. Ele não prova automaticamente que o código cria uma violação explorável de um limite de segurança.

A alcançabilidade é um teste essencial. Revisores precisam de evidências de que uma entrada não confiável pode chegar à operação perigosa em condições realistas. Os relatos também devem considerar sanitização, privilégios, configuração e defesas existentes.

O impacto é outro teste. Um estouro de buffer parece sério, mas sua localização e os controles ao redor determinam o que um atacante pode alcançar. Algumas falhas apenas encerram um processo isolado, sem expor dados ou controle.

A novidade também importa. Sistemas automatizados podem redescobrir problemas conhecidos, repetir teorias anteriormente rejeitadas ou produzir várias descrições da mesma causa raiz. Cada duplicata ainda consome capacidade de recebimento e revisão.

Essa carga de trabalho recai sobre pessoas especializadas. Mantenedores experientes e engenheiros de segurança entendem pressupostos arquiteturais que modelos frequentemente deixam passar. Desviá-los para validações repetitivas atrasa correções, auditorias, revisões de design e resposta a incidentes.

O custo de oportunidade vai além do Google. Projetos de código aberto frequentemente contam com pequenos grupos de mantenedores, mesmo quando seu código sustenta serviços amplamente utilizados. Uma campanha automatizada de relatos pode exceder toda a capacidade de segurança deles.

As equipes podem preservar o contexto mantendo decisões, reproduções e descobertas anteriores em uma base de conhecimento de engenharia pesquisável. Essa prática reduz investigações repetidas, mas não elimina a necessidade de verificação por especialistas.

A pausa no programa de recompensa por bugs do Google torna essa restrição de mão de obra visível. Os programas de segurança foram concebidos em torno de envios que carregavam esforço significativo do pesquisador. A IA permite que o remetente transfira grande parte desse esforço à equipe que recebe o relato.

Relatos de bugs por IA criam um problema de qualidade, não uma proibição da IA

O conflito central é entre pesquisa verificada e automação não verificada, não entre pesquisadores humanos e inteligência artificial.

O Google não argumentou que pesquisadores devam evitar totalmente a IA. Sua posição declarada é que as pessoas precisam validar a saída da IA durante a pesquisa. Essa exigência trata a IA como um instrumento, e não como um relator responsável.

Um envio útil com assistência de IA ainda pode incluir evidências diretas. Pesquisadores podem fornecer versões afetadas, comandos exatos, casos de teste minimizados, logs, capturas de tela e resultados observados. Também podem explicar o limite de segurança violado.

A questão decisiva é se uma pessoa confirmou a alegação. Uma hipótese gerada por modelo se torna valiosa quando testes comprovam que o código relevante é alcançável e que o resultado afeta confidencialidade, integridade ou disponibilidade.

Esse padrão protege a automação legítima. Fuzzers geram descobertas de segurança há anos ao enviar entradas inesperadas e registrar falhas. Seu valor vem de resultados concretos e reproduzíveis, e não de descrições persuasivas.

Agentes de IA podem ampliar esse modelo. Eles podem raciocinar sobre código-fonte, criar harnesses, investigar falhas e propor correções. Seu espaço de busca mais amplo pode revelar defeitos que ferramentas convencionais não detectam.

No entanto, sistemas de raciocínio introduzem outro modo de falha. Eles podem preencher evidências ausentes com linguagem plausível. Um scanner convencional normalmente relata o padrão que detectou, enquanto um modelo de linguagem pode inventar toda uma narrativa de ataque.

Essa diferença explica por que programas de divulgação não podem simplesmente pontuar relatos pela fluência. Revisores precisam de artefatos ligados a comportamento observável. Alegações sobre consequências teóricas merecem menos confiança do que resultados demonstrados.

A evidência mais forte contra uma rejeição generalizada da IA vem de trabalhos bem-sucedidos de segurança com IA. Sistemas de IA encontraram vulnerabilidades genuínas em grandes projetos de código aberto, incluindo falhas que revisores humanos não haviam percebido.

Esses resultados mostram por que proibir todos os relatos assistidos por IA seria míope. Equipes defensivas querem uma cobertura mais ampla, especialmente em grandes grafos de dependências e bases de código maduras. Elas não querem especulação ilimitada e não testada.

O próprio Google usa IA em pesquisa defensiva de segurança. Seu trabalho de segurança mais amplo inclui descoberta de vulnerabilidades com assistência de IA e fuzzing de código aberto. A objeção da empresa diz respeito à qualidade da validação na fronteira de reporte.

Esse limite cria uma questão de responsabilização. Quando um agente autônomo envia um relatório, quem responde às perguntas de acompanhamento? Alguém precisa esclarecer as premissas, modificar a reprodução e distinguir o comportamento observado do comportamento previsto.

Um relatório sem um pesquisador responsável transfere essas tarefas ao mantenedor. O destinatário passa a ser responsável por concluir a investigação iniciada pelo remetente.

A divulgação clara do uso de IA pode ajudar, mas a divulgação por si só não estabelece qualidade. Um relatório escrito por uma pessoa também pode estar errado. Um relatório gerado por IA pode estar correto, conciso e exaustivamente testado.

Portanto, os programas precisam de barreiras baseadas em evidências, e não de detectores de estilo. Classificadores de texto de IA podem rotular incorretamente textos técnicos, especialmente quando pesquisadores usam modelos ou escrevem em um segundo idioma.

Um sistema de recebimento melhor testa o conteúdo do relatório. Ele pode exigir uma reprodução mínima, detalhes do ambiente, commits afetados, prova de alcançabilidade e uma explicação direta das capacidades do atacante.

A suspensão do Google OSS VRP dá à empresa tempo para desenvolver essas barreiras. O risco é que um sistema mais rigoroso também exclua novos pesquisadores qualificados que não têm reputação, mas possuem uma descoberta válida.

Essa troca não pode desaparecer. Programas abertos atraem descobertas inesperadas porque qualquer pessoa pode participar. Restringir o acesso melhora a qualidade média, mas reduz a chance de que um pesquisador desconhecido chegue à equipe certa.

GitHub e mantenedores de código aberto estão reforçando a mesma barreira

A decisão do Google faz parte de uma mudança em toda a indústria, que sai de um recebimento aberto em direção à reputação, às evidências e a canais de envio mais restritos.

O GitHub enfrentou seu próprio acúmulo de relatórios de baixo esforço e gerados por IA durante 2026. Em resposta, reestruturou seu programa de recompensas e criou caminhos separados para pesquisadores públicos e convidados.

O programa público adicionou uma exigência de sinal do HackerOne, que usa o histórico anterior de um pesquisador na plataforma como medida de elegibilidade. O programa por convite oferece uma rota distinta para pesquisadores com confiança já estabelecida.

O GitHub afirmou que seu objetivo era reduzir o volume de baixo esforço enquanto preservava pesquisas externas sérias. Seu anúncio de reestruturação aplicou a nova estrutura a relatórios enviados a partir de 27 de julho de 2026.

Orientações anteriores explicavam quais evidências a plataforma considerava úteis. Um relatório forte precisava de um resumo conciso, etapas de reprodução com artefatos de apoio e uma declaração clara do impacto que um atacante poderia alcançar.

O GitHub também alertou que narrativas teóricas e conteúdo gerado por IA como preenchimento atrasavam a triagem. O problema não era apenas conteúdo impreciso. Explicações excessivas podiam ocultar a descoberta real e atrasar a revisão.

Google e GitHub escolheram respostas imediatas diferentes. O GitHub manteve uma rota pública com barreiras mais fortes de reputação e qualidade. O Google pausou uma categoria do OSS VRP, enquanto manteve outros programas de vulnerabilidades disponíveis.

Ambas as abordagens protegem a atenção dos revisores. Elas também criam atrito para novos pesquisadores que ainda não construíram reputações nas plataformas. Um excelente primeiro relatório pode vir de alguém sem um longo histórico de recompensas.

Mantenedores de código aberto enfrentam uma versão ainda mais aguda desse problema. Muitos projetos não têm equipe dedicada de segurança, times pagos de triagem nem infraestrutura formal de envio. Um mantenedor pode revisar relatórios durante seu tempo pessoal.

As orientações do setor atribuem cada vez mais responsabilidade aos dois lados. A Open Source Security Foundation aconselha pesquisadores a verificar descobertas, entender as políticas do projeto e divulgar claramente como a IA contribuiu para o trabalho.

Sua orientação para mantenedores também reconhece que a IA pode apoiar análises defensivas legítimas. A resposta recomendada se concentra em integração segura e revisão humana.

O padrão mais amplo se assemelha ao controle de spam. Quando enviar se torna quase gratuito, os destinatários precisam introduzir filtros, sinais de reputação, limites de taxa ou custos de envio. Caso contrário, o volume de baixa qualidade supera a comunicação valiosa.

Programas de recompensa por bugs não podem copiar exatamente os filtros comuns de spam. Relatórios de segurança contêm detalhes técnicos inéditos e frequentemente chegam de pesquisadores desconhecidos. Rejeitar conteúdo incomum de forma agressiva demais pode ocultar a descoberta mais importante.

Os programas provavelmente combinarão vários controles. Formulários estruturados podem exigir respostas concretas. Verificações automatizadas podem testar se os artefatos exigidos existem. A reputação pode determinar limites de envio, em vez de elegibilidade absoluta.

Limites de taxa podem se tornar especialmente importantes para agentes autônomos. Uma pessoa pode revisar vários candidatos gerados por máquina e enviar apenas os mais fortes. Um sistema sem supervisão pode inundar um programa antes que os mantenedores forneçam feedback.

Depósitos ou garantias reembolsáveis de envio criariam custos mais fortes, mas levantam preocupações de acesso. Pesquisadores em regiões de menor renda poderiam enfrentar barreiras desproporcionais. A complexidade jurídica e administrativa também aumentaria.

Programas privados ou apenas por convite evitam o volume público, mas perdem a participação ampla. Eles concentram a confiança entre pesquisadores conhecidos, potencialmente deixando de fora pessoas com conhecimento especializado sobre um componente específico.

A reformulação do Google, portanto, tem implicações além de uma empresa. Outros operadores de programas observarão se ela restaura o sinal sem fechar a porta para novos talentos.

Filtros mais rígidos também podem ocultar vulnerabilidades reais

Reduzir o ruído da IA é necessário, mas cada filtro cria a possibilidade de que um relatório válido e incomum nunca chegue ao engenheiro certo.

O Google descreveu os motivos da pausa, mas não publicou dados completos de desempenho. Pessoas de fora não podem comparar as taxas de falsos positivos antes e depois da adoção de IA, nem medir a gravidade real do acúmulo.

Sem esses números, várias interpretações continuam possíveis. Envios gerados por IA podem dominar a fila, ou um grupo menor de remetentes repetitivos pode gerar a maior parte da carga. Causas diferentes exigem controles diferentes.

A qualidade dos modelos subjacentes também importa. Uma política elaborada em torno das taxas atuais de alucinação pode envelhecer rapidamente. Agentes melhores podem produzir reproduções mais robustas, mas também podem gerar volumes maiores de relatórios.

O desenho do programa precisa distinguir confiança de evidência. Um agente que atribui alta probabilidade à exploração não provou a exploração. Por outro lado, um relatório incompleto ainda pode descrever uma falha grave que merece acompanhamento.

Novos pesquisadores frequentemente enviam relatórios imperfeitos porque não têm experiência com divulgação. Sua escrita pode se parecer com resultados automatizados de baixa qualidade, mesmo quando a observação subjacente é genuína.

Idioma e acessibilidade criam riscos semelhantes. Exigir inglês refinado pode prejudicar pesquisadores com profundo conhecimento técnico. Os formulários devem exigir evidências específicas sem transformar estilo em um substituto para credibilidade.

Barreiras de reputação também reforçam o acesso anterior. Pesquisadores estabelecidos recebem mais oportunidades para construir sinal, enquanto recém-chegados lutam para entrar. Um ciclo fechado pode melhorar a eficiência, mas enfraquecer a diversidade.

A automação no lado do recebimento apresenta outra incerteza. O Google pode usar modelos para resumir, desduplicar ou priorizar relatórios. Esses sistemas exigem auditoria porque um falso negativo traz consequências diferentes de um falso positivo.

Um falso positivo desperdiça o tempo dos revisores. Um falso negativo pode deixar uma vulnerabilidade sem descoberta. Portanto, os sistemas de recebimento devem automatizar encaminhamento e verificações de evidências mais prontamente do que a rejeição final.

Recursos oferecem uma salvaguarda. Um pesquisador rejeitado deve entender qual elemento falhou e se evidências adicionais podem reabrir o relatório. Mensagens genéricas de rejeição incentivam novos envios e frustração pública.

Exemplos transparentes também podem melhorar o comportamento. Os programas podem publicar casos anonimizados que mostrem código inacessível, alegações de impacto sem suporte, origens de duplicatas e reproduções aceitáveis.

O Google já oferece orientações de relato em todos os seus programas de vulnerabilidades. Seu framework de qualidade enfatiza informações sobre o alvo, reprodutibilidade, impacto e comunicação.

A reformulação precisa decidir se esses padrões se tornam pré-requisitos aplicados por máquina. Ela também deve determinar quais relatórios merecem discrição humana apesar de não preencherem um campo formal.

Há outro perigo em enquadrar todo envio indesejado como conteúdo ruim de IA. O rótulo pode obscurecer divergências genuínas sobre modelos de ameaça. Pesquisadores e fornecedores frequentemente avaliam a explorabilidade de maneiras diferentes.

Uma empresa pode rejeitar um problema porque um atacante precisa de interação do usuário. Um pesquisador pode argumentar que a interação ainda é realista. Essas disputas são anteriores à IA generativa e não podem ser resolvidas por meio da detecção de autoria.

A mesma cautela se aplica a defeitos comuns de código. Alguns bugs não têm impacto imediato, mas se tornam perigosos após outra mudança de produto. Os programas precisam de limites, mas esses limites não devem ser confundidos com julgamentos universais sobre gravidade.

A suspensão é, portanto, uma intervenção de triagem, não uma prova de que os repositórios afetados se tornaram mais seguros. As vulnerabilidades continuam existindo enquanto uma rota de relato permanece fechada.

Os pesquisadores precisam identificar outro canal apropriado ou contatar diretamente o projeto relevante. Caminhos fragmentados de divulgação podem aumentar atrasos, publicação acidental e esforço duplicado.

O Google pode reduzir esse risco ao encaminhar claramente os relatórios excluídos. Seu diretório público de programas já separa escopos de Google, Cloud, Chrome, Android, IA, abuso e código aberto.

A reformulação só terá sucesso se pesquisadores válidos puderem prever o destino correto. Uma fila menor significa pouco se relatórios sérios desaparecerem entre regras sobrepostas de programas.

O que observar antes que o Google reabra relatórios de produtos

O próximo teste é se o Google substituirá uma caixa aberta de envio por um sistema que verifica evidências sem silenciar pesquisadores desconhecidos.

O primeiro sinal é a atualização prometida até o primeiro trimestre de 2027. O Google deve esclarecer se os envios de vulnerabilidades em produtos serão reabertos, transferidos para outro lugar ou retomados por meio de um processo de acesso limitado.

Uma reabertura com exigências estruturadas de evidências sustentaria a visão de que a suspensão foi uma triagem temporária. Um fechamento indefinido mostraria que o Google não considera mais sustentável o antigo modelo público.

O segundo sinal é o desenho da barreira de recebimento. Reproduções obrigatórias, versões afetadas, commits testados, rastros de execução e declarações concisas de impacto tratariam diretamente dos modos de falha documentados.

Restrições baseadas apenas em reputação representariam uma escolha diferente. Elas poderiam reduzir rapidamente o volume, mas atribuiriam mais peso ao histórico do pesquisador do que às evidências dentro de cada relatório.

O tratamento dado pelo Google aos agentes autônomos será especialmente importante. A empresa poderia exigir que uma pessoa identificada ateste que cada envio foi reproduzido. Também poderia impor limites de taxa aos relatos assistidos por máquina.

Uma política significativa deve separar a assistência de IA do envio em massa sem supervisão. Pesquisadores usam rotineiramente automação, depuradores, fuzzers, scanners e modelos de linguagem. A questão decisiva é quem valida e assume a responsabilidade pela alegação.

O terceiro sinal é se o acúmulo melhora sem reduzir as descobertas confirmadas. O Google não divulgou dados suficientes para essa comparação, mas transparência futura ajudaria outros programas a aprender com a reformulação.

Métricas úteis incluiriam volume de envios, tempo de validação, taxas de duplicação, descobertas aceitas, recursos de relatores e a parcela de relatórios com reproduções funcionais. Números agregados poderiam proteger detalhes sensíveis.

Pesquisadores também devem acompanhar os outros VRPs do Google. Se relatórios inválidos de bugs de IA migrarem para os canais de Cloud, Chrome ou gerais do Google, a suspensão terá apenas deslocado a carga de trabalho, em vez de resolvê-la.

O sistema mais amplo de recompensas por bugs da empresa continua ativo. O diretório de programas do Google ainda encaminha questões de segurança elegíveis para vários programas especializados.

Responsáveis por manutenção fora do Google não devem esperar pela política final. Eles podem definir as evidências aceitas, publicar modelos de ameaça, limitar submissões automatizadas e criar modelos que separem observações de impacto inferido.

Pesquisadores também podem se adaptar. Antes de enviar um relatório, devem reproduzir o comportamento, minimizar o caso de teste, confirmar a revisão afetada e explicar o acesso necessário ao invasor.

Devem remover o conteúdo gerado que não sustenta a descoberta. Um relatório curto, com evidências diretas, é mais fácil de validar do que um ensaio elaborado baseado em uma premissa incerta.

A pesquisa de segurança assistida por IA continuará se expandindo, pois seus benefícios legítimos são substanciais. Os modelos podem examinar mais código, gerar testes direcionados e ajudar investigadores a conectar componentes desconhecidos.

No entanto, o volume de descobertas já não é a melhor medida de progresso. Um relatório só se torna útil quando fornece aos responsáveis pela manutenção evidências confiáveis suficientes para agir.

A suspensão do OSS VRP do Google marca o momento em que essa distinção se tornou impossível de ignorar. O próximo desenho de programa deve recompensar insights verificados, preservar o acesso e manter a atenção humana focada no risco real.

Antes de enviar outra descoberta assistida por IA, faça uma pergunta mais difícil do que se o modelo encontrou código suspeito: outro engenheiro consegue reproduzir o impacto de segurança a partir das evidências fornecidas?