Uma Common Vulnerability and Exposure (CVE) é uma falha de segurança conhecida e catalogada. Quando uma vulnerabilidade recebe um CVE, significa que a comunidade de segurança a identificou, nomeou e adicionou a um banco de dados público (principalmente cve.org com pontuação e contexto adicionados pelo National Vulnerability Database (NVD) do NIST) para que qualquer pessoa possa consultá-la e agir sobre ela. O rastreamento de CVEs oferece ao mundo da segurança um ponto de referência comum, para que as equipes possam priorizar e responder a falhas conhecidas antes que os invasores as explorem. Simples na teoria, certo?
O problema é o seguinte: mais de 48.000 CVEs foram publicados somente em 2025. Isso significa 131 novas vulnerabilidades todos os dias. Modelos de IA e recursos de varredura estão tornando a descoberta de vulnerabilidades mais rápida e acessível do que nunca, mas validar os resultados em escala é mais difícil porque o grande volume de submissões está superando a infraestrutura construída para lidar com eles. O NVD está cedendo sob o volume, e um número crescente de vulnerabilidades reais nunca é relatado.
Este guia aborda como os CVEs funcionam, como são pontuados, onde o sistema está falhando e o que as equipes estão fazendo para se manterem à frente.
O que um registro de CVE inclui?
Um ID de CVE é como um número de série, formatado como: 'CVE-YYYY-####'.
Cada registro contém:
- ID de CVE
- Descrição
- Referências
- CNA Atribuinte
- Data de Criação do Registro
Registros de CVE mais antigos também podem incluir campos legados, como fase, votos, comentários e proposto, que não são mais usados em novas entradas.
Quem mantém o banco de dados CVE?
A resposta curta é: nenhuma organização sozinha. E esse é cada vez mais o problema.
A corporação MITRE supervisiona o programa CVE, atribuindo IDs e mantendo a lista oficial, e todos os registros de CVE são gratuitos para pesquisa e uso. O NVD tem sido historicamente onde essas entradas brutas de CVE são enriquecidas com pontuações CVSS, detalhes de patches e contexto técnico. É também de onde a maioria das ferramentas de segurança extrai seus dados. A Cybersecurity and Infrastructure Security Agency (CISA) fornece suporte financeiro. Outros bancos de dados, como o CERT/CC Vulnerability Notes Database e o GitHub Advisory, preenchem lacunas adicionais.
Mas nenhum deles foi realmente completo, e em 2026, as falhas são difíceis de ignorar. O NIST adotou uma abordagem 'baseada em risco' que prioriza CVEs para software do governo dos EUA e aqueles no catálogo de Known Exploited Vulnerabilities (KEV), deixando o restante não enriquecido, com o crescente backlog efetivamente movido para 'não agendado'. O programa CVE da MITRE enfrentou problemas de financiamento. A UE lançou sua própria alternativa, o European Vulnerability Database (EUVD), mas ainda está em seus estágios iniciais e ainda depende muito da sincronização com o NVD. Não há mais uma única fonte de verdade, e depender de um único banco de dados significa ter menos cobertura e visibilidade do que se espera. Este é exatamente o problema que o Aikido Intel foi projetado para resolver: monitorar milhões de pacotes de código aberto em busca de patches relevantes para a segurança que nunca chegam a nenhum banco de dados oficial, e alimentar os resultados diretamente na plataforma Aikido para que os usuários sejam alertados automaticamente.
Como os CVEs são encontrados e atribuídos?
Qualquer pessoa pode relatar uma vulnerabilidade: empresas de segurança, pesquisadores independentes, desenvolvedores individuais, até mesmo usuários curiosos. Muitas organizações executam programas de bug bounty que pagam pesquisadores por descobertas válidas, e projetos de código aberto geralmente dependem da divulgação da comunidade.
Uma vez que uma vulnerabilidade é relatada, uma CVE Numbering Authority (CNA) a valida, atribui um ID de CVE, escreve uma breve descrição e adiciona referências antes de publicá-la na lista oficial de CVEs. CNAs são organizações autorizadas pela MITRE a atribuir CVEs dentro de um escopo definido, incluindo grandes fornecedores como Microsoft, Google e RedHat, fundações de código aberto como Python Software Foundation, empresas de pesquisa de segurança, bem como plataformas como Django e GitLab. Normalmente, um ID de CVE é atribuído antes que a vulnerabilidade seja tornada pública. Os fornecedores mantêm os detalhes em segredo enquanto desenvolvem e testam uma correção, e então divulgam tudo de uma vez. Isso é conhecido como divulgação coordenada, o padrão amplamente recomendado para relatórios responsáveis de vulnerabilidades, apoiado pela CISA, ENISA e FIRST.
Nem todo problema relatado se qualifica. Três critérios devem ser atendidos:
- Corrigível independentemente: A falha pode ser corrigida por si só, independentemente de outros bugs.
- Reconhecido pelo fornecedor: O fornecedor confirma que o problema representa um risco de segurança, ou um relatório de terceiros demonstra seu impacto.
- Afeta uma única base de código: Se uma vulnerabilidade afeta vários produtos, cada um recebe seu próprio CVE. Os registros são mantidos o mais isolados possível.
Como posso encontrar registros CVE?
As informações de CVE são gratuitas e publicamente disponíveis. Para um feed ao vivo de novas entradas, siga @CVEnew no X. Com a taxa atual de mais de 130 novos CVEs por dia, ele se move rapidamente. Para acesso em massa a registros históricos desde 1999, CVE.org/Downloads oferece o banco de dados completo via um repositório GitHub no formato JSON 5.0/5.1, atualizado aproximadamente a cada sete minutos. CVEdetails.com fornece uma interface mais acessível e pesquisável com atualizações diárias.
Como você associa suas bibliotecas ao CVE correto?
Ao analisar uma vulnerabilidade, o ponto chave é fazer a correspondência entre o nome do pacote e o número da versão para garantir que você esteja olhando para o CVE correto para sua dependência específica. Ferramentas como o Aikido lidam com isso automaticamente, fazendo a correspondência de nomes de pacotes e versões com bancos de dados de vulnerabilidades, para que você não precise fazer isso manualmente.
O que é pontuação CVSS?
O CVSS (Common Vulnerability Scoring System) é o padrão usado para classificar a gravidade de uma vulnerabilidade em uma escala de 0.0 a 10.0. A maioria das entradas de CVE possui uma pontuação CVSS, fornecendo às equipes de segurança uma leitura rápida sobre a seriedade de uma falha. As pontuações CVSS são tipicamente atribuídas pelo NVD como parte de seu processo de enriquecimento, embora as CNAs também possam fornecer pontuações. Onde houver divergência, ambas podem ser listadas.
Como uma pontuação CVSS é calculada?
CVSS v4.0 é composto por quatro grupos de métricas:
- Base: captura as características intrínsecas de uma vulnerabilidade que são constantes ao longo do tempo
- Ameaça: reflete como essas características mudam com base na atividade de exploração no mundo real
- Ambiental: considera fatores específicos da configuração da sua organização
- Suplementar: adiciona contexto extra sem afetar a pontuação final
Qual é a escala de pontuação CVSS?
A (v4.0) Escala de Pontuação CVSS atual inclui cinco categorias:
- Crítico (9.0–10.0)
- Alto (7.0–8.9)
- Médio (4.0–6.9)
- Baixo (0.1–3.9)
- Nenhum (0.0)
Para contextualizar a escala, aqui estão alguns exemplos reais:
- Crítico: CVE-2021-44228 (Log4Shell). Pontuação CVSS v3.1: 10.0. Uma execução remota de código no Apache Log4j. Um atacante poderia executar código arbitrário em um servidor enviando uma mensagem de log especialmente elaborada. Uma das vulnerabilidades mais severas já divulgadas.
- Alto: CVE-2017-0144 (EternalBlue). Pontuação CVSS v3.1: 8.8. Uma falha no Windows SMB (Server Message Block). Originalmente desenvolvido como um exploit pela NSA, foi vazado em 2017 e quase imediatamente transformado em arma nos ataques de ransomware WannaCry e NotPetya, que causaram bilhões em danos em todo o mundo.
Para os níveis mais baixos, exemplos conhecidos são mais raros, já que vulnerabilidades de baixa gravidade geralmente não viram notícia. Na prática:
- Médio: Geralmente inclui falhas que exigem condições específicas para exploração, por exemplo, uma vulnerabilidade de cross-site scripting que precisa de interação do usuário, ou uma má configuração expondo dados não críticos.
- Baixo: Falhas que exigem acesso local ou condições incomuns, por exemplo, um arquivo de configuração com credenciais padrão que só pode ser acessado localmente.
- Nenhum: Um problema relatado sem impacto de segurança confirmado
Baixe uma cópia do guia do usuário completo do sistema de pontuação CVSS.
Como encontro uma pontuação CVSS para um registro CVE?
As pontuações CVSS são exibidas diretamente na página de registro de cada CVE no NVD, com suporte para pontuações v3.x e v4.0, quando disponíveis. Tenha em mente que, à medida que a cobertura de enriquecimento do NVD diminui, as pontuações podem estar ausentes ou baseadas apenas na avaliação do remetente, em vez de uma análise independente. O banco de dados de vulnerabilidades do Aikido é uma referência cruzada útil, que se baseia em múltiplas fontes em vez de apenas o NVD.
O que é um CWE?
Common Weakness Enumeration (CWE) é uma lista desenvolvida pela comunidade de fraquezas comuns de software e hardware, mantida pela MITRE. O principal objetivo do CWE é interromper as vulnerabilidades na origem, eliminando os erros mais comuns antes que os produtos sejam entregues. Também oferece aos desenvolvedores uma estrutura compartilhada para discutir e abordar ameaças de segurança, com mapeamentos diretos para bancos de dados de vulnerabilidades como o CVE.
A distinção principal: CWE descreve a fraqueza subjacente que leva a uma vulnerabilidade, enquanto CVE identifica uma instância específica de uma vulnerabilidade. Pense no CWE como a categoria, e no CVE como a ocorrência. Assim como o CVE, o CWE possui seu próprio sistema de pontuação de gravidade via CWSS e CWRAF.
Dê uma olhada nos 25 CWEs mais perigosos para 2025.
Por que o monitoramento de CVE está ficando mais difícil
O problema do volume é real: as submissões de CVE aumentaram 263% entre 2020 e 2025, e as submissões nos primeiros três meses de 2026 são quase um terço maiores do que no mesmo período do ano passado. Esse crescimento está apenas acelerando, e os registros de código aberto são um grande motivo.
A IA reduziu drasticamente a barreira para a publicação de pacotes de código aberto, e os registros estão sentindo isso. O número de pacotes que chegam significa que uma revisão significativa é cada vez mais rara, e a infraestrutura construída para rastrear e contextualizar vulnerabilidades está sob a mesma pressão.
O NVD foi construído para enriquecer cada CVE, adicionando pontuações CVSS, listas de produtos e contexto técnico que tornam os registros CVE brutos realmente utilizáveis. O NIST enriqueceu quase 42.000 CVEs em 2025, o que representa 45% a mais do que em qualquer ano anterior. Mas esse aumento de produtividade não foi suficiente para acompanhar o crescente número de submissões. Como abordamos acima, o NIST agora despriorizou o enriquecimento para a maioria dos CVEs. As ferramentas nas quais sua equipe confia para identificar e pontuar vulnerabilidades estão, para uma fatia crescente do universo CVE, operando com dados incompletos sem avisar.
Os limites dos CVEs: o que não é reportado
O problema do NVD é apenas parte da história. A questão mais profunda é que os CVEs cobrem apenas o que é divulgado, e muito não é.
Em uma única semana de monitoramento do Aikido Intel, 12 das 16 vulnerabilidades sinalizadas não tinham CVE atribuído. Estes também não eram casos de borda obscuros. Axios, com 56 milhões de downloads semanais de npm, corrigiu silenciosamente uma vulnerabilidade de poluição de protótipo que ainda não possui CVE. Apache ECharts corrigiu um problema de cross-site scripting e nunca o divulgou. Das vulnerabilidades que eventualmente receberam um CVE, o tempo médio do patch à divulgação foi de 27 dias, com algumas levando até nove meses.
Em vez de depender de bancos de dados centralizados, o Intel usa LLMs treinados sob medida para escanear changelogs, notas de lançamento e mensagens de commit em milhões de pacotes de código aberto, identificando patches relevantes para segurança antes mesmo de receberem um ID CVE, e fazendo referência cruzada com cinco bancos de dados de vulnerabilidades chave para uma cobertura mais ampla. Se nenhuma divulgação existir, os engenheiros de segurança da Aikido validam e publicam um aviso com um ID de Vulnerabilidade Aikido. Em seu primeiro ano, 67% das vulnerabilidades sinalizadas pelo Intel nunca haviam sido divulgadas em nenhum banco de dados público. O Intel alimenta diretamente a plataforma Aikido, então, quando uma nova vulnerabilidade é encontrada, os usuários são alertados automaticamente, mesmo antes de receber um CVE.
O que posso fazer para manter uma postura de segurança robusta?
Nem todo CVE é seu problema. Você precisa de uma abordagem em camadas. As pontuações CVSS são um ponto de partida útil, mas não levam em conta seu contexto específico. Um sinal mais acionável é o catálogo KEV da CISA: se um CVE estiver listado lá, ele está sendo ativamente explorado na natureza. Mas o KEV cobre menos de 1% de todos os CVEs e se inclina para vulnerabilidades de perímetro de rede, então está longe de ser exaustivo.
O Exploit Prediction Scoring System (EPSS) é outra camada útil. Ele prevê a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias com base em Threat Intelligence do mundo real, ajudando você a despriorizar a longa cauda de CVEs que provavelmente nunca serão explorados. A Aikido oferece suporte nativo à priorização baseada em EPSS, rebaixando automaticamente problemas de baixo risco para que sua equipe possa focar no que realmente importa.
Antes de escalar qualquer vulnerabilidade, considere:
- Reachability: A função vulnerável pode não ser alcançável em sua aplicação, uma razão chave pela qual a Reachability analysis, e não as pontuações CVSS brutas, deve guiar sua priorização.
- Impacto nos negócios: O componente afetado pode não interagir com sistemas críticos, dados de clientes ou operações essenciais.
- Ambiente único: Sistemas personalizados ou legados podem enfrentar perfis de risco diferentes dos que a descrição padrão do CVE assume.
- Controles existentes: Você já pode ter defesas em vigor que neutralizam o risco.
- Restrições de recursos: Corrigir tudo não é realista. Priorize o que é realmente explorável e impactante.
Obtenha um scanner de vulnerabilidades
O melhor lugar para começar é Aikido Security, uma plataforma construída especificamente para reduzir o ruído que torna a maioria dos scanners de CVE exaustivos de usar. Scanners tradicionais exibem centenas de alertas brutos, independentemente de uma vulnerabilidade ser realmente explorável em seu ambiente. A Reachability analysis do Aikido rastreia caminhos de execução através do seu código para determinar quais vulnerabilidades podem ser genuinamente alcançadas e acionadas, filtrando problemas não alcançáveis, falsos positivos e descobertas irrelevantes, frequentemente alcançando até 95% de redução de ruído.
Fique à frente da CurVA
CVEs descrevem vulnerabilidades que já foram identificadas e catalogadas. No momento em que um CVE é publicado, os invasores podem ter tido dias ou semanas para agir sobre ele. E, como vimos acima, muitas vulnerabilidades nunca recebem um CVE.
Manter-se à frente significa mais do que correção reativa. Mantenha as dependências atualizadas e verifique seu código em relação ao Top 10 OWASP 2025 e benchmarks de conformidade CIS, as ferramentas padrão para identificar as fraquezas mais comuns e configurações de segurança incorretas básicas. Você pode verificar suas pontuações OWASP e CIS diretamente no Aikido. Para ameaças que ainda não foram catalogadas, o Aikido Intel monitora mais de 4,3 milhões de pacotes de código aberto para detectar vulnerabilidades antes que elas tenham um ID de CVE.
Veja quais CVEs realmente afetam sua base de código.
{{cta}}
