A IA barateou a descoberta de falhas. Corrigi-las agora é o gargalo

O custo da descoberta despencou

Encontrar uma vulnerabilidade plausível exigia antes habilidade, tempo e um entendimento sólido da base de código. Os grandes modelos de linguagem eliminaram a maior parte desse custo. Pesquisadores e ferramentas automatizadas agora conseguem gerar grandes volumes de relatórios candidatos contra projetos populares de código aberto em questão de horas. O problema é que o trabalho não termina na descoberta. Alguém ainda precisa reproduzir o problema, avaliar a gravidade, escrever a correção, revisá-la e entregá-la aos usuários. Nenhuma dessas etapas ficou mais barata.

Essa assimetria está forçando os programas de recompensa a mudar suas regras. A curl suspendeu seu programa de recompensas em janeiro de 2026. O Google endureceu seu programa de recompensas de código aberto em março de 2026, exigindo provas de maior qualidade, como uma reprodução com OSS-Fuzz ou uma correção incorporada, para certas faixas de pagamento. O Google afirmou que muitos relatórios gerados por IA incluem condições de acionamento alucinadas ou relatam falhas com pouco impacto real de segurança. Em abril, a HackerOne pausou os pagamentos do Internet Bug Bounty. O programa havia pago mais de US$ 1,5 milhão desde 2012 e historicamente destinava cerca de 80% das recompensas a novas descobertas e 20% ao apoio à correção.

A explicação da HackerOne é a declaração mais clara do problema até agora. A empresa disse que a pesquisa assistida por IA está ampliando a descoberta de vulnerabilidades em todo o ecossistema, aumentando cobertura e velocidade, e que o equilíbrio entre descobertas e capacidade de correção no código aberto mudou de forma substancial. O Node.js, um dos primeiros projetos afetados, continua aceitando relatórios pela HackerOne, mas não paga mais recompensas por eles.

Por que relatórios ruins saem caros

Um relatório errado não é gratuito para quem o recebe. O mantenedor precisa lê-lo, reproduzi-lo e explicar por que ele não funciona, muitas vezes em uma discussão cheia de trocas educadas, mas pouco úteis. Se o relatório descreve um caminho de acionamento que não existe, o mantenedor pode passar horas investigando um código que nunca é executado. Multiplique isso por dezenas de envios e uma equipe voluntária pode perder uma semana inteira só na triagem. Relatórios que parecem confiáveis mas estão errados custam mais do que os claramente ruins, porque não podem ser descartados de relance.

A resposta dos programas foi devolver o ônus da prova ao relator. Pedir uma reprodução com fuzzer, uma prova de conceito que rode na versão atual ou um patch obriga o relator a fazer parte do trabalho que, de outra forma, caberia ao mantenedor. Isso também filtra envios de autores que não executaram o código de fato.

Por que isso importa além do código aberto

O que está em jogo não é teórico. O Relatório de Investigações de Violação de Dados 2026 da Verizon constatou que cerca de 31% das violações agora se originam da exploração de vulnerabilidades de software, ante cerca de 20% no ano anterior. Nesse conjunto de dados, a exploração de vulnerabilidades ultrapassou o roubo de credenciais como principal via de acesso inicial. A maior parte do software corporativo é construída sobre componentes de código aberto, então um acúmulo de correções na origem vira um acúmulo em cada produto a jusante.

A cobertura da lacuna de financiamento também evidenciou a escala do problema. Segundo relatos, a Linux Foundation pediu ajuda financeira a empresas de IA, e Google, Anthropic, AWS, Microsoft e OpenAI se comprometeram juntas com US$ 12,5 milhões para o trabalho de segurança de código aberto. É um valor relevante, mas é uma contribuição pontual diante do trabalho contínuo de manter bibliotecas amplamente usadas.

O que deveria mudar

O movimento certo é pagar pela parte cara do trabalho. Descobrir falhas agora é barato; uma correção confirmada e entregue não é. Algumas mudanças decorrem disso.

• Os mantenedores deveriam escrever um critério de evidência explícito na política de segurança. Relatórios sem reprodução, teste que falha ou prova de conceito podem ser fechados automaticamente, com um modelo curto explicando o que é necessário. Configurar isso leva minutos e economiza horas depois.
• Os mantenedores deveriam tratar a revisão de patches como uma atividade com orçamento. Se um projeto depende de voluntários, o financiamento deve cobrir o tempo de revisão, não apenas os pagamentos por relatórios.
• Empresas que dependem de software de código aberto deveriam medir o tempo de correção, não o tempo de notificação. Uma equipe de segurança que conta quantos casos triou vai otimizar volume. Uma equipe que acompanha quanto tempo uma vulnerabilidade fica sem patch em suas dependências vai financiar o trabalho que importa.
• Plataformas de recompensa deveriam pagar mais por correções incorporadas do que por relatórios, e considerar pagar também pelos artefatos de reprodução antes de a triagem começar.
• Pesquisadores que encontram falhas reais deveriam enviar um patch junto com o relatório. Um patch que passa na suíte de testes é a coisa mais útil que um relator pode entregar a um mantenedor.

O que isso significa para sua equipe

Se você administra um produto que depende de componentes de código aberto, comece inventariando os projetos upstream de que depende e verificando se eles têm um processo ativo de resposta a segurança. Peça a seus fornecedores níveis de serviço para correções, não apenas resultados de varredura. Quando uma vulnerabilidade é reportada na origem, o tempo até uma versão corrigida é o número que determina sua exposição, e esse número depende da capacidade dos mantenedores, que você pode ajudar a financiar.

O problema da descoberta não vai desaparecer, e provavelmente não deveria. Encontrar mais falhas não é um fracasso em si. O fracasso seria continuar recompensando a etapa barata enquanto a etapa cara recai sobre alguns voluntários esgotados. Os programas que mudam suas regras agora estão tentando corrigir isso, e as equipes que dependem desse software também deveriam prestar atenção.