Janela de exploração: o prazo entre a falha e o patch

Uma terça-feira qualquer, o fabricante do seu firewall publica um alerta de segurança com patch. A equipe de TI anota, coloca na fila da janela de manutenção do mês e segue o trabalho. São três semanas até a próxima parada programada.

Esse intervalo, entre a falha virar pública e a correção estar aplicada, é a janela de exploração. Por muitos anos ela foi medida em semanas, e o calendário mensal de atualização cabia dentro dela com folga.

Os números dos últimos relatórios mostram outra régua. O atacante deixou de esperar semanas, e em parte dos casos começa antes de o patch existir.

O ciclo mensal de patch foi desenhado para uma janela de exploração que não existe mais. O que protege hoje é uma fila curta, com os ativos expostos à internet, corrigidos em dias, separada do resto do parque.

As cinco marcas do relógio

Toda falha passa pelas mesmas marcas, e a ordem entre elas mudou.

A primeira é a divulgação: o fabricante, um pesquisador ou um aviso público torna a falha conhecida. A segunda é o patch, quando existe correção disponível. A terceira é o exploit, o código que transforma a falha em acesso. A quarta é a exploração, o uso desse código contra alvos reais. A quinta é a correção no seu ambiente, e só ela depende da sua equipe.

O modelo antigo supunha uma sequência confortável: divulgação e patch juntos, exploit semanas depois, exploração em massa mais tarde ainda. A empresa tinha o mês inteiro para encaixar a atualização.

Hoje a exploração pode vir antes da divulgação (o dia zero), no mesmo dia ou poucos dias depois. A quinta marca virou a única variável que a defesa controla, e é nela que o prazo precisa ser definido.

O post sobre gestão de vulnerabilidades explica como escolher o que corrigir primeiro, com CVSS, EPSS e KEV. Aqui o assunto é outro: quanto tempo você tem depois da escolha.

O que os números dizem sobre a janela de exploração

Três fontes medem o relógio de formas diferentes, e as três apontam na mesma direção.

A Mandiant publicou em outubro de 2024 uma análise do tempo de exploração das falhas de 2023. A empresa acompanhou 138 vulnerabilidades exploradas e chegou a uma média de 5 dias. Em 2018 e 2019, a mesma métrica era de 63 dias; em 2021 e 2022, de 32.

O próprio relatório faz uma ressalva honesta: a média de 5 dias exclui 15 casos fora da curva. Com eles, a média sobe para 47 dias. Mesmo assim, o desenho das falhas já corrigidas (as chamadas n-day) é claro: 12% foram exploradas em até um dia, 29% em até uma semana e 56% em até um mês após o patch.

O M-Trends 2026, publicado em março, foi além. O tempo médio estimado de exploração ficou em -7 dias. Segundo a Mandiant, a exploração acontece rotineiramente antes de o patch ser lançado. O mesmo relatório mantém a exploração de falha como o vetor inicial mais comum pelo sexto ano seguido, com 32% das intrusões investigadas.

A VulnCheck mede outra coisa: quantas falhas recém-exploradas já estavam sendo usadas no dia da divulgação ou antes. No relatório do primeiro semestre de 2025, foram 32,1% de 432 vulnerabilidades. Em 2024, a proporção tinha sido de 23,6%.

Os números têm limite, e vale saber qual. Eles contam a primeira exploração registrada, o que tende a atrasar a data real. Média com dias negativos também mistura dois fenômenos: o dia zero, contra o qual patch nenhum ajuda, e a falha corrigida que alguém explora antes que você atualize. A segunda é a parte da janela de exploração que a sua fila consegue fechar.

Por que o patch mensal ficou curto

O ciclo mensal de atualização tem boas razões para existir. Ele junta as correções num pacote, permite testar antes e concentra a parada numa data combinada com o negócio.

