Você encontrou serviços, versões e potenciais falhas. Agora precisa de uma linguagem comum para identificá-las, entendê-las e priorizá-las — porque "achei uma falha no Apache" é vago, e um relatório profissional exige precisão. O ecossistema de segurança padronizou isso em três siglas que você usará todos os dias: CVE (identifica qual vulnerabilidade), CVSS (mede quão grave ela é) e CWE (classifica que tipo de fraqueza a originou). Dominar esse vocabulário é o que conecta o que você achou na enumeração com a decisão do que atacar e como reportá-lo.

CVE: um identificador para cada falha

Comece pelo CVE (Common Vulnerabilities and Exposures). É um catálogo público e universal que atribui um identificador único a cada vulnerabilidade conhecida, no formato CVE-ANO-NÚMERO — por exemplo, o Heartbleed é o CVE-2014-0160 e o EternalBlue está associado ao CVE-2017-0144. A genialidade do CVE é ser uma referência comum: quando você diz "o alvo é vulnerável ao CVE-2017-0144", qualquer profissional no mundo, qualquer ferramenta, qualquer base de dados sabe exatamente a que você se refere, sem ambiguidade. É o "nome próprio" de cada vulnerabilidade. Quando sua enumeração revela "vsftpd 2.3.4", você pesquisa por CVEs associados a essa versão e descobre precisamente quais falhas conhecidas ela tem. Bases como o NVD (National Vulnerability Database) e o Exploit-DB conectam CVEs a detalhes técnicos e, crucialmente, a exploits disponíveis.

CVSS: uma nota de 0 a 10

O CVSS (Common Vulnerability Scoring System) responde à pergunta seguinte: "quão grave é?". É um sistema que atribui a cada vulnerabilidade uma nota de 0.0 a 10.0, derivada de um conjunto de métricas sobre a falha — quão fácil é explorá-la (precisa de acesso à rede ou só local? exige autenticação? exige interação da vítima?) e qual o impacto se explorada (afeta confidencialidade, integridade, disponibilidade? em que grau?). A nota se traduz em faixas de severidade: baixa (0.1–3.9), média (4.0–6.9), alta (7.0–8.9) e crítica (9.0–10.0). A versão vigente é o CVSS 4.0, que refinou as métricas em relação ao amplamente usado 3.1, buscando maior precisão e melhor tratamento de contexto. O CVSS é a base para priorizar: diante de vinte achados, você naturalmente olha primeiro para os críticos e altos.

Severidade técnica não é risco real

Mas — e este "mas" é uma das lições profissionais mais importantes do curso, já antecipada na aula Governança, risco e compliance: por que o cliente realmente paga — o CVSS mede severidade técnica, não risco real. Uma vulnerabilidade CVSS 9.8 num servidor de testes isolado, sem dados sensíveis e sem acesso externo, representa risco de negócio muito menor que uma CVSS 6.5 no sistema que processa os pagamentos e está exposto à internet. O CVSS base não sabe nada sobre o seu ambiente — o valor do ativo, sua exposição, os controles compensatórios existentes. O pentester maduro usa o CVSS como ponto de partida da priorização e então o ajusta pelo contexto: um achado de severidade média num ativo crítico pode merecer atenção antes de um crítico num ativo irrelevante. Reportar apenas a nota CVSS, sem contextualizar o risco para o negócio, é o erro do amador que confunde o número com a sabedoria. (O próprio CVSS prevê métricas ambientais e temporais para esse ajuste, mas o essencial é o princípio: número técnico não é risco de negócio.)

CWE: o tipo de fraqueza que causou

O terceiro membro, o CWE (Common Weakness Enumeration), opera num nível diferente e complementar: enquanto o CVE identifica uma vulnerabilidade específica num software específico, o CWE classifica o tipo de fraqueza que a causou. Por exemplo, muitos CVEs diferentes têm como raiz o CWE-89 (SQL Injection), ou o CWE-79 (Cross-Site Scripting), ou o CWE-787 (escrita fora dos limites de memória). O CWE é a taxonomia das causas. Ele é valioso por dois motivos: ajuda a entender a natureza de uma falha (e portanto como corrigi-la de forma estrutural, não pontual), e permite reconhecer padrões — se você encontra vários CVEs do mesmo CWE num alvo, isso sugere uma fraqueza sistêmica de desenvolvimento, não incidentes isolados. Para o relatório, citar o CWE eleva a análise de "conserte este bug" para "sua equipe tem um padrão de falhas dessa classe; eis como preveni-las".

