Um guia direto sobre o catálogo de vulnerabilidades mais usado no mundo da cibersegurança: o que é, quem mantém, como um identificador é atribuído e o que isso muda na prática para quem gerencia uma aplicação.
CVE é a sigla para Common Vulnerabilities and Exposures, em português algo como "Vulnerabilidades e Exposições Comuns". Não se trata de uma ferramenta nem de um software: é um catálogo público e gratuito que reúne falhas de segurança já conhecidas em programas, sistemas operacionais e equipamentos.
Cada falha registrada nesse catálogo ganha um identificador único, no formato CVE-AAAA-NNNNN, onde o ano indica quando o identificador foi reservado e o número final diferencia cada caso. Esse código funciona como um "nome oficial" da falha, usado por fabricantes, pesquisadores, ferramentas de scanner e equipes de segurança do mundo todo para falar exatamente da mesma coisa.
Sem um identificador padronizado, cada fabricante, pesquisador ou ferramenta de segurança poderia descrever a mesma vulnerabilidade de um jeito diferente. Um ID CVE elimina essa ambiguidade: quando alguém diz "CVE-2021-44228" (a famosa falha do Log4j), todo mundo no mundo da segurança sabe exatamente do que se trata, sem precisar de mais contexto.
O programa CVE nasceu em 1999 e é operado pela MITRE Corporation, uma organização sem fins lucrativos que administra centros de pesquisa nos Estados Unidos, com apoio da divisão de cibersegurança do governo americano. A MITRE não descobre as falhas sozinha: ela coordena o processo de catalogação.
Quem efetivamente atribui os identificadores são as chamadas CNAs (CVE Numbering Authorities): um grupo de aproximadamente uma centena de organizações autorizadas, que inclui grandes fabricantes de software, empresas de segurança e institutos de pesquisa. Quando uma dessas organizações identifica uma falha em seu próprio produto (ou recebe o relato de um pesquisador externo), ela reserva um número CVE, documenta o problema e, quando a correção já está disponível ou pronta para ser divulgada, publica a entrada no catálogo.
É importante notar que a entrada CVE em si é enxuta: normalmente traz só o identificador e uma descrição curta do problema. Detalhes técnicos mais profundos, como o nível de gravidade, o vetor de exploração e as versões afetadas, costumam estar em bases complementares, como o NVD (National Vulnerability Database) americano, que usa o identificador CVE como referência e adiciona essa camada extra de informação, incluindo a pontuação de severidade conhecida como CVSS.
O nome "CVE" junta dois conceitos parecidos, mas não idênticos:
Um erro no próprio código do software que permite que um invasor execute ações não autorizadas, como rodar comandos, instalar malware ou assumir privilégios de administrador, muitas vezes se passando por um usuário legítimo do sistema.
Um erro de código ou de configuração que, sozinho, não dá controle total sobre o sistema, mas abre uma porta de acesso indevido, permitindo, por exemplo, que alguém colete dados sensíveis, credenciais ou informações de clientes sem ser percebido.
Na prática, o catálogo trata os dois como a mesma categoria de risco, porque ambos podem servir de porta de entrada para um ataque maior: só muda o tipo de dano direto que cada um causa.
Se a sua empresa usa bibliotecas, frameworks, plugins de CMS ou qualquer componente de terceiros (e praticamente toda aplicação usa), existe uma boa chance de que, mais cedo ou mais tarde, uma CVE seja publicada para alguma dessas peças. O problema não é a existência da falha em si (isso é normal e constante no ecossistema de software); o problema é não saber que ela existe no seu ambiente ou demorar para aplicar a correção depois que ela já é pública.
É exatamente esse o intervalo que os atacantes exploram: no momento em que uma CVE crítica é divulgada, ela vira um roteiro pronto de ataque, muitas vezes com prova de conceito publicada junto, para qualquer sistema que ainda não tenha sido corrigido. Por isso, mapear quais CVEs afetam os componentes da sua stack é uma das primeiras coisas que analisamos em uma análise gratuita ou em um Pentest Web completo.
Durante o reconhecimento inicial de qualquer projeto, identificamos versões de software, bibliotecas e serviços expostos e cruzamos com bases de CVEs conhecidas para saber se existem falhas públicas já documentadas, antes mesmo de partir para os testes manuais de exploração.
Como uma entrada CVE em si é enxuta (basicamente um identificador e uma descrição curta), o mercado de segurança precisava de um jeito padronizado de responder à pergunta óbvia: "essa falha é grave o suficiente para eu tratar agora, ou pode esperar?" É exatamente esse o papel do CVSS (Common Vulnerability Scoring System), um framework mantido pela FIRST.org que converte as características técnicas de uma vulnerabilidade em uma nota de 0 a 10.
O CVSS nasceu em 2005, encomendado originalmente pelo governo americano justamente porque, até então, cada fornecedor e cada empresa de segurança usava sua própria régua de gravidade, o que tornava praticamente impossível comparar riscos entre sistemas diferentes. Hoje já está na versão 4.0, e é a nota que a maioria dos scanners de vulnerabilidade, bases como o NVD e times de segurança usam para priorizar o que corrigir primeiro.
A pontuação final não é um número solto: ela é composta por grupos de métricas que olham para ângulos diferentes da mesma falha.
O núcleo da nota, e a única parte obrigatória para classificar uma vulnerabilidade no sistema CVSS. Avalia o quão fácil é explorar a falha (se o ataque pode ser feito remotamente, se exige interação do usuário, se precisa de privilégios prévios) e qual o impacto real na confidencialidade, integridade e disponibilidade do sistema afetado.
Ajustam a nota conforme o cenário muda no mundo real: existe um exploit público disponível? Já há relatos de ataques ativos explorando essa falha? Ou ainda não passa de uma prova de conceito teórica?
Permitem que cada empresa recalcule a nota considerando o próprio ambiente: a mesma falha pode ser crítica em um servidor que guarda dados de clientes e quase irrelevante em uma máquina isolada, sem acesso à internet.
Adicionadas nas versões mais recentes do CVSS, cobrem fatores que não mudam a nota numérica, mas dão contexto extra, como se o ataque pode ser automatizado em massa ou qual o potencial de dano físico envolvido.
Uma vulnerabilidade "Crítica" (nota 9.5, por exemplo) em um sistema pouco relevante pode representar menos risco real do que uma vulnerabilidade "Média" (nota 5.5) em um sistema que processa pagamentos ou dados sensíveis. A nota base do CVSS mede a gravidade da falha em abstrato, não o risco real dela dentro do seu ambiente específico é por isso que uma avaliação de risco de verdade, feita por quem entende do seu negócio, continua sendo insubstituível.
Na prática, CVE, CVSS e NVD trabalham em conjunto: o CVE identifica e nomeia a falha, o CVSS avalia e pontua a gravidade dela, e o NVD reúne as duas informações em um banco de dados público e pesquisável, junto com a string de vetor que detalha exatamente como aquela nota foi calculada.