O problema aparece quando ele vira o único ritmo da empresa. Se 29% das falhas já corrigidas foram exploradas na primeira semana, um ciclo de 30 dias deixa o ativo exposto durante a fase de maior risco. A janela de exploração fecha do lado do atacante antes de a sua parada chegar.

Há também um fator novo. Gerar um exploit a partir da leitura do patch ficou mais barato com modelos de linguagem. O relatório de ameaças da Anthropic e o caso do primeiro ataque agêntico documentado mostram o pré-requisito técnico caindo. Quando o patch sai, a diferença entre a versão vulnerável e a corrigida vira um mapa para quem quer explorar.

O ciclo mensal continua bom para a maior parte do parque. O que muda é que os ativos com a janela de exploração mais curta saem dele e ganham um prazo próprio, com dono e data.

A régua da CISA: duas semanas

Para quem procura um número defensável, existe uma régua pública. A diretiva BOD 22-01 obriga as agências federais civis dos Estados Unidos a corrigir as falhas do catálogo KEV em prazos fixos. Para CVE atribuída a partir de 2021, o prazo é de duas semanas. Para as anteriores, seis meses.

A CISA só coloca uma falha no catálogo quando há três condições: um identificador CVE, evidência confiável de exploração real e uma ação de correção clara, como a atualização do fabricante. Ou seja, todo item do KEV já está sendo usado por alguém e já tem conserto.

Empresa brasileira não está sujeita à diretiva. A própria CISA recomenda que qualquer organização acompanhe o catálogo e priorize a correção do que aparece nele. Duas semanas é um teto razoável para começar. Para o que está exposto à internet, a janela de exploração medida pela Mandiant pede um prazo menor.

Uma janela de exploração por tipo de ativo

A pergunta útil é qual janela de exploração cada tipo de ativo aceita, e quem responde por esse prazo quando ele estoura.

Os prazos da tabela são sugestão de partida, alinhados à régua da CISA e aos dados de tempo de exploração. Cada empresa ajusta conforme o que consegue sustentar, desde que o número seja escrito e medido.

O servidor de backup aparece na terceira linha por um motivo: grupos de ransomware procuram justamente ele depois de entrar, para impedir a recuperação.

Como montar a fila curta

O trabalho cabe numa rotina semanal, mesmo numa equipe pequena.

1. Liste o que está exposto à internet. Endereço, serviço, fabricante e versão. Sem essa lista, a fila curta não existe.
2. Assine os avisos dos fabricantes dessa lista. VPN, firewall e sistema publicado primeiro. O alerta precisa chegar a uma pessoa nomeada, que responde por ele.
3. Cruze a lista com o catálogo KEV toda semana. Item exposto que aparece no catálogo vira emergência, com prazo em horas.
4. Defina o prazo por tipo de ativo, por escrito. Use a tabela acima como ponto de partida e registre quem aprovou cada número.
5. Combine com o negócio uma parada fora do calendário. Atualizar o concentrador de VPN derruba o acesso remoto. Essa conversa precisa acontecer antes da emergência.
6. Verifique depois de aplicar. Confirme a versão no próprio equipamento, não só no painel da ferramenta de atualização.
7. Meça a janela de exploração real. Dias entre o patch publicado e o patch aplicado, para cada item exposto. Esse é o indicador para levar à diretoria.

Para uma PME sem equipe dedicada, os passos 1, 3 e 6 já cobrem a maior parte do risco. Uma planilha com os ativos expostos, conferida toda segunda-feira contra o KEV, resolve o começo. Ferramenta paga pode vir depois, quando a lista crescer. O restante da base está no guia de cibersegurança para PMEs.

O número que fica

A Mandiant registrou 63 dias de tempo médio de exploração em 2018 e 2019, 5 dias em 2023 e uma estimativa de -7 dias no relatório de 2026. A CISA dá duas semanas para agência federal corrigir uma falha do KEV, e o seu firewall de borda está exposto aos mesmos atacantes que motivaram esse prazo.