Quando "crítico" não é tão crítico: por que repensar a severidade das vulnerabilidades

A dimensão do ruído

O volume de vulnerabilidades divulgadas a cada ano torna essa conversa urgente. Em 2024, foram publicados mais de 40.000 novos CVEs, um aumento de 38% em relação aos aproximadamente 29.000 registrados em 2023. Até o final de 2025, esse número havia crescido mais 21%, chegando a 48.185. Isso representa mais de 100 novos identificadores de vulnerabilidades por dia. Uma parcela considerável deles recebe rótulos de severidade alta ou crítica pelo framework padrão de pontuação base CVSS (no ano passado, essa parcela foi de quase 40%). Se uma organização tentasse tratar cada achado CVSS crítico como uma emergência de verdade, esgotaria sua equipe e seu orçamento tentando reduzir riscos que talvez nem existam na prática.

No entanto, das dezenas de milhares de vulnerabilidades publicadas a cada ano, apenas uma pequena fração chega a ser explorada no mundo real. Uma análise dos dados de 2024 constatou que aproximadamente 0,9% dos CVEs reportados foram ativamente utilizados por agentes de ameaças. Uma análise separada estimou que a proporção de CVEs usados em ataques de ransomware ou por grupos de ameaças persistentes avançadas (APT) fica em torno de 0,2%.

Esses números não significam que as demais vulnerabilidades sejam inofensivas. No entanto, sugerem com força que o rótulo "crítico" é aplicado com muito mais frequência do que os padrões reais de exploração justificariam.

Onde as pontuações divergem

Se a severidade fosse uma medição completamente objetiva, seria de se esperar que diferentes autoridades, ao avaliar a mesma vulnerabilidade, chegassem a números semelhantes. Mas muitas vezes não é isso que acontece.

Um exame de aproximadamente 120.000 CVEs com pontuações CVSS v3.0 no NVD constatou que cerca de 20% deles (quase 25.000 entradas) apresentavam duas pontuações: uma atribuída pelo NIST e outra pelo fornecedor ou por um CNA terceiro. Desse subconjunto, 56% tinham pontuações conflitantes. Ou seja, em mais da metade dos casos em que tanto o NVD quanto o fornecedor se pronunciaram, houve discordância sobre a gravidade do problema.

Considere o caso do CVE-2023-21557, uma vulnerabilidade no protocolo LDAP do Windows, que é analisado na fonte citada. A Microsoft, empresa que escreveu o código e conhece a fundo os requisitos de exploração, atribuiu a ele 7,5 (alto), enquanto o NVD atribuiu 9,1 (crítico). Essa diferença de 1,6 ponto não é cosmética. Em uma organização, uma pontuação acima de 9,0 pode disparar protocolos de correção emergencial, tirando engenheiros de outras tarefas e alterando os ciclos de lançamento. Uma pontuação de 7,5, por outro lado, costuma cair dentro do ciclo regular mensal de aplicação de patches. A mesma vulnerabilidade provoca duas respostas muito diferentes dependendo do número em que você confia.

Esse tipo de diferença não é um caso isolado. Pesquisas demonstraram que as avaliações CVSS não são consistentes nem mesmo dentro da mesma pessoa ao longo do tempo. Em uma pesquisa de acompanhamento realizada nove meses após a avaliação inicial, 68% dos participantes atribuíram uma classificação de severidade diferente à mesma vulnerabilidade que haviam pontuado antes. Isso significa que o próprio sistema projetado para padronizar a severidade abre espaço para que a subjetividade se infiltre.

Além disso, um estudo independente identificou mais de 12.800 entradas no NVD em que vulnerabilidades com descrições idênticas ou semanticamente equivalentes receberam pontuações CVSS significativamente diferentes. E a inconsistência não se limitou a casos marginais; ela abrangeu tipos comuns de vulnerabilidades e produtos amplamente conhecidos.

A lógica do NVD

É importante ser justo com as razões por trás da forma como o NVD pontua. O próprio NVD explica em sua página de métricas de vulnerabilidades que o CVSS, tal como utilizado pelo NVD, é uma medida de severidade, não de risco. Essa mesma página reconhece que, quando um fornecedor ou mantenedor se abstém de fornecer certos detalhes, os esforços de enriquecimento do NVD atribuem valores às métricas CVSS "usando uma abordagem de pior cenário possível". "Informações excessivamente vagas ou indisponíveis» é o que motiva o enriquecimento que resulta nas diferenças de pontuação. Se, por exemplo, a fonte não especifica se uma vulnerabilidade exige autenticação, o NVD vai assumir que não exige, o que eleva a pontuação.

Essa política é defensável em tese. O NVD atende a um público amplo e diverso, e pecar pelo excesso de cautela em um aviso genérico tem a sua lógica. Porém, o efeito na prática é que uma pontuação concebida originalmente como uma estimativa conservadora para a configuração mais exposta possível se torna a severidade padrão que as ferramentas automatizadas, os painéis de controle e os frameworks de conformidade consomem e sobre a qual tomam decisões.

