A Inteligência Artificial mudou a escala da descoberta de vulnerabilidades em software. Em anúncio publicado em 6 de outubro, a Anthropic informou que parceiros do Project Glasswing identificaram pelo menos 129 mil vulnerabilidades verificadas entre abril e julho de 2026, das quais mais de 33 mil classificadas como críticas ou de alta severidade. O número vem de apenas 33 relatórios de parceiros, e a própria companhia estima que o impacto real seja ao menos cinco vezes maior.
O dado dimensiona um avanço relevante na capacidade de identificar falhas antes que elas sejam exploradas, além de deslocar o problema. Durante anos, a limitação das operações de segurança esteve na descoberta: era difícil saber o que estava quebrado e esse gargalo está sendo resolvido. O que surge no lugar é um desafio diferente e menos discutido, que é a capacidade das organizações de absorver, avaliar e agir sobre um volume de informação que agora cresce mais rápido do que qualquer equipe pode processar.
"A descoberta deixou de ser o problema, e isso é uma boa notícia", afirma Heriberto Cabrera, Regional Vice President, Solutions Engineering LATAM da Tanium. "O efeito colateral é que a triagem virou a disciplina central da segurança. Não existe organização no Brasil com equipe suficiente para tratar 129 mil achados como se todos tivessem o mesmo peso. Priorizar deixou de ser boa prática e passou a ser a única forma de operar."
Um número global, uma pergunta local
Um ponto costuma se perder na leitura desses levantamentos: o volume divulgado não representa o que existe em um ambiente específico. Nenhuma empresa está exposta a 129 mil vulnerabilidades. A pergunta que importa para uma organização brasileira é outra e é bem mais estreita: quais desses componentes nós efetivamente usamos, em quais equipamentos eles estão instalados, quais estão expostos e quais processos de negócio dependem deles.
Essa diferença entre o número do setor e o número da empresa é onde se decide se a informação vira proteção ou apenas volume. Uma falha crítica em um equipamento isolado, sem exposição externa e sem relação com sistemas essenciais, não demanda a mesma resposta que a mesma falha em um ativo que sustenta uma operação de produção. A classificação técnica de severidade é idêntica nos dois casos, enquanto o risco para o negócio, não.
O peso do código aberto nas cadeias brasileiras
Há um aspecto do levantamento com relevância particular para o Brasil. Boa parte das falhas identificadas por programas desse tipo se concentra em projetos de código aberto com componentes que raramente são adquiridos de forma direta e que chegam às empresas embutidos em sistemas de terceiros, aplicações internas, imagens de contêiner e dependências de desenvolvimento.
No setor público, no sistema financeiro e no ecossistema de fintechs brasileiro, esses componentes sustentam operações críticas sem aparecer em contratos ou em listas formais de software. O resultado é um ponto cego estrutural: a organização pode estar exposta a uma vulnerabilidade divulgada sem ter como saber, rapidamente, se o componente afetado está em execução em seu parque e em quais ativos.
"Não dá para priorizar aquilo que não se sabe que existe", diz Cabrera. "Quando uma falha relevante é divulgada, a primeira pergunta não é técnica, é de inventário: nós usamos isso? Onde? Em quantos equipamentos, em quais versões? Se essa resposta leva dias para ser montada em planilha, a priorização já começou atrasada."
Inventário como condição de triagem
A qualidade dessa resposta depende diretamente da qualidade do inventário. Equipamentos fora dos processos formais de gestão, aplicações desatualizadas, mudanças de configuração não registradas e dispositivos que se conectam de forma intermitente produzem lacunas que distorcem qualquer esforço de priorização. Uma triagem construída sobre dados coletados em varreduras periódicas descreve o ambiente de semanas atrás, não o de agora.
A Anthropic observou, ao divulgar os resultados, que menos da metade dos parceiros informou o número de correções aplicadas, em muitos casos porque os ajustes ainda estavam em andamento. A observação reforça um ponto prático: o ciclo de uma vulnerabilidade não termina na identificação. O guia de gestão de correções do NIST, referência amplamente adotada, descreve esse ciclo como identificar, priorizar, obter, instalar e verificar, além da etapa de verificação, confirmar no próprio equipamento que a correção foi aplicada e que a exposição deixou de existir, é a que mais frequentemente fica incompleta.
Para a Tanium, a viabilidade desse ciclo depende de inteligência confiável e atual sobre os endpoints. A arquitetura da companhia obtém dados sob demanda diretamente do equipamento, e não de um banco de dados intermediário, o que permite responder em minutos quais ativos executam determinado componente, em quais versões e com qual nível de exposição e confirmar, depois da correção, se o problema foi efetivamente resolvido.
"O setor passou anos tentando enxergar mais", conclui Cabrera. "Estamos entrando em um período em que enxergar deixou de ser o problema. O diferencial passa a ser a capacidade de responder, sobre o próprio ambiente e em tempo real, o que é relevante aqui dentro. Essa resposta é o que separa um relatório de uma redução real de risco."
