Guia de CVE — ler, pontuar e priorizar vulnerabilidade

Todo mundo aprende a rodar scanner. Pouca gente aprende a olhar o resultado e decidir o que corrigir primeiro. Este guia é sobre isso.

Uma CVE não é uma nota de gravidade. É um identificador, só isso: CVE-2021-44228 quer dizer "a quarenta e quatro mil duzentos e vigésima oitava vulnerabilidade catalogada em 2021". Quem dá nota é o CVSS, e quem diz se importa para você é outra coisa ainda.

Confundir essas cinco coisas é o erro mais comum de quem começa.

A relação entre elas: uma CVE é uma instância de uma CWE, recebe nota CVSS na NVD, tem probabilidade EPSS de ser explorada, e se já estiver sendo explorada entra no KEV.

Pegue CVE-2021-44228 (Log4Shell) como exemplo e abra os dois lados:

• Fonte do identificador: cve.org/CVERecord?id=CVE-2021-44228
• Enriquecido: nvd.nist.gov/vuln/detail/CVE-2021-44228

O campo mais ignorado é o CPE. Ele lista produto, fornecedor e faixa de versão. Sem ler isso você corrige o que não precisava, ou pior, acha que está seguro porque a versão "parece" diferente.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — nota 10.0. Traduzido:

Compare com AV:L/AC:H/PR:H/UI:R — precisa de acesso local, condição difícil, privilégio alto e um usuário cooperando. Mesmo que a nota base seja 7.0, é um problema completamente diferente.

Calculadora oficial: first.org/cvss/calculator/3.1. Rode o vetor de três CVEs reais nela e o formato deixa de ser sopa de letra.

CVSS sozinho é um péssimo critério de prioridade, porque metade das CVEs recebe nota alta. Use três eixos:

O catálogo KEV da CISA lista o que tem exploração confirmada no mundo real. Se a sua CVE está lá, ela sobe ao topo, independentemente da nota.

# baixar o catálogo e procurar uma CVE
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | .cveID, .dateAdded, .requiredAction'

O EPSS dá uma probabilidade de 0 a 1 de exploração nos próximos 30 dias, baseada em dados observados.

# consultar o EPSS de uma CVE
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | jq -r '.data[] | "\(.cve)  epss=\(.epss)  percentil=\(.percentile)"'

Na prática: uma CVE com CVSS 9.8 e EPSS 0.0004 é menos urgente que uma CVSS 7.5 com EPSS 0.87.

A pergunta que nenhuma base responde. Depende de:

• Você usa o produto e a versão afetada?
• O componente está exposto à rede, ou atrás de autenticação e segmentação?
• Existe mitigação já aplicada que quebra a condição de exploração?
• O que roda ali é crítico para o negócio?

Uma CVSS 10.0 num serviço interno, desligado, sem dado, atrás de firewall, perde para uma CVSS 6.5 no seu portal público de clientes.

A regra prática: KEV → corrija agora. EPSS alto + exposto → corrija esta semana. CVSS alto, EPSS baixo, não exposto → entra na fila normal de correção.

# o que está instalado, com versão
dpkg -l | grep -i openssl              # Debian/Ubuntu
rpm -qa | grep -i openssl              # RHEL/Fedora

# dependências de aplicação
npm audit                              # Node
pip-audit                              # Python
composer audit                         # PHP

# imagem de contêiner e sistema de arquivos
trivy image minha-imagem:tag
grype dir:.

Ferramentas: Trivy · Grype · pip-audit · OSV-Scanner

Para vulnerabilidade em dependência de código, a base mais precisa é a OSV, porque ela trabalha por versão de pacote em vez de CPE — e CPE erra muito em ecossistema de linguagem.

Três regras, sempre:

1. Leia o código antes de executar. PoC público com backdoor é comum, especialmente em repositório novo com CVE da moda.
2. Rode em lab isolado, nunca contra produção, nunca da sua máquina principal.
3. Desconfie de binário. Se o "exploit" é um .exe ou um script obfuscado, não é exploit, é malware.

Detectar exposição sem explorar é quase sempre suficiente e sempre mais seguro:

nuclei -u https://example.com -t http/cves/2021/CVE-2021-44228.yaml

Assine o do fabricante do que você usa. Acompanhar tudo é impossível e inútil.

Escrever uma análise própria de CVE é um dos artefatos que mais mostra maturidade, e ninguém precisa de autorização para fazer.

Escolha uma CVE recente e relevante, e escreva:

1. O que é o produto, e quem o usa
2. O mecanismo da falha, na sua palavra, com o trecho de código quando o patch é público
3. A leitura do vetor CVSS, e se você concorda com a nota
4. CWE e se o defeito é sistêmico naquele projeto
5. Como detectar exposição no seu ambiente, com comando
6. A mitigação, e a correção definitiva
7. O que o diff do patch mudou

Comparar o commit de correção com a versão vulnerável é o exercício que mais ensina. É um passo do projeto P12 e casa direto com docs/como-documentar.md.

• CVE Program — a fonte do identificador
• NVD — registro enriquecido, CVSS e CPE
• Especificação do CVSS 3.1 — o que cada métrica significa
• EPSS — modelo e API de probabilidade de exploração
• CISA KEV — exploração confirmada
• CWE — classes de defeito
• OSV — vulnerabilidade por versão de pacote

← Voltar ao índice