Empresas brasileiras acumulam milhares de vulnerabilidades em inventários crescentes, mas o que separa uma brecha crítica de um ruído de fundo é saber distinguir um zero-day de uma CVE conhecida. Neste guia técnico, mostramos como usar CVSS v4, EPSS e a lista CISA KEV para priorizar patches com base em risco real, não em pânico.

Zero-day versus vulnerabilidade conhecida

A confusão começa na definição. Uma vulnerabilidade conhecida já foi identificada, recebeu um identificador CVE (Common Vulnerabilities and Exposures) e, na maioria dos casos, possui correção disponível do fornecedor. Já um zero-day é uma falha explorada ativamente na natureza antes que o fabricante publique um patch — o nome refere-se aos “zero dias” de proteção disponíveis desde a divulgação.

A diferença não é acadêmica. Dados da CISA mostram que o catálogo Known Exploited Vulnerabilities (KEV) cresceu cerca de 20% em 2025, ultrapassando 1.480 entradas, com 245 novas vulnerabilidades adicionadas no ano — 24 delas associadas a grupos de ransomware. No mesmo período, estudos consolidados registraram 90 zero-days confirmados em exploração ativa, um aumento de 15% em relação ao ano anterior. Em outras palavras: a janela entre descoberta e exploração continua encolhendo.

Um exemplo emblemático está documentado em nosso relato sobre o ataque ShinyHunters ao regulador NAIC, em que a exploração de uma falha sem correção disponível resultou no vazamento de 3,1 TB de dados.

CVSS v4 mede o impacto técnico

O Common Vulnerability Scoring System (CVSS), mantido pelo FIRST, atribui uma nota de 0 a 10 baseada nas características técnicas da falha: vetor de ataque, privilégios exigidos, impacto na confidencialidade, integridade e disponibilidade. A versão 4.0, finalizada em 2024 e adotada em escala pelo NIST NVD ao longo de 2025, incorpora métricas de ameaça e ambientais que refletem melhor o contexto real de uso.

O problema do CVSS usado isoladamente é bem conhecido: ele mede severidade, não urgência. Estudos publicados em 2025 apontam que apenas 2% a 5% das vulnerabilidades classificadas como “Crítico” (CVSS 9,0 ou superior) chegam a ser exploradas na natureza. Aplicar o mesmo SLA de correção a todas elas gera desperdício de esforço e atrasa a remediação das que realmente importam.

EPSS estima risco real de exploração

Foi para corrigir essa lacuna que o Exploit Prediction Scoring System (EPSS), operado pelo FIRST em parceria com a CISS, ganhou força. A versão 4, lançada em 17 de março de 2025, publica diariamente uma probabilidade de 0 a 1 para cada CVE, baseada em evidências empíricas de exploração no mundo real — e disponibiliza os dados de forma aberta via API e CSV.

A combinação CVSS + EPSS muda a equação. Uma vulnerabilidade com CVSS 9,8 pode ter EPSS de 0,02% (baixa probabilidade de exploração imediata), enquanto uma falha com CVSS 7,5 pode registrar EPSS acima de 80%. Pesquisas acadêmicas de 2025 demonstram que o EPSS supera o CVSS isolado em eficiência de priorização por margem significativa, permitindo que equipes concentrem esforços nos poucos percentuais de CVEs efetivamente sob ataque.

CISA KEV exige ação imediata

O terceiro pilar é a lista CISA KEV. Quando uma vulnerabilidade entra no catálogo, há comprovação pública de exploração ativa, e a agência americana exige que órgãos federais apliquem a correção em prazos curtos — frequentemente três semanas, em alguns casos 14 dias. Para empresas privadas, a lista funciona como sinal de prioridade máxima: se está na KEV, a exploração já ocorreu e há exploit circulando.

O fluxo recomendado por analistas é tripartido:

  • Alta prioridade: presente na CISA KEV — corrigir em até 72 horas;
  • Prioridade média: EPSS acima de 10% e CVSS alto — corrigir em até 15 dias;
  • Rotina: demais CVEs — janela padrão de 30 a 60 dias, conforme criticidade do ativo.

Automação com Ansible e WSUS

Definir prioridade é metade do trabalho; a outra metade é executar a correção sem interromper a operação. Em ambientes heterogêneos, a automação é o que viabiliza SLAs curtos. No mundo Linux, o Ansible, mantido pela Red Hat, tornou-se o padrão de fato: playbooks agentless aplicam patches em centenas de servidores RHEL, Ubuntu e Debian simultaneamente, com módulos como dnf, apt e yum, e suporte a reinicialização controlada.

No ambiente Windows, o Windows Server Update Services (WSUS) permanece como espinha dorsal para distribuição centralizada de patches. A integração entre Ansible Automation Platform e WSUS permite orquestrar todo o ciclo: inventário de hosts, seleção de updates, validação em grupo piloto, implantação em produção e relatório de conformidade. A Red Hat documenta um fluxo de cinco passos que cobre desde o inventário centralizado até templates de job para aplicar correções de RHEL e Windows no mesmo pipeline.

Para endpoints fora do datacenter, ferramentas como Tanium, Ivanti Neurons e Microsoft Intune complementam a automação, garantindo cobertura de notebooks, estações de trabalho e servidores distribuídos — cenário comum em empresas com múltiplas filiais.

Desafios brasileiros e recomendações práticas

No Brasil, o cenário é mais complexo. Cerca de 87% das empresas falham em maturidade de gestão de vulnerabilidades e patches, segundo diagnóstico recente do mercado nacional. A combinação de inventários desatualizados, janelas de manutenção curtas e dependência de sistemas legados — ainda comuns em setores como manufatura, saúde e setor público — cria um gap estrutural entre a teoria do CVSS e a realidade da operação.

A vulnerabilidade sem correção na biblioteca pynetdicom, que ameaça hospitais brasileiros, ilustra o ponto: quando não há patch disponível, a priorização depende de compensação de risco (WAF, segmentação de rede, EDR), não de aplicação automatizada.

Os casos recentes reforçam a urgência. Em março de 2026, o grupo Interlock explorou a falha CVE-2026-20131 (CVSS 10,0) no Cisco Secure Firewall Management Center durante 36 dias antes de a Cisco publicar a correção — ataque documentado por AWS, eSentire e FortiGuard. A CVE-2026-20700, primeira zero-day da Apple em 2026 (no componente dyld do iOS), foi explorada em “ataque extremamente sofisticado” antes de qualquer patch público. E em janeiro de 2025, a CVE-2025-0282 no Ivanti Connect Secure sustentou campanhas de ransomware em escala global.

O recado para equipes brasileiras é direto:

  • Monitore a CISA KEV diariamente e crie alertas automatizados para ativos do seu inventário;
  • Combine CVSS e EPSS para definir SLAs realistas, evitando a “fadiga de patches”;
  • Automatize a aplicação com Ansible (Linux) e WSUS/Intune (Windows), com grupo piloto obrigatório;
  • Mantenha o inventário atualizado — sem visibilidade de ativos, qualquer priorização é palpite;
  • Tenha plano de contenção para zero-days sem correção: segmentação, EDR e WAF reduzem a janela de exposição.

Em um ano em que a janela entre divulgação e exploração encolheu para dias — às vezes horas —, a diferença entre sofrer um incidente e evitá-lo não está em aplicar todos os patches, mas em corrigir primeiro o que efetivamente está sob ataque.