Daniel Stenberg, o criador e desenvolvedor principal do cURL, provavelmente um dos componentes de software mais implantados no mundo, já escreveu bastante sobre essa dinâmica. Em uma publicação de 2023 em seu blog, ele descreveu como o projeto cURL classificou uma vulnerabilidade (CVE-2022-42915) como de severidade média, dadas as condições muito limitadas nas quais poderia ser explorada. O NVD a pontuou com 9,8 (crítico), e é assim que ela aparece no GitHub. Stenberg observou em outra publicação que o NVD não pediu esclarecimentos nem detalhes à equipe do cURL; simplesmente aplicou sua própria avaliação. Em outro caso, uma vulnerabilidade do cURL envolvendo um estouro de inteiro na opção de linha de comando --retry-delay (um problema que Stenberg descreveu como um bug, mas não como um problema de segurança) foi inicialmente pontuada com 9,8 pelo NVD antes de ser finalmente reduzida a 3,3 após disputas repetidas. Há um ano, em uma publicação intitulada "CVSS is dead to us", Stenberg fala de mais um caso e menciona que o cURL não usa mais o CVSS. Se você conferir os avisos de CVE do projeto, eles exibem um dos níveis de severidade atribuídos pela equipe de segurança do cURL; não há CVSS à vista.

Citamos esses exemplos não para demonizar o NVD, que presta um serviço público essencial, mas para ilustrar um padrão. Quando a entidade que mais entende de um software discorda da entidade que o pontua para o mundo, e isso acontece com frequência, algo no sistema merece ser examinado com mais cuidado.

Os incentivos em jogo

Por que esse padrão persiste? Ajuda considerar os possíveis incentivos, sem presumir má-fé.

Para os agregadores como o NVD e o projeto Vulnrichment da CISA, o mandato é a proteção pública ampla. Como a própria documentação do NVD indica, quando os detalhes não são claros, a política é assumir o pior cenário. É um critério razoável para um banco de dados de acesso público, mas que favorece as pontuações mais altas.

Para as ferramentas de testes de segurança, a estrutura de incentivos também pode tender para severidades mais altas. Uma ferramenta que reporta menos achados críticos do que um concorrente corre o risco de ser vista como menos minuciosa, já que encontrar mais costuma ser equiparado a ser melhor. No que diz respeito a vulnerabilidades conhecidas, as ferramentas podem simplesmente herdar as pontuações base CVSS do NVD ou dos avisos dos fornecedores e exibi-las sem ajustes de alcançabilidade, explorabilidade ou contexto específico do cliente. As premissas conservadoras embutidas nessas pontuações de origem são repassadas sem questionamento, e o painel da ferramenta acaba reforçando a mesma inflação que, em princípio, poderia ajudar a corrigir.

Para os fornecedores de software que atuam como CNAs, o cenário é mais complexo. De um lado, um fornecedor que classifique sistematicamente suas próprias vulnerabilidades como baixas pode enfrentar acusações de que está minimizando problemas de segurança. De outro, um fornecedor que classifique tudo como crítico pode alarmar seus clientes.

Para os pesquisadores de segurança independentes, os CVEs têm valor profissional. Um achado de severidade crítica atrai mais atenção e pode se converter em pagamentos de programas de recompensa por bugs (bug bounty) ou em avanço na carreira. O pesquisador Florian Hantke testou isso na prática. Ele buscou padrões de injeção SQL no GitHub, encontrou uma aplicação de provas online cujo repositório não era atualizado havia três anos e cujo README indicava que estava essencialmente abandonada, explorou a falha em minutos e submeteu uma solicitação de CVE. Foi aceita. Uma busca no Shodan não havia revelado nenhuma instância do software acessível publicamente; mesmo assim, a vulnerabilidade foi publicada no NVD e, como Hantke escreveu, classificada com uma pontuação alta. Sua conclusão: "precisamos recalibrar como percebemos e valorizamos os CVEs".

Uma pergunta melhor do que "quão grave poderia ser?"

A pontuação base do CVSS responde a uma pergunta específica: no pior cenário e em um ambiente genérico, quanto dano essa vulnerabilidade poderia causar se fosse explorada? É uma pergunta válida. Mas não é a pergunta que a maioria das equipes de segurança precisa responder no dia a dia. A pergunta mais útil é: qual a probabilidade de essa vulnerabilidade ser explorada no nosso ambiente, e qual seria o impacto no nosso contexto específico?

Dois frameworks surgiram para ajudar a responder a essa pergunta com maior precisão.

O EPSS (Exploit Prediction Scoring System), mantido pela FIRST, utiliza aprendizado de máquina treinado com dados reais de exploração para estimar a probabilidade de que um determinado CVE seja explorado nos próximos 30 dias. O EPSS produz uma pontuação entre 0 e 1 (0% a 100%). A maioria das vulnerabilidades (mesmo aquelas com pontuações CVSS altas) tem pontuações EPSS muito baixas. Segundo os próprios dados de desempenho da FIRST, uma estratégia de remediar todos os CVEs com pontuação CVSS de 7 ou acima resulta em uma eficiência de aproximadamente 4%; ou seja, apenas cerca de 4 em cada 100 vulnerabilidades remediadas sob essa política foram de fato exploradas nos 30 dias seguintes. O artigo de pesquisa original do EPSS também cita pesquisas anteriores segundo as quais apenas 1,4% das vulnerabilidades publicadas foram exploradas no mundo real. A Fluid Attacks integrou o EPSS à sua plataforma justamente para ajudar as equipes a se concentrar nessa pequena fração.

