CVSS é útil. O problema começa quando a pontuação vira a fila. Duas vulnerabilidades com nota 9,8 podem representar riscos completamente diferentes no ambiente real: uma pode estar exposta à Internet e sendo explorada; a outra pode existir em um componente isolado, sem caminho até dados ou sistemas críticos.
Vulnerability Management amadurece quando deixa de perguntar apenas “qual é a severidade?” e passa a perguntar “qual correção reduz mais risco agora?”. Parece uma diferença semântica. Na prática, muda completamente a ordem do trabalho.
CVSS mede severidade, não contexto de negócio
O CVSS foi criado para padronizar características técnicas de uma vulnerabilidade. Ele ajuda a comparar vetores de ataque, complexidade, privilégios necessários, interação do usuário e impacto potencial.
Isso é valioso. O que ele não sabe é se o ativo está exposto, se o código vulnerável é alcançável, se existe exploração ativa, qual dado está por trás daquele sistema ou quanto tempo a organização leva para restaurá-lo.
Essas informações estão fora da pontuação. E são justamente as informações que definem prioridade operacional.
Em ambientes grandes, scanners produzem milhares ou milhões de achados. Se toda vulnerabilidade crítica entra no topo, a equipe recebe uma lista praticamente impossível de executar.
O resultado costuma ser previsível: backlog cresce, SLAs são violados, exceções se acumulam e ninguém consegue explicar por que uma CVE foi corrigida antes de outra.
A solução não é abandonar CVSS. É colocá-lo no lugar certo: um dos sinais, não o árbitro final.
Exploração real muda a conversa
O catálogo Known Exploited Vulnerabilities da CISA adiciona um dado objetivo importante: há evidência de que aquela vulnerabilidade está sendo explorada no mundo real.
Quando uma CVE entra no KEV e afeta um ativo exposto, o contexto muda rapidamente. Uma vulnerabilidade de severidade menor pode merecer correção antes de outra mais “crítica” que não possui exploração conhecida e está isolada.
Esse é um dos motivos pelos quais organizações maduras acompanham exploitation intelligence em vez de trabalhar apenas com pontuação estática.
O EPSS, mantido pela FIRST, tenta estimar a probabilidade de exploração de uma vulnerabilidade em um horizonte de curto prazo. Ele não mede impacto e não substitui análise interna, mas acrescenta um sinal útil.
Em termos simples: CVSS ajuda a entender quão ruim a falha pode ser; EPSS ajuda a estimar a chance de ela ser explorada; KEV diz que já existe evidência de exploração. O ambiente interno decide o que isso significa para a empresa.
Notícias Relacionadas
- PoC público e exploração em até 48 horas: quando a fila de vulnerabilidades precisa mudar
- CISA propõe uma “era da qualidade” para o CVE diante do avanço das vulnerabilidades
Exposição e reachability separam teoria de risco real
Uma falha em um componente Internet-facing é diferente da mesma falha em uma rede isolada. Da mesma forma, uma biblioteca vulnerável presente em um pacote não significa necessariamente que o caminho de código vulnerável é executado.
Reachability ajuda a entender se a vulnerabilidade é realmente acionável naquela aplicação. Não elimina a necessidade de correção, mas melhora a prioridade.
O mesmo vale para controles compensatórios. Um WAF, segmentação ou feature desativada pode reduzir temporariamente o risco. A palavra importante é “temporariamente”. Controle compensatório não deveria virar desculpa para nunca corrigir.
Um servidor de teste e um gateway de identidade podem ter a mesma CVE. O impacto potencial não é o mesmo.
Criticidade do ativo, sensibilidade dos dados, dependências, privilégio e blast radius precisam entrar na decisão. É por isso que Vulnerability Management depende tanto de inventário e CMDB confiáveis. Sem contexto de ativo, o scanner enxerga falhas; a organização não enxerga risco.
Um modelo de priorização que funciona melhor na prática
- Severidade técnica: usar CVSS como base comum.
- Exploração conhecida: elevar o que está no KEV ou possui evidência confiável de atividade.
- Probabilidade: usar EPSS como sinal adicional, entendendo suas limitações.
- Exposição: diferenciar Internet-facing, interno, segmentado e isolado.
- Reachability: verificar se o código ou função vulnerável é realmente alcançável.
- Criticidade: considerar dados, serviço, privilégio e impacto no negócio.
- Controles compensatórios: registrar mitigação com evidência e prazo.
Esse é um ponto que muitas equipes evitam dizer em voz alta. Em ambientes grandes, não há capacidade operacional para aplicar todas as correções imediatamente. Fingir que existe cria SLAs irreais e relatórios que ninguém usa.
Uma priorização madura reconhece a restrição e torna a decisão explícita. O importante é conseguir explicar por que uma vulnerabilidade ficou para depois, qual risco foi aceito e quais controles permanecem até a correção.
Fechar muitas vulnerabilidades de baixo risco pode melhorar um dashboard sem reduzir exposição significativa. Métricas como tempo para corrigir KEV, exposição de ativos críticos, idade de vulnerabilidades realmente exploráveis e reincidência costumam contar uma história melhor.
O objetivo de Vulnerability Management não é zerar scanner. É reduzir as oportunidades que um atacante realmente conseguiria usar.
Conclusão
CVSS continua sendo parte importante do processo. Só não consegue, sozinho, organizar uma fila que reflita risco real.
Quando severidade é combinada com exploração, probabilidade, exposição, reachability e criticidade, a conversa muda. A equipe deixa de perseguir números e passa a tomar decisões defensáveis.
A melhor fila não é a que parece mais bonita no relatório. É a que reduz risco mais rápido com a capacidade que a organização realmente tem.
Veja também
- IA acelera descoberta de vulnerabilidades e transforma remediação no novo gargalo
- CVE-2026-104286: falha crítica no FortiMail é explorada ativamente
Be the first to comment