As três siglas no fluxo de trabalho

Juntando as três, veja o fluxo profissional completo: sua enumeração identifica um serviço e versão → você pesquisa CVEs aplicáveis àquela versão → avalia a gravidade de cada um pelo CVSS, ajustando pelo contexto do ativo → entende a natureza pela classificação CWE → e verifica (no Exploit-DB, no NVD) se há exploit público disponível, o que determina a viabilidade prática de explorá-la na fase seguinte. Esse encadeamento transforma "encontrei serviços abertos" em "identifiquei vulnerabilidades específicas, priorizadas por risco real, com caminhos de exploração conhecidos" — que é exatamente o que a fase de exploração (Bloco VIII) vai consumir.

A mesma linguagem estrutura a defesa

Do lado defensivo, essa mesma linguagem estrutura a gestão de vulnerabilidades: as equipes usam CVEs para rastrear o que as afeta, CVSS (ajustado ao contexto) para priorizar a remediação, e a análise de CWE para atacar causas-raiz nos processos de desenvolvimento. E há uma fonte que unifica tudo, que vale conhecer: o catálogo KEV (Known Exploited Vulnerabilities) da CISA, que lista vulnerabilidades sabidamente exploradas na prática — uma priorização baseada em realidade (está sendo usada por atacantes agora) que muitas vezes supera a pura nota CVSS.

Fontes e leituras recomendadas

  • NVD (nvd.nist.gov) — base nacional de vulnerabilidades, com CVEs, CVSS e CWE
  • Exploit-DB (exploit-db.com) — CVEs conectados a exploits públicos
  • FIRST.org — especificação oficial do CVSS 4.0
  • CISA KEV Catalog — vulnerabilidades conhecidamente exploradas (priorização real)
  • MITRE CWE (cwe.mitre.org) — a taxonomia de fraquezas

Exercícios

  1. O que é um CVE e qual a genialidade de ele funcionar como "referência comum"?

    ✓ Resposta:

    CVE (Common Vulnerabilities and Exposures) é um catálogo que atribui um identificador único a cada vulnerabilidade conhecida (formato CVE-ANO-NÚMERO). Sua genialidade é ser uma referência universal: ao citar um CVE, qualquer profissional, ferramenta ou base sabe exatamente a que vulnerabilidade se refere, sem ambiguidade.

  2. O que o CVSS mede, qual sua escala, e quais as faixas de severidade?

    ✓ Resposta:

    Mede a gravidade de uma vulnerabilidade numa escala de 0.0 a 10.0, com base na facilidade de exploração e no impacto (sobre CIA). Faixas: baixa (0.1–3.9), média (4.0–6.9), alta (7.0–8.9) e crítica (9.0–10.0).

  3. Explique por que "CVSS mede severidade técnica, não risco real", com um exemplo em que uma nota menor representa risco de negócio maior.

    ✓ Resposta:

    Porque o CVSS base avalia a falha isoladamente, sem conhecer o valor do ativo, sua exposição ou controles compensatórios. Exemplo: uma CVSS 6.5 no sistema de pagamentos exposto à internet representa risco de negócio maior que uma CVSS 9.8 num servidor de testes isolado, sem dados sensíveis nem acesso externo.

  4. Qual a diferença entre CVE e CWE, e por que reconhecer padrões de CWE num alvo é valioso?

    ✓ Resposta:

    O CVE identifica uma vulnerabilidade específica num software específico; o CWE classifica o tipo de fraqueza que a originou (ex.: CWE-89, SQL Injection). Reconhecer padrões de CWE é valioso porque vários CVEs do mesmo CWE num alvo indicam uma fraqueza sistêmica de desenvolvimento, permitindo corrigir a causa-raiz em vez de bugs isolados.

  5. Descreva o fluxo profissional que conecta enumeração → CVE → CVSS → CWE → exploit, e o que ele entrega para a fase de exploração.

    ✓ Resposta:

    A enumeração identifica serviço e versão → pesquisam-se os CVEs aplicáveis → avalia-se a gravidade por CVSS, ajustada ao contexto do ativo → entende-se a natureza pelo CWE → verifica-se a existência de exploit público. Isso entrega à fase de exploração uma lista de vulnerabilidades específicas, priorizadas por risco real e com caminhos de exploração conhecidos.