O SSVC (Stakeholder-Specific Vulnerability Categorization), desenvolvido pelo Software Engineering Institute da Carnegie Mellon University em colaboração com a CISA, adota uma abordagem diferente. Em vez de produzir uma pontuação numérica, o SSVC utiliza árvores de decisão que consideram o estado atual de exploração, a criticidade da missão do ativo afetado e a prevalência do componente vulnerável. O resultado é uma recomendação orientada à ação (track, attend ou act) em vez de um número que pode ou não corresponder a uma resposta no mundo real.

Nem o EPSS nem o SSVC substituem o CVSS. Eles o complementam ao acrescentar dimensões que representam o risco.

O que isso significa para organizações que desenvolvem software

Se a sua equipe desenvolve aplicações, é muito provável que esteja consumindo pontuações CVSS de múltiplas fontes: ferramentas SAST, scanners SCA, o pipeline de análise de contêineres, o próprio NVD. As discrepâncias descritas neste artigo não são problema de outra pessoa; elas chegam diretamente aos seus painéis e ao backlog dos seus sprints.

Alguns princípios podem ajudar a filtrar o ruído:

• Entenda como as ferramentas classificam as vulnerabilidades: Nem todas as ferramentas pontuam os achados da mesma forma. Algumas herdam as pontuações base CVSS diretamente do NVD; outras aplicam sua própria lógica de severidade; outras permitem que você faça ajustes com base em fatores ambientais. Saber qual abordagem as suas ferramentas adotam, e de onde vêm as pontuações delas, ajuda você a interpretar corretamente um rótulo de "crítico" em vez de reagir de forma automática.

• Verifique antes de escalar: Um rótulo de crítico sobre um segredo embutido no código significa muito pouco se ninguém confirmou se a credencial está ativa. Um rótulo de crítico sobre uma vulnerabilidade de biblioteca significa muito pouco se a função vulnerável nunca é chamada no seu código. As equipes que lidam bem com severidade investem em verificação; ou seja, conferem se os achados são alcançáveis, funcionais e exploráveis no contexto antes de tratá-los como emergências.

• Use múltiplos sinais: O CVSS informa sobre o impacto potencial; o EPSS informa sobre a probabilidade; o catálogo KEV da CISA indica o que já está sendo explorado. Depender de apenas uma dessas fontes pode criar pontos cegos.

• Documente o seu raciocínio: Se você decide reduzir a prioridade de um achado com pontuação CVSS crítica porque o EPSS está próximo de zero e o componente não é alcançável, documente essa decisão. Regulamentações como a NIS2 na Europa e as regras de divulgação de cibersegurança da SEC enfatizam processos demonstrados de gestão de riscos, e não a ausência de vulnerabilidades rotuladas como "críticas".

• Cuidado com a fadiga de alertas: Equipes que estão o tempo todo apagando incêndios por achados que no fim das contas não têm impacto real acabam deixando de prestar atenção, e é justamente aí que uma vulnerabilidade verdadeiramente perigosa passa despercebida. Já escrevemos sobre esse problema antes.

Queremos deixar claro o espírito deste artigo. O NVD, a CISA, a FIRST, o ecossistema de CNAs, as soluções de testes de segurança e a comunidade de pesquisa em segurança desempenham papéis essenciais para tornar o software mais seguro. A intenção aqui não é enfraquecê-los, mas reconhecer que a classificação de severidade, da forma como é praticada hoje, tem limitações que as equipes de segurança precisam compreender e levar em conta.

A inflação de severidade não é fruto de incompetência nem de má intenção. É a consequência natural de um sistema em que diferentes atores, cada um agindo racionalmente dentro da sua própria estrutura de incentivos, produzem ou entregam números que nem sempre servem a quem precisa agir com base neles. Reconhecer isso é o primeiro passo para tomar decisões melhores.

O segundo passo é complementar o CVSS com contexto: dados reais de exploração, criticidade dos ativos, análise de alcançabilidade e julgamento profissional. Os desenvolvedores de ferramentas, por sua vez, podem contribuir investindo em precisão. Em vez de retransmitir uma pontuação base CVSS tal como ela vem da fonte original, uma ferramenta pode tentar verificar se a vulnerabilidade é alcançável no código do cliente, se as condições para a exploração realmente existem e se o componente afetado está exposto. Isso é mais difícil e mais caro do que simplesmente repassar um número, mas é também o que separa um achado útil do ruído. Na Fluid Attacks, essa é a filosofia por trás da nossa abordagem de pontuação. Preferimos informar que um segredo vazado tem severidade baixa porque ainda não confirmamos o risco que ele representa, em vez de rotular tudo como crítico e deixar para você a tarefa de filtrar o ruído.