O paradoxo da divulgação de vulnerabilidades: por que a aplicação mais rápida de patches não consegue superar os ataques gerados por IA.

Durante décadas, o gerenciamento de patches funcionou com base em uma premissa: agir rápido o suficiente significa vencer os atacantes. O relatório M-Trends 2026 da Mandiant mostra que a corrida acabou. Atualmente, em média, uma vulnerabilidade é explorada sete dias antes mesmo de uma correção ser disponibilizada.

O contraste com o passado recente é gritante. Em 2018, os defensores tinham cerca de dois meses após uma vulnerabilidade se tornar pública antes que alguém tentasse explorá-la — tempo suficiente para testar uma correção e implementá-la antes que alguém aparecesse. Essa janela agora está negativa.

O Relatório Global de Ameaças de 2026 da CrowdStrike corrobora essa informação, constatando que 42% das vulnerabilidades exploradas foram atacadas antes mesmo de serem divulgadas publicamente.

Sentei-me para discutir essas descobertas com Jason Garbis, fundador da Numberline Security e co-presidente do Grupo de Trabalho Zero Trust da Cloud Security Alliance, para um episódio recente do podcast The Segment .  

Ele argumentou que, uma vez que uma vulnerabilidade se torna de conhecimento público, os atacantes não precisam mais procurar pela falha. A própria divulgação lhes fornece um modelo, e desenvolver um exploit a partir de um aviso publicado exige muito menos trabalho do que encontrar a vulnerabilidade do zero.  

Essa mudança explica por que a longa obsessão da indústria de segurança com a velocidade de aplicação de patches está perseguindo o objetivo errado. As equipes que se mantêm firmes sob esse novo cronograma compartilham uma característica. Eles partem do princípio de que a segurança será violada em algum ponto entre a divulgação da vulnerabilidade e a aplicação da correção, e já limitaram o alcance dessa violação.

Quando o aviso de atualização se torna o plano do atacante.

Todo processo de divulgação responsável existe por um bom motivo.  

Os fornecedores precisam informar os clientes sobre os problemas para que eles possam corrigi-los, e os órgãos reguladores exigem isso cada vez mais. Mas essa mesma transparência agora funciona nos dois sentidos.  

No momento em que uma vulnerabilidade CVE se torna pública, os atacantes não precisam mais fazer engenharia reversa para desvendar um mistério. Eles só precisam ler o aviso. Em seguida, eles comparam o código corrigido com a versão vulnerável. A partir dessa diferença, eles podem criar um exploit funcional.

Pesquisas da Iniciativa de Segurança de IA da Cloud Security Alliance mostram o quanto esse processo já foi automatizado. Sistemas de IA multiagentes construídos para reproduzir vulnerabilidades divulgadas recriaram aproximadamente metade de todos os CVEs publicados nos últimos dois anos, muitos deles com exploits funcionais, a um custo médio inferior a US$ 3 por tentativa.  

O que antes exigia um engenheiro reverso habilidoso e dias de trabalho silencioso, agora acontece por uma ninharia. Leva aproximadamente o mesmo tempo que ler o aviso duas vezes.

Este é o mecanismo que Jason e eu discutimos no podcast. Um atacante com acesso a um modelo de IA de ponta que analisa repositórios de código em busca de falhas desconhecidas representa um risco real. 

Mas a ameaça mais imediata é mais simples. Os atacantes aguardam a divulgação da vulnerabilidade e, em seguida, correm para desenvolver a exploração antes que os defensores terminem de validar e implementar a correção.  

A divulgação discretamente se transformou em reconhecimento, e a maioria dos programas de gerenciamento de patches nunca foi projetada para sobreviver a isso.

O tsunami pós-atualização do Mythos

Jason tem um termo criativo para o que ele prevê que acontecerá em um futuro próximo: um tsunami de manchas.

Os modelos de IA de ponta estão agora revelando vulnerabilidades e solicitando atualizações de segurança em um volume e velocidade que a maioria das equipes nunca enfrentou. O debate em torno dos modelos da classe Mythos e do Projeto Glasswing só serviu para acirrar essa discussão.  

Mas a opinião de Jason é que não importa o quanto da propaganda inicial foi marketing. Esses modelos estão cada vez melhores em encontrar falhas, e os defensores precisam se preparar para essa realidade, independentemente do ritmo.

Os números comprovam o que ele está dizendo. De acordo com uma análise de dados oficiais do CVE feita pelo pesquisador da Cisco, Jerry Gamblin, as publicações globais sobre vulnerabilidades CVE ultrapassaram 48.000 em 2025, um aumento de 20% em relação ao ano anterior. Seu levantamento de acompanhamento no meio do ano mostra a curva subindo verticalmente: somente o primeiro semestre de 2026 gerou mais de 35.000 eventos cardiovasculares adversos, um aumento de quase 50% em relação ao mesmo período do ano passado. Isso representa uma nova vulnerabilidade CVE a cada 7,4 minutos.  

Os fornecedores de software comercial também estão reduzindo o tempo de suporte para versões antigas, o que força ciclos de atualização mais rápidos em toda a empresa.  

