Pentest com IA: o gargalo não é achar, é provar

Em janeiro de 2026, o mundo inteiro recebeu 5.045 vulnerabilidades. Em agosto, recebeu 10.740. O número dobrou em oito meses, e a leitura ingênua é que o software ficou duas vezes mais inseguro. Não é isso. O Google Threat Intelligence Group publicou em 30 de setembro um estudo sobre exatamente esse ponto: das vulnerabilidades divulgadas em 2026, apenas 0,23% foram vistas em exploração ativa. Uma em cada 431. Este texto mostra o número que decide onde gastar o seu orçamento de segurança, e por que um relatório de pentest sem prova reproduzível virou trabalho de triagem.

O que o Google Threat Intelligence mediu

O relatório do GTIG cobre 20 meses de divulgações e medições de exploração, de janeiro de 2025 a agosto de 2026. Três números sustentam o resto do texto.

O primeiro é o volume: 5.045 divulgações em janeiro de 2026, 10.477 em julho e 10.740 em agosto, o pico. O segundo é a exploração: 141 vulnerabilidades distintas foram divulgadas e exploradas entre janeiro e agosto de 2026, acima das 127 exploradas em todo o ano de 2025. A média mensal saltou de 10,5 para 18.

O terceiro número é o que desmonta a lista. Só 0,23% das vulnerabilidades divulgadas em 2026 foram observadas em exploração ativa, algo da ordem de uma em cada 431. O GTIG insiste que o volume cru engana: a atribuição automática de números CVE em ecossistemas de código aberto infla a contagem. Vulnerabilidades cuja descrição apenas menciona “Linux Kernel” geraram cerca de 5.000 CVEs entre janeiro e agosto de 2026, com zero zero-day explorado observado.

Ou seja: boa parte do que chegou à sua mesa como “novo problema” não é o dobro de risco. É o dobro de texto.

Nem toda falha real é uma falha que importa

Vale olhar o outro lado da moeda, porque o estudo não é um manifesto contra IA. Entre as vulnerabilidades que o GTIG conseguiu atribuir a agentes autônomos em 2026, o perfil de risco inverte: 58% são de risco médio, contra 28% no restante do ecossistema, e os achados de baixo risco caem de 69% para 39%. Metade exata das vulnerabilidades descobertas por IA resulta em execução remota de código, contra 26% da média. O relatório atribui isso ao tipo de tarefa: os programas de pesquisa direcionam agentes a fronteiras de privilégio e a caminhos de código de vários passos, que é justamente onde mora a falha chata de lógica.

O GTIG também avisa que os dados públicos subcontam o que foi encontrado por IA, porque falta metadado padronizado de atribuição, porque provedores de nuvem corrigem direto em produção sem pedir número CVE e porque muitos achados ficam embargados. Ou seja, o total de falhas achadas por IA é maior do que se consegue medir. Isso não muda a conclusão: se o subnúmero é medido, não medido ou estimado por terceiro, a fila de triagem na sua frente é grande.

O caso que amarra as duas partes é o CVE-2026-1731: injeção de comando de sistema não autenticada no BeyondTrust Privileged Remote Access, descoberta de forma autônoma pelo agente de pesquisa Hacktron AI. Quatro dias após a divulgação pública, o GTIG já observava um cluster explorando. Mais cinco clusters em sete dias, com escalonamento de privilégio, exfiltração de dados e carga secundária. Não foi um relatório esquecido em arquivo morto. Foi uma porta que abriu rápido, porque alguém provou que ela abria.

O Google desligou o botão de reportar

No mesmo dia, o Google suspendeu as submissões do seu programa de recompensas para código aberto, o OSS VRP. O motivo está no comunicado: a pausa se deve a um aumento significativo de submissões automatizadas, “a grande maioria das quais não é válida”. Relatórios de supply chain e relatórios já pendentes continuam aceitos, e a empresa promete reformatar o programa até o primeiro trimestre de 2027.

O programa pagou mais de US$ 81,6 milhões desde 2010, com US$ 17,1 milhões em 2025 para mais de 700 pesquisadores. Não é um projeto marginal cortado por aperto de custo. O canal foi fechado porque o custo de humano para ler o que a máquina mandou ficou maior que o retorno. E não é o primeiro: em janeiro o mantenedor do curl encerrou o programa dele no HackerOne pelo mesmo motivo, e em setembro a Intel removeu as recompensas financeiras do programa dela no Intigriti, sem explicar.

Uma empresa grande de tecnologia chegou à conclusão que eu venho repetindo há anos: gerar relatório é barato, verificar relatório é caro, e o mercado só paga pela segunda metade.

O que isso tem a ver com o seu próximo pentest

Aqui é onde a notícia vira decisão de compra, e onde eu vou discordar do conselho padrão.

Se você adota uma ferramenta de varredura porque “achou 400 vulnerabilidades”, você não comprou segurança. Você comprou uma fila. Pelo próprio GTIG, cada 431 itens dessa fila contém uma que alguém vai explorar de verdade, e as 430 restantes são custo de triagem, ruído em relatório e, se passarem adiante sem filtro, ruído na sua frente e na do seu auditor.

Duas coisas que eu diria a um CTO nessa situação. A primeira: o escopo do teste precisa entregar prova, não título. Uma vulnerabilidade séria de pentest vem com requisição reproduzível, resposta observada e efeito demonstrado no seu ambiente. É isso que separa relatório de auditoria de fórum.

A segunda: o número de achados não é métrica de segurança. Métrica de segurança é o que o atacante conseguiu depois. FortiMail, Cisco e o NetScaler deram o mesmo espetáculo na semana: patches publicados, appliances reiniciando sozinhas porque alguém já estava dentro, e administradores relatando ter atualizado o equipamento e ainda assim levar com o problema. Atualizar fecha a porta de entrada de um caminho específico. Não fecha a sessão que alguém já abriu, não revoga a credencial que já saiu e não valida se existia outra porta.

Se eu fosse o CTO dessa empresa, a primeira coisa amanhã não seria trocar de scanner. Seria pedir, para cada achado pendente na fila, uma prova reproduzível em ambiente de teste. O que sobreviver a isso é o seu backlog real. O resto pode esperar o próximo trimestre.

O que fazer agora

• Peça evidência, não contagem: cada achado do relatório precisa de requisição, resposta e impacto observados no seu ambiente.
• Trate a lista de varredura como fila de triagem, com prazo e responsável, não como backlog de correção.
• Meça o seu teste pelo que o atacante conseguiu depois, não pelo número de itens entregues.
• Inclua no escopo as fronteiras de privilégio, que é onde os agentes de IA estão achando o dobro de execução remota de código e onde o teste manual costuma passar reto.
• Valide a correção depois do patch, em teste de regressão, porque atualizar não limpa invasão anterior.

Se a sua superfície de aplicação e API ainda não foi testada por inteiro neste ano, é aqui que o escopo de cobertura do PentestBR entra: teste manual aprovado, com exploit reproduzível e relatório que o auditor aceita. Você pode discordar do 0,23%, e eu também não quero dizer que a sua empresa tem 431 vulnerabilidades esperando. O que eu quero dizer é o seguinte: quando alguém apresentar uma lista enorme, pergunte quantos itens dela foram provados no seu ambiente. A resposta costuma ser muito menor que a lista.