Pare de correr atrás de CVEs: priorização de vulnerabilidades por exploração real (KEV)

O jogo de correr atrás de tudo já está perdido

Deixa eu começar com uma verdade incômoda que vejo em quase toda organização brasileira que assessoro: a equipe de segurança está afogada. O scanner de vulnerabilidades roda, cospe milhares de itens classificados como críticos e altos, e o time olha aquele relatório com a mesma sensação de quem recebe uma conta que não tem como pagar. Corrigir tudo virou uma fantasia operacional. Não é questão de esforço ou competência, é questão de aritmética básica: o volume de Vulnerabilidades e Exposições Comuns (CVE) divulgadas por ano cresceu de forma expressiva e continua acelerando, enquanto o número de horas disponíveis do seu time permanece o mesmo.

O que acontece na prática quando você tenta corrigir tudo? Você não corrige nada bem. A equipe gasta semanas empurrando patches de baixa relevância porque o scanner os marcou como críticos, e enquanto isso a vulnerabilidade que está sendo ativamente explorada no seu setor passa despercebida no meio da pilha. É o clássico problema de tratar todo alarme como se tivesse o mesmo peso: quando tudo é urgente, nada é urgente.

Neste artigo quero mostrar por que a priorização baseada em volume de CVE e em score genérico falhou, e como montar um processo de priorização que foca no que realmente está sendo atacado. Vou falar do catálogo de vulnerabilidades sabidamente exploradas mantido pela agência americana de cibersegurança, de como conectar isso à sua gestão de riscos e, o que mais importa para quem responde a auditoria, de como deixar essa decisão registrada e defensável.

Por que o CVSS sozinho te enganou por anos

O Sistema Comum de Pontuação de Vulnerabilidades (CVSS) foi uma boa ideia com uma execução que virou muleta. A proposta era dar uma nota de severidade padronizada para cada vulnerabilidade, de zero a dez, para que times pudessem comparar riscos. O problema é que a maioria das organizações passou a usar o score base como se fosse uma ordem de serviço: nota nove, corrige agora; nota sete, corrige essa semana. Essa leitura é preguiçosa e perigosa.

O CVSS base mede o potencial teórico de dano de uma vulnerabilidade, não a probabilidade de ela ser explorada contra você. São coisas radicalmente diferentes. Uma vulnerabilidade pode ter nota máxima e nunca ter sido explorada por ninguém no mundo real, seja porque exige condições improváveis, seja porque simplesmente não interessa aos atacantes. Enquanto isso, uma vulnerabilidade de nota média pode estar sendo usada em campanhas de ransomware ativas neste exato momento contra empresas do seu porte.

Após anos trabalhando com organizações de médio e grande porte no Brasil, posso afirmar que a maior parte das vulnerabilidades com score alto nunca será explorada. Isso não é opinião, é comportamento observável dos atacantes: eles miram um subconjunto pequeno e específico do universo de CVE, aquele que dá retorno com menos esforço. Quando você prioriza pelo score genérico, você está gastando o combustível do seu time exatamente onde o atacante não está olhando.

Não estou dizendo para jogar o CVSS no lixo. Ele continua útil como um dos ingredientes da decisão. O erro é usá-lo como ingrediente único e principal. A pergunta que precisa guiar a priorização não é "o quão grave isso seria em teoria", e sim "isso está sendo explorado de verdade, e eu estou exposto".

O catálogo KEV e por que ele mudou o jogo

A agência americana de cibersegurança e segurança de infraestrutura, a CISA, mantém um recurso que virou referência global e que ainda é subutilizado no Brasil: o catálogo de vulnerabilidades sabidamente exploradas, conhecido pela sigla KEV, de Known Exploited Vulnerabilities. A lógica dele é simples e brutalmente eficaz. Em vez de listar tudo o que poderia ser perigoso, o catálogo lista o que comprovadamente está sendo explorado no mundo real, com evidência de exploração ativa.

Isso inverte a lógica da priorização. Quando uma CVE entra no catálogo KEV, ela deixa de ser um risco hipotético e passa a ser um risco confirmado. Não é mais uma questão de "poderia acontecer", é "está acontecendo". Para um gestor que precisa decidir onde alocar as poucas horas do time nesta semana, essa distinção vale ouro. O KEV funciona como um filtro de realidade sobre aquele relatório inflado do scanner.

O que eu recomendo é bem prático: cruze o resultado das suas varreduras com o catálogo KEV. Toda vulnerabilidade presente no seu ambiente que também consta no KEV sobe imediatamente ao topo da fila, independentemente do que o CVSS base diz sobre ela. Esse é o seu núcleo inegociável de correção. É a lista curta que realmente importa, e ela costuma ser uma fração minúscula do relatório original.

Vale um alerta de contexto brasileiro. O KEV é excelente, mas não é onisciente. Ele reflete o que a comunidade global e o governo americano conseguiram confirmar como explorado. Ameaças mais regionais ou campanhas direcionadas ao mercado brasileiro podem não estar refletidas ali de imediato. Por isso o KEV é o piso da sua priorização, não o teto. Ele resolve a maior parte do problema, mas você complementa com inteligência do seu próprio setor.

A janela entre divulgação e exploração está encolhendo

Existe um fenômeno que todo gestor de segurança precisa entender porque muda completamente o cálculo de urgência: o tempo entre a divulgação pública de uma vulnerabilidade e o início da sua exploração ativa vem encolhendo de forma consistente. Houve uma época em que você tinha semanas, às vezes meses, entre saber de uma falha e ver os primeiros ataques usando ela. Essa folga acabou.

Hoje o padrão é assustadoramente mais rápido. Grupos de atacantes acompanham as divulgações com a mesma diligência que os defensores deveriam ter, e em muitos casos a exploração começa em questão de dias após a publicação da correção, às vezes antes que boa parte das empresas sequer tenha lido o boletim. A automação ajudou os dois lados, mas ajudou os atacantes de forma mais direta: eles transformam uma prova de conceito recém-publicada em ferramenta de ataque em massa quase que instantaneamente.

Isso tem uma consequência operacional que gestores brasileiros ainda não internalizaram: o ciclo mensal de patches, aquele conforto de "toda terceira terça-feira a gente aplica as correções", já não protege contra as vulnerabilidades que entram no KEV. Para o núcleo inegociável, o de exploração ativa confirmada, o ritmo tem que ser de dias, não de semanas. Você precisa de um caminho rápido separado para essas correções, com autonomia para agir fora da janela normal de manutenção.

A boa notícia é que essa mesma compressão de tempo torna a priorização por exploração real ainda mais valiosa. Se você não pode correr atrás de tudo e a janela de reação é curta, então você precisa acertar a mira. Focar no que está sendo explorado é a única estratégia que respeita ao mesmo tempo a limitação do seu time e a velocidade do adversário.

Montando o processo de priorização na prática

Vou descer ao operacional, porque teoria sem processo não corrige nada. A base do modelo que recomendo combina três camadas de informação para decidir a ordem de correção, e nenhuma delas isolada é suficiente. A primeira camada é a exploração real, respondida pelo catálogo KEV e por fontes de inteligência de ameaças. A segunda é a probabilidade estatística de exploração futura, que você extrai de sistemas de scoring preditivo de exploração. A terceira é o contexto do seu ambiente: onde a vulnerabilidade está, o que ela expõe e o quanto aquele ativo importa para o negócio.

O fluxo funciona como um funil. Você começa com o relatório completo do scanner, que é imenso. Aplica o filtro KEV e isola o que está confirmadamente sendo explorado. Esse grupo vai para o caminho rápido de correção emergencial. Do que sobra, você olha a probabilidade preditiva de exploração e a exposição do ativo, priorizando vulnerabilidades em sistemas expostos à internet e em ativos críticos para a operação. O que não se encaixa em nenhuma dessas categorias entra no ciclo normal de manutenção ou, sendo honesto, na fila do "quando der".

Um ponto que faz toda diferença na prática é a criticidade do ativo. Uma vulnerabilidade explorada num servidor de teste isolado da internet não é a mesma emergência que a mesma vulnerabilidade num servidor de aplicação que processa dados de clientes. O KEV te diz que a falha é real; o contexto do seu ambiente te diz o quanto ela é sua. Sem esse cruzamento, você ainda estaria priorizando no escuro, só que num escuro mais bem informado.

Para não deixar isso abstrato, esses são os passos mínimos de um processo que funciona:

• Cruzar automaticamente o inventário de vulnerabilidades com o catálogo KEV a cada varredura
• Definir um prazo agressivo e formal de correção para tudo que consta no KEV e está exposto
• Estabelecer um caminho de aprovação rápido para correções fora da janela de manutenção
• Registrar toda decisão de priorização e de aceitação de risco com justificativa
• Revisar periodicamente os itens não corrigidos, porque uma vulnerabilidade dormente pode entrar no KEV a qualquer momento

O caminho rápido de correção não é opcional

Muita organização monta a inteligência de priorização e para no meio do caminho, porque descobre que sabe o que corrigir mas não tem como corrigir rápido. Identificar a vulnerabilidade crítica e levar três semanas para aplicar o patch por causa de burocracia interna é o mesmo que não ter identificado nada. A priorização baseada em exploração real exige um mecanismo de resposta com velocidade compatível.

Isso significa ter um processo de mudança emergencial desenhado antes de precisar dele. Um comitê de mudanças que só se reúne quinzenalmente não serve para uma vulnerabilidade no KEV que está sendo explorada hoje. Você precisa de uma via expressa, com alçada de decisão pré-aprovada, critérios claros de quando ela é acionada e responsáveis nomeados. O critério mais óbvio de acionamento é justamente a entrada da vulnerabilidade no catálogo de exploração ativa combinada com a existência do ativo exposto no seu parque.

Aqui entra uma tensão cultural que vejo com frequência nas empresas brasileiras: o medo de que a correção emergencial derrube algum sistema. É um medo legítimo, mas ele precisa ser gerenciado com preparo, não com paralisia. Ter ambientes de teste que permitam validação rápida, ter capacidade de reverter uma mudança e ter acordos prévios com as áreas de negócio sobre janelas emergenciais transforma o "não podemos parar o sistema" em "sabemos como parar o sistema com segurança quando for necessário".

Perguntas frequentes

O que é KEV (Known Exploited Vulnerabilities) e por que devo me importar?
KEV refere-se a vulnerabilidades que estão sendo exploradas ativamente em ataques reais, não apenas em laboratórios. Para sua empresa, isso significa que você pode focar recursos limitados de TI onde os criminosos realmente estão atacando, em vez de gastar tempo com vulnerabilidades teóricas que podem nunca ser exploradas.

Qual é a diferença entre uma CVE e uma vulnerabilidade explorada?
Uma CVE é um identificador para qualquer vulnerabilidade conhecida, enquanto uma vulnerabilidade explorada é aquela que criminosos estão efetivamente utilizando em ataques. Existem dezenas de milhares de CVEs cadastradas, mas apenas uma fração pequena é explorada na prática, o que permite priorização mais inteligente.

Por que as equipes de segurança não conseguem acompanhar todas as CVEs?
O volume é simplesmente insustentável: milhares de novas CVEs são descobertas mensalmente, e remediar todas esgota orçamento, pessoas e tempo. Tentar corrigir tudo é impossível e improdutivo quando a maioria nunca será explorada contra sua empresa.

Como a priorização por exploração real reduz custos de segurança?
Ao focar apenas em vulnerabilidades que estão sendo exploradas ativamente, você reduz o volume de patches desnecessários, diminui downtime de sistemas e aloca engenheiros para riscos reais. Isso significa menos investimento em remediação desperdiçada e mais eficiência operacional.

Existe uma base de dados pública de vulnerabilidades sendo exploradas?
Sim, o CISA (agência de segurança dos EUA) mantém publicamente uma lista de vulnerabilidades exploradas conhecidas, atualizada regularmente. Outras fontes comerciais também rastreiam exploração em tempo real, oferecendo visibilidade sobre quais CVEs representam ameaça imediata.

Em quanto tempo devo corrigir uma vulnerabilidade explorada?
Vulnerabilidades exploradas ativamente devem ser remediadas em dias, não meses. Dependendo da criticidade e complexidade do patch, muitas organizações estabelecem metas de 24 a 72 horas para aplicar correções em sistemas vulneráveis expostos à internet.

Como implementar priorização de vulnerabilidades por exploração em minha empresa?
Comece integrando dados de KEV nas suas ferramentas de gerenciamento de vulnerabilidades, estabeleça SLAs mais agressivos para itens explorados e estruture seus processos para reagir rápido quando uma vulnerabilidade que você tem entra na lista de exploradas. Segundo, treine sua equipe a focar nos riscos reais, não teóricos.

Quais setores precisam de priorização mais rigorosa de vulnerabilidades?
Organizações críticas como bancos, saúde, energia e governo enfrentam volume maior de ataques direcionados, então precisam dessa priorização. Porém, qualquer empresa conectada à internet é alvo e se beneficia de focar em vulnerabilidades realmente exploradas.

Como medir o impacto da priorização de KEV na minha segurança?
Acompanhe métricas como tempo médio para remediar vulnerabilidades exploradas, redução de brechas causadas por CVEs knowns, e eficiência da equipe de segurança em termos de patches aplicados versus risco mitigado. Compare o tempo de remediação antes e depois da implementação da estratégia.

A priorização por KEV substitui uma estratégia de patch management robusta?
Não, ela complementa e otimiza. Uma estratégia de patch management sólida continua essencial para manter sistemas atualizados, mas KEV permite que você dirija urgência máxima aos riscos concretos. Você ainda precisa de processo disciplinado, mas com inteligência sobre onde concentrar esforços.

A GovSimplix integra a Gestão de Incidentes e Vulnerabilidades ao seu modelo de governança, permitindo que organizações registrem, classifiquem e monitorem ocorrências com trilha de auditoria completa e visibilidade executiva sobre o estado de exposição da organização ao longo do tempo.

Sobre o autor

Julio César
Fundador e Arquiteto das Soluções, GovSimplix

Julio César é bacharel em Ciências da Computação pela USTJ e graduado em Análise e Desenvolvimento de Sistemas. É especialista pós-graduado em Cibersegurança e Governança de Dados pela PUC Minas e pós-graduado em Gestão Estratégica de Negócios pela Universidade Presbiteriana Mackenzie.

Possui certificação internacional de Lead Auditor para as normas ISO 27001 (Segurança da Informação), ISO 27701 (Privacidade da Informação) e ISO 42001 (Gestão de Inteligência Artificial), além da certificação Lean Six Sigma Black Belt, voltada para melhoria de processos e redução de variabilidade operacional.

Na GovSimplix, é o responsável pela concepção e evolução da arquitetura metodológica que estrutura os 11 domínios de governança empresarial da plataforma. Combina formação técnica, experiência em auditoria de sistemas de gestão e visão executiva para traduzir a complexidade da governança em estrutura operável para organizações de qualquer porte e setor.