Bibliotecas de código aberto também estão se tornando uma fonte crescente de visibilidade. Jason salientou que, muitas vezes, eles demonstram muito menos rigor em relação ao empacotamento e ao versionamento do que o software comercial. Muitos softwares empresariais personalizados dependem deles, às vezes sem serem modificados por anos.

Jason argumentou que os fundamentos da segurança da informação não mudaram. A indústria já sabe como se defender contra todas as categorias de ataque que enfrenta atualmente.  

O que está mudando é o volume e a velocidade com que os riscos conhecidos estão chegando. Essa mudança está expondo equipes que nunca desenvolveram a disciplina necessária para acompanhar o ritmo, mesmo antes da entrada da IA em cena.

O que importa é a extensão da propagação de uma violação.

Se a velocidade de aplicação de patches por si só não for suficiente para compensar um tempo negativo de exploração, os líderes de segurança precisam de uma métrica diferente. A verdadeira questão é quanta parte da rede um invasor consegue alcançar depois de entrar.  

Jason ofereceu um exemplo concreto de seu trabalho de consultoria. Imagine um aplicativo financeiro rodando em uma rede corporativa plana, onde qualquer um dos 5.000 funcionários e dispositivos pode acessá-lo diretamente. Agora imagine essa mesma aplicação restrita às cerca de 200 pessoas que realmente trabalham no setor financeiro. 

De qualquer forma, a vulnerabilidade ainda precisa ser corrigida. Mas a população que poderia explorá-la antes do lançamento do patch diminuiu em mais de 95%.

Esse é o argumento a favor de tratar a segmentação como um controle fundamental. Isso não elimina a necessidade de correções ou de uma política perfeita e detalhada desde o primeiro dia. A segmentação de baixo nível, aplicada em torno dos seus sistemas de maior valor, ainda traz benefícios.  

Com a segmentação correta, uma vulnerabilidade que poderia se tornar uma grande catástrofe se transforma em um pequeno incidente que sua equipe pode resolver em uma tarde.

As orientações em si têm sido consistentes há anos. O que mudou foi o custo de ignorar o problema, visto que uma nova descoberta pode agora se transformar rapidamente em uma vulnerabilidade explorada.

Três medidas que vale a pena tomar antes do seu próximo ciclo de divulgação.

Algumas medidas concretas surgiram da minha conversa com Jason. Eu encorajaria todos os líderes de segurança a ponderarem essas medidas em relação ao seu planejamento atual.

Crie um inventário real do que está em funcionamento e de quem deve entrar em contato com ele.

Jason foi enfático quanto a isso. A tecnologia de segmentação só agrega valor quando recebe dados precisos e legíveis por máquina sobre suas cargas de trabalho e as identidades que precisam ter acesso a elas. Ignorar esta etapa é a maneira mais rápida de acabar com uma política que parece boa no papel, mas falha na prática.

Segmente agora seus sistemas de maior valor, mesmo que de forma geral.

Aguardar por uma política perfeita e totalmente definida antes de agir é a paralisia por análise contra a qual Jason alertou diretamente. Uma primeira análise superficial dos seus recursos críticos é melhor do que um plano perfeitamente documentado que nunca é implementado.

Configure um temporizador de atualização em seus sistemas legados.

Jason recomenda que todos os novos sistemas sejam obrigados a seguir as normas de governança modernas desde o primeiro dia. Todo sistema existente deve passar por um ciclo obrigatório de reconstrução ou revisão, digamos, a cada 12 a 18 meses. Distribuir esse trabalho ao longo do calendário evita que ele se torne uma pilha que nenhuma equipe consegue terminar.

O momento de agir é antes da próxima divulgação, não depois.

Em junho, a Agência de Segurança Cibernética e de Infraestrutura (CISA) tornou essa mudança política oficial. A Diretiva Operacional Vinculativa 26-04 agora exige que as agências federais corrijam as vulnerabilidades mais perigosas (expostas publicamente, exploradas ativamente e automatizáveis) em até três dias, em vez do prazo anterior de duas semanas. A CISA apontou a IA diretamente como a razão, observando que ela está aumentando drasticamente o ritmo de descoberta de vulnerabilidades tanto para atacantes quanto para defensores.

A diretiva vincula apenas as agências federais, mas a CISA incentiva o setor privado a adotar a mesma abordagem. A expectativa básica do setor em relação ao tempo de resposta já foi reescrita.

A boa notícia é que nada disso exige reinventar seu programa de segurança do zero. Isso exige aceitar que uma violação de segurança que ocorra em algum ponto entre a divulgação e a correção é agora o cenário para o qual se deve planejar. E isso exige a criação de segmentação em torno de seus sistemas mais importantes, para que, quando uma violação ocorrer, o prejuízo seja de apenas uma tarde, em vez de uma manchete.  

As equipes que estão tratando isso como urgente agora, enquanto ainda há uma diferença entre o cenário de ameaças atual e o que vier com a próxima geração de modelos, são as que ainda estarão contando uma boa história daqui a um ano. Aguardar um momento mais favorável é uma aposta que os dados já não sustentam.

Ouça o episódio completo de The Segment: A Zero Trust Leadership Podcast em Podcasts da Apple,  Spotify, ou nosso site.