O CVSS (Common Vulnerability Scoring System), mantido pelo FIRST, é a linguagem comum para descrever a severidade de uma vulnerabilidade. A versão 4.0 foi publicada em 1º de novembro de 2023 e mudou bastante coisa: métricas novas, um grupo inteiro novo, outra forma de calcular e uma nomenclatura que diz quais métricas foram usadas.
No artigo 48 mil CVEs por ano mostramos por que o CVSS sozinho prioriza mal. Este é o complemento: como ler a nota corretamente e como usar as partes do CVSS que a maioria das organizações ignora.
Severidade, não risco
A especificação é clara sobre o papel do CVSS: ele descreve características e severidade de vulnerabilidades, e as organizações podem usá-lo como entrada de um processo de gestão que também considere fatores fora do CVSS. Ele não diz quanto uma falha custa nem qual a chance de ela virar incidente na sua empresa.
A escala qualitativa continua a mesma da versão anterior:
| Classificação | Nota |
|---|---|
| Nenhuma | 0.0 |
| Baixa | 0.1 – 3.9 |
| Média | 4.0 – 6.9 |
| Alta | 7.0 – 8.9 |
| Crítica | 9.0 – 10.0 |
Os quatro grupos de métricas
| Grupo | O que mede | Quem preenche | Altera a nota? |
|---|---|---|---|
| Base | Características intrínsecas da falha: como é atacada e o que ela compromete. Não muda com o tempo nem com o ambiente | Fornecedor ou analista do boletim | Sim |
| Ameaça (Threat) | Maturidade da exploração: atacada, com prova de conceito pública ou sem relato | Quem usa o software, com inteligência de ameaças | Sim |
| Ambiente (Environmental) | Importância do ativo para confidencialidade, integridade e disponibilidade, e o efeito dos seus controles | Quem usa o software | Sim |
| Suplementar (Supplemental) | Informações extras: impacto em segurança física (Safety), automatização do ataque, recuperação, densidade de valor, esforço de resposta, urgência do fornecedor | Fornecedor | Não |
Para deixar claro o que foi preenchido, a versão 4.0 criou uma nomenclatura: CVSS-B (só Base), CVSS-BT (Base e Ameaça), CVSS-BE (Base e Ambiente) e CVSS-BTE (os três). A especificação recomenda usá-la sempre que uma nota numérica for exibida.
O que mudou em relação ao CVSS 3.1
- Attack Requirements (AT), métrica nova. Separa da complexidade do ataque as condições do próprio sistema vulnerável que precisam existir para o ataque funcionar, como uma configuração específica ou uma condição de corrida.
- Interação do usuário em três níveis. Nenhuma, passiva ou ativa, em vez de apenas sim ou não.
- Fim do "Scope". No lugar, o impacto é descrito em dois conjuntos: no sistema vulnerável (VC, VI, VA) e nos sistemas subsequentes (SC, SI, SA).
- Temporal virou Ameaça. O grupo ficou com uma métrica só, Exploit Maturity.
- Grupo Suplementar. Novo, e deliberadamente fora do cálculo.
- Outro cálculo. Em vez de uma fórmula, os cerca de 15 milhões de vetores possíveis foram agrupados em 270 conjuntos de severidade comparável, ordenados com base em comparações feitas por especialistas. A nota sai de uma tabela de referência e de interpolação.
Como ler o vetor
A nota é só o resumo. O que descreve a falha é o vetor. Um exemplo:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Lendo da esquerda para a direita: atacável pela rede (AV:N), com baixa complexidade (AC:L), sem requisitos especiais no alvo (AT:N), sem privilégio (PR:N) e sem interação de usuário (UI:N). O impacto no sistema vulnerável é alto em confidencialidade, integridade e disponibilidade, e não há impacto em sistemas subsequentes. A nota é 9.3, crítica.
A mesma falha, quatro notas
O detalhe que quase ninguém percebe: quando os grupos de Ameaça e de Ambiente não são preenchidos, a especificação assume o pior caso. Exploit Maturity vazia equivale a "atacada", e os requisitos de segurança do ativo vazios equivalem a "alto". A nota Base publicada já é, portanto, a nota do cenário mais pessimista.
Veja o que acontece com o vetor acima quando a sua organização preenche o que sabe:
| O que foi preenchido | Nota | Classificação |
|---|---|---|
| Só Base (CVSS-B) | 9.3 | Crítica |
| + prova de conceito pública, sem ataques relatados (E:P) | 8.9 | Alta |
| + nenhuma exploração conhecida (E:U) | 8.1 | Alta |
| + sem exploração conhecida, em sistema de baixa importância (E:U, CR:L, IR:L, AR:L) | 6.5 | Média |
A falha é a mesma nas quatro linhas. O que muda é o quanto a organização sabe sobre a ameaça e sobre o próprio ambiente. É por isso que uma fila de tratamento montada só com notas Base parece urgente demais: todas as linhas estão no pior caso.
Na prática: cinco regras
- Rotule a nota. Em relatório e painel, escreva CVSS-B ou CVSS-BTE. Um 9.3 de Base e um 9.3 com ameaça e ambiente preenchidos não dizem a mesma coisa.
- Preencha Ameaça automaticamente. O catálogo KEV da CISA indica exploração confirmada; o EPSS e a inteligência de ameaças ajudam a separar prova de conceito de nenhum relato.
- Preencha Ambiente por classe de ativo, não por falha. Defina uma vez os requisitos de confidencialidade, integridade e disponibilidade para grupos de ativos — os que suportam processos críticos em alto, laboratório e testes em baixo — e aplique a todas as falhas daquele grupo.
- Use o Suplementar para desempatar. "Automatable: Yes" indica uma falha que pode ser explorada em escala; "Safety" é decisivo em ambientes industriais e de saúde.
- Não misture versões no mesmo ranking. Durante a transição, muitas fontes ainda publicam notas 3.1. O cálculo é diferente; trate a versão como parte do dado.
Feito isso, a nota deixa de ser um rótulo genérico do fornecedor e passa a dizer algo sobre a sua organização. Para chegar a uma prioridade de verdade, ela ainda precisa ser cruzada com exposição e impacto para o negócio — o que é o trabalho de um score de risco bem construído.
Fontes consultadas em 04/10/2026: CVSS v4.0 Specification Document, do FIRST, incluindo a escala qualitativa e o histórico de versões; calculadora de referência do CVSS v4.0, publicada pelo FIRST, usada para calcular as notas dos exemplos. Consulte a especificação oficial antes de definir a sua política de pontuação.