Quando o tempo de exploração é negativo: o que fazer com seu patch SLA

Há um número no M-Trends 2026 que deveria reescrever como pensamos a gestão de vulnerabilidades em toda a indústria: o mean time-to-exploit estimado é de menos sete dias. Negativo. A exploração começa, em média, antes de o patch existir.

Para dimensionar a mudança: em 2018 esse mesmo número era de 63 dias. As equipes de segurança tinham cerca de dois meses entre o disclosure de uma vulnerabilidade e sua exploração para identificá-la, priorizá-la, testar o fix e implantá-lo. Em 2024 a métrica cruzou o zero. Hoje está em menos sete. A janela não encolheu: ela se inverteu.

O que significa um tempo de exploração negativo

Um tempo de exploração negativo significa que, em média, os atacantes estão explorando uma vulnerabilidade antes de o fabricante publicar o patch que a corrige. O modelo mental tradicional — publica-se o CVE, começa a corrida para aplicar o patch antes que alguém o aproveite — assume que existe uma janela de vantagem para o defensor. Esse pressuposto deixou de se sustentar. Quando a exploração precede o patch, não há corrida a vencer dentro do framework de patching: a exposição já está aberta antes de você ter algo para aplicar.

Vejo isso toda semana. Quando rodamos testing baseado em mudanças sobre fintechs e processadoras de pagamento na América Latina, a distância entre "o CVE foi publicado" e "esse CVE já está rodando em tráfego adversário" se reduziu a quase zero.

Três dados que confirmam a mudança

Não é uma métrica isolada nem uma leitura otimista de uma única fonte. Três dados independentes apontam na mesma direção.

O primeiro: o IBM X-Force 2026 reporta que 40% dos incidentes observados começaram com a exploração de uma vulnerabilidade, o que a coloca como a principal causa dos ataques. O segundo: segundo os dados da VulnCheck sobre tendências de exploração, 28,3% dos CVEs que foram explorados foram weaponizados dentro de 24 horas após seu disclosure público. O terceiro não é um número, e sim uma mudança estrutural: o pipeline de research-to-weaponize, que costumava levar semanas, hoje opera em mercados de exploits acelerados por IA, muitas vezes antes de o aviso chegar à sua equipe.

O que a maioria das análises deixa passar é que isso não se trata de atacantes mais sofisticados. Trata-se de industrialização. O pipeline virou uma linha de montagem.

Por que seu patch SLA de 72 horas já não é suficiente

O patch SLA — o Service Level Agreement que define em quanto tempo uma organização se compromete a aplicar um patch — de 72 horas foi calibrado para um mundo em que esse pipeline levava duas semanas. Esse mundo terminou. Não porque a política esteja mal escrita, mas porque ela mede contra uma janela que já não existe.

Quando me sento com CISOs, a lacuna que vejo com mais frequência não está na política de patching em si. Está entre a política e a realidade operacional, e é justamente a lacuna em que os atacantes já estão dentro. Por isso a pergunta honesta não é qual é o seu SLA, e sim outra: qual é o seu mean time to patch real sobre um CVE no seu inventário exposto externamente? Não o do SLA. O número real. Se você não o conhece, não pode fechá-lo.

O que fazer quando o atacante chega antes do patch

Se a exploração precede o patch, a defesa não pode depender da velocidade de patching. Ela tem que se apoiar em saber, de forma contínua, o que está exposto e como poderia ser explorado, sem esperar que um aviso seja publicado. Isso desloca a conversa da gestão reativa de patches para a validação contínua da exposição real.

Na Strike passamos o último ano argumentando que a validação híbrida contínua deixou de ser um feature: é o novo piso. Quando os atacantes trabalham antes de a sua janela de patching abrir, seu testing também tem que fazê-lo. Eles não esperam o seu patch window. Estão trabalhando antes de ele abrir.

‍