Vulnerability Management: por que o CVSS sozinho não organiza sua fila
O CVSS é uma referência importante para avaliar vulnerabilidades, mas não deve ser usado como uma fila automática de correções. A pontuação descreve a gravidade técnica de uma falha; não informa, por si só, qual problema representa o maior risco para uma organização naquele momento.
Duas vulnerabilidades com nota 9,8 podem exigir respostas muito diferentes. Uma pode estar em um serviço acessível pela Internet e ser explorada ativamente. A outra pode afetar um componente isolado, sem acesso a sistemas relevantes nem possibilidade prática de acionar o código vulnerável. Tratar ambas como prioridades idênticas ignora justamente o contexto que orienta a decisão.
O CVSS ajuda a comparar aspectos técnicos, como vetor e complexidade do ataque, privilégios necessários, interação do usuário e possíveis impactos sobre confidencialidade, integridade e disponibilidade. Essa padronização é útil para classificar falhas e comunicar sua severidade. Mas a pontuação não conhece a arquitetura da empresa, os dados armazenados no ativo ou a capacidade de recuperação da equipe.
Em outras palavras, saber que uma falha pode ser grave não responde à pergunta operacional: qual correção reduz mais risco agora? É essa mudança de perspectiva que torna o gerenciamento de vulnerabilidades mais efetivo. O objetivo não é apenas acumular notas altas em uma lista, mas direcionar recursos limitados para os riscos mais urgentes.
A dificuldade fica evidente em ambientes com milhares de ativos e um grande volume de alertas produzidos por scanners. Se todo achado classificado como crítico for colocado no topo, a fila pode superar rapidamente a capacidade de correção. Backlogs aumentam, prazos deixam de ser cumpridos e exceções passam a se acumular sem uma justificativa clara.
Isso não significa abandonar o CVSS. Significa tratá-lo como um dos sinais de priorização, e não como o único critério. Para decidir a ordem de atendimento, a organização precisa combinar a severidade técnica com evidências de exploração, exposição, possibilidade de ataque e impacto sobre o negócio.
Um desses sinais é a presença da vulnerabilidade no catálogo KEV, da CISA, que reúne falhas para as quais há evidências de exploração no mundo real. Quando uma CVE desse tipo afeta um ativo exposto, a urgência pode mudar significativamente. Uma falha com nota inferior pode merecer atenção antes de outra mais grave no papel, mas sem exploração conhecida e em um sistema isolado.
O EPSS, mantido pela FIRST, acrescenta outra perspectiva: estima a probabilidade de uma vulnerabilidade ser explorada em um horizonte de curto prazo. Ele não mede o impacto para a empresa nem substitui uma avaliação interna, mas ajuda a identificar falhas que podem atrair tentativas de exploração. Em conjunto, os sinais respondem a perguntas diferentes: o CVSS indica a gravidade potencial, o EPSS estima a probabilidade de exploração e o KEV aponta evidências de exploração observada.
Também é essencial entender se o ativo pode ser alcançado por um atacante. Um serviço exposto à Internet tende a apresentar um cenário diferente daquele de um sistema restrito a uma rede segmentada. Da mesma forma, encontrar uma biblioteca vulnerável em um pacote não prova necessariamente que a aplicação executa o trecho de código afetado.
A análise de reachability ajuda a verificar se o caminho vulnerável está acessível dentro da aplicação e em quais condições poderia ser acionado. Essa informação torna a priorização mais precisa, mas não deve ser interpretada como garantia de segurança. Um achado considerado menos urgente ainda pode precisar de correção, especialmente se mudanças no sistema alterarem sua exposição ou utilização.
O peso do ativo completa a avaliação. Uma vulnerabilidade em um ambiente de testes não representa necessariamente o mesmo risco que a mesma falha em um gateway de identidade, em um sistema de pagamentos ou em uma plataforma que concentra dados sensíveis. Criticidade do serviço, tipo de informação, privilégios disponíveis e alcance de um possível comprometimento – o chamado blast radius – devem fazer parte da análise.
Por isso, a qualidade do inventário de ativos e da CMDB influencia diretamente o resultado do programa. Sem saber quem é responsável por um sistema, para que ele serve e quais outros serviços dependem dele, a equipe consegue identificar falhas, mas não avaliar adequadamente suas consequências. Contexto incompleto tende a produzir prioridades pouco confiáveis.
Controles compensatórios, como segmentação de rede, regras de WAF ou desativação de uma funcionalidade, podem reduzir o risco enquanto a correção não é aplicada. Ainda assim, devem ser registrados com responsáveis, prazo de revisão e evidências de funcionamento. Uma medida temporária não deve se transformar, por falta de acompanhamento, em uma justificativa permanente para manter a vulnerabilidade aberta.
Na prática, uma boa fila de trabalho combina exploração conhecida, probabilidade de ataque, exposição do ativo, reachability, criticidade do negócio e severidade técnica. A ordem final não precisa resultar de uma fórmula complexa, mas deve seguir critérios consistentes e documentados. Assim, diferentes equipes conseguem entender por que uma falha foi priorizada e outra ficou para depois.
Também é importante reconhecer os limites de capacidade. Em organizações grandes, nem sempre é possível aplicar todas as correções imediatamente. Fingir o contrário leva a prazos irreais e relatórios que não ajudam a tomar decisões. Uma gestão madura registra o risco aceito, identifica quem autorizou a exceção, define controles temporários e estabelece uma data para reavaliar o caso.
O desempenho do programa não deve ser medido apenas pela quantidade de vulnerabilidades fechadas. Indicadores como tempo de correção para falhas exploradas, número de ativos expostos sem proteção e idade das exceções ajudam a mostrar se o risco está diminuindo. Acompanhar a evolução desses dados permite ajustar prioridades e identificar gargalos no processo.
Quando a fila é construída com contexto, as equipes de segurança e tecnologia conseguem conversar sobre risco, e não apenas sobre números. O CVSS continua sendo uma peça valiosa dessa análise, mas a decisão de corrigir deve considerar o ambiente real, a ameaça existente e o impacto potencial para a organização.