Gestão de vulnerabilidades: CVE, CVSS e priorização que funciona

Qualquer scanner de vulnerabilidades moderno tem um talento perverso: gerar mais achados do que qualquer equipe consegue corrigir. Uma varredura de um ambiente de tamanho médio devolve facilmente centenas ou milhares de vulnerabilidades. Se o time tratar todas com a mesma urgência, ou pior, tentar zerar a lista, ele vai se afogar em trabalho e, ironicamente, deixar passar justamente as poucas que realmente importam. O problema central da segurança defensiva não é encontrar vulnerabilidades. É priorizá-las.

Gestão de vulnerabilidades é a disciplina que transforma uma lista assustadora em um plano de ação sensato. Ela responde à pergunta que de fato importa: com recursos limitados, o que corrigir primeiro para reduzir o máximo de risco real? Este guia percorre o vocabulário (CVE e CVSS), explica por que a nota bruta engana, apresenta os sinais que uma priorização madura usa (EPSS e contexto de negócio) e mostra como fechar o ciclo com SLAs de correção.

O vocabulário: CVE e CVSS

Dois termos aparecem o tempo todo, e confundi-los atrapalha a conversa.

• CVE (Common Vulnerabilities and Exposures): é o identificador único de uma vulnerabilidade específica e publicamente conhecida. Cada falha catalogada recebe um código, como CVE-2026-12345. O CVE é apenas o "nome de registro" da vulnerabilidade, um jeito de todo mundo falar da mesma coisa sem ambiguidade. Ele não diz o quão grave o problema é.
• CVSS (Common Vulnerability Scoring System): é o sistema que atribui uma nota de severidade de 0 a 10 à vulnerabilidade, com base em características técnicas como facilidade de exploração e impacto. A nota vira uma classificação: Baixa, Média, Alta e Crítica.

A relação é direta: o CVE nomeia, o CVSS pontua. O erro começa quando a nota CVSS passa a ser tratada como a resposta final sobre o que priorizar.

Por que a nota CVSS sozinha engana

O CVSS é útil, mas priorizar apenas pela nota é uma armadilha clássica, por alguns motivos concretos.

Primeiro, ele mede severidade teórica, não risco real no seu ambiente. Uma vulnerabilidade Crítica (nota 9.8) em um serviço interno, isolado, sem acesso à internet e sem dados sensíveis, representa um risco muito menor do que uma vulnerabilidade Média (nota 5.5) em um servidor exposto que processa dados de clientes. A nota é a mesma para todo mundo; o risco é só seu.

Segundo, a nota bruta não considera se a falha está sendo explorada no mundo real. Muitas vulnerabilidades de nota alta nunca ganham um exploit prático; algumas de nota média são exploradas em massa poucos dias após a divulgação. Tratar as duas igual desperdiça esforço.

Terceiro, o volume torna a abordagem inviável. Se você tem duzentas vulnerabilidades "Altas ou Críticas", dizer "corrija todas as Altas e Críticas" não é uma priorização, é uma lista de desejos. A pergunta continua sem resposta: qual dessas duzentas primeiro?

Priorização que funciona: CVSS + EPSS + contexto

A priorização madura combina três sinais, em vez de depender de um só. Cada um responde a uma pergunta diferente.

Sinal	Pergunta que responde	O que traz
CVSS	Quão grave é em teoria?	Severidade técnica base
EPSS	Qual a chance de ser explorada?	Probabilidade de exploração real
Contexto de negócio	O que essa falha ameaça aqui?	Exposição, criticidade do ativo, dados

O EPSS (Exploit Prediction Scoring System) é o complemento que faltava ao CVSS. Ele estima, em porcentagem, a probabilidade de uma vulnerabilidade ser explorada em um horizonte curto, com base em dados do mundo real. Cruzar CVSS com EPSS já muda o jogo: uma falha Crítica com EPSS baixo pode esperar, enquanto uma falha Alta que está sendo ativamente explorada sobe para o topo. Listas de vulnerabilidades sabidamente exploradas, como o catálogo KEV, reforçam esse sinal.

O terceiro fator, o contexto de negócio, é o que só você tem. Ele pondera: o ativo afetado está exposto à internet? Ele guarda ou processa dados sensíveis? É crítico para a operação ou para o faturamento? Existe alguma mitigação já no caminho (um WAF, segmentação)? Uma falha exposta, num sistema crítico, com dados de clientes, é uma emergência mesmo com nota intermediária. A regra de ouro da priorização é: severidade x probabilidade x valor do ativo, não só a nota.

O ciclo de vida da gestão de vulnerabilidades

Priorizar bem é o coração, mas a gestão de vulnerabilidades é um processo contínuo, um ciclo que se repete. Suas etapas:

1. Descoberta: identificar as vulnerabilidades por varreduras contínuas (de rede, de aplicação, de dependências, de containers) e por fontes externas de divulgação.
2. Priorização: classificar os achados combinando CVSS, EPSS e contexto de negócio, como descrito acima. É aqui que a lista vira plano.
3. Remediação: corrigir. Pode ser aplicar um patch, mudar uma configuração ou, quando a correção imediata não é possível, aplicar uma mitigação (por exemplo, isolar o ativo ou bloquear no WAF) para reduzir o risco enquanto a correção definitiva não chega.
4. Verificação: confirmar que a correção realmente fechou a falha e não introduziu outro problema. Marcar como resolvido sem verificar é fé, não gestão.
5. Relatório e melhoria: medir tendências, acompanhar o tempo de correção e ajustar o processo. O ciclo então recomeça.

A palavra-chave é contínuo. Novas vulnerabilidades surgem todos os dias, e o ambiente muda toda semana. Uma varredura pontual é uma foto que envelhece rápido.

SLAs de correção: transformar prioridade em prazo

Priorizar sem prazo é opinião. Os SLAs de remediação (acordos de nível de serviço) definem quanto tempo cada nível de prioridade tem para ser corrigido, tornando o processo mensurável e cobrável. Um exemplo de política, que cada empresa calibra ao seu risco:

• Prioridade crítica (grave, exposta e sob exploração): corrigir em horas a poucos dias.
• Prioridade alta: corrigir em alguns dias a duas semanas.
• Prioridade média: corrigir no ciclo normal, dentro de um mês.
• Prioridade baixa: tratar quando conveniente, ou aceitar formalmente o risco.

Note que a "prioridade" aqui não é a nota CVSS pura, e sim o resultado da combinação dos três sinais. O SLA dá ao processo uma régua objetiva: dá para medir se o time está dentro do prazo, onde estão os gargalos e se o risco acumulado está subindo ou caindo.

Um complemento importante é a aceitação formal de risco: para o que não será corrigido agora, registre a decisão, quem a tomou e por quê. Isso transforma um risco esquecido em um risco gerenciado.

Gestão de vulnerabilidades é decidir bem, não corrigir tudo

Encontrar vulnerabilidades ficou fácil; qualquer scanner faz isso. O trabalho que reduz risco de verdade é decidir, com recursos finitos, onde aplicar o esforço primeiro. Isso exige ir além da nota CVSS e olhar para a probabilidade de exploração (EPSS) e para o que a falha ameaça no seu contexto específico. Com um ciclo de vida contínuo e SLAs claros, a montanha de achados vira um fluxo previsível de correções que ataca o risco onde ele é maior. A meta nunca é "zero vulnerabilidades", que é inatingível. A meta é que as vulnerabilidades que importam sejam corrigidas rápido, e que as decisões sobre as demais sejam conscientes.

Na ConstructorTI, ajudamos empresas a montar essa disciplina: implantação de varredura contínua, desenho de um modelo de priorização que combina CVSS, EPSS e contexto de negócio, definição de SLAs de correção e do processo de aceitação de risco, e relatórios que mostram a tendência real do risco ao longo do tempo. Se a sua lista de vulnerabilidades cresce mais rápido do que a sua capacidade de corrigir, converse com o nosso time de CyberSecurity e transforme o caos em um plano.