Uma Vulnerabilidade e Exposição Comum (CVE) é uma falha de segurança conhecida e catalogada. Quando uma vulnerabilidade recebe um CVE, isso significa que a comunidade de segurança a identificou, nomeou e adicionou a uma base de dados pública (principalmente , cve.org e , com pontuação e contexto adicionados pela Base de Dados Nacional de Vulnerabilidades (NVD) do NIST), para que qualquer pessoa possa consultá-la e tomar medidas. O acompanhamento dos CVEs proporciona ao mundo da segurança um ponto de referência comum, para que as equipas possam priorizar e responder a falhas conhecidas antes que os atacantes as explorem. Simples na teoria, certo?
Eis o problema: só em 2025 foram publicados mais de 48 000 CVEs. Isso equivale a 131 novas vulnerabilidades por dia. Os modelos de IA e as capacidades de análise estão a tornar a deteção de vulnerabilidades mais rápida e acessível do que nunca, mas validar os resultados em grande escala é mais difícil, porque o volume de submissões está a ultrapassar a infraestrutura criada para as processar. O NVD está a sucumbir ao volume, e um número crescente de vulnerabilidades reais nunca chega a ser reportado.
Este guia aborda o funcionamento das CVEs, a forma como são classificadas, onde o sistema apresenta falhas e o que as equipas estão a fazer para se anteciparem a essas falhas.
O que um registro de CVE inclui?
Um ID CVE é como um número de série, com o formato: «CVE-AAAA-#####».
Cada registo contém:
- ID de CVE
- Descrição
- Referências
- CNA Atribuinte
- Data de Criação do Registro
Os registos CVE mais antigos podem também incluir campos antigos, tais como «fase», «votos», «comentários» e «proposto», que já não são utilizados nas novas entradas.
Quem mantém o banco de dados CVE?
A resposta curta é: nenhuma organização o faz sozinha. E isso é, cada vez mais, o problema.
A MITRE Corporation supervisiona o próprio programa CVE, atribuindo identificadores e mantendo a lista oficial, e todos os registos CVE podem ser pesquisados e utilizados gratuitamente. Historicamente, o NVD tem sido o local onde essas entradas CVE brutas 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 obtém os seus dados. A Agência de Cibersegurança e Segurança de Infraestruturas (CISA) fornece apoio financeiro. Outras bases de dados, como a Base de Dados de Notas de Vulnerabilidade do CERT/CC e o GitHub Advisory, preenchem lacunas adicionais.
Mas nenhuma destas bases de dados chegou a estar verdadeiramente completa e, em 2026, as lacunas são difíceis de ignorar. O NIST adotou uma abordagem «baseada no risco» que dá prioridade aos CVEs para software do governo dos EUA e aos que constam do catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), deixando o resto sem enriquecimento, com o crescente atraso efetivamente transferido para «não agendado». O programa CVE da MITRE tem enfrentado problemas de financiamento. A UE lançou a sua própria alternativa, a Base de Dados Europeia de Vulnerabilidades (EUVD), mas ainda está numa fase inicial e continua a depender fortemente da sincronização com o NVD. Já não existe uma única fonte de verdade, e depender de qualquer base de dados significa ter menos cobertura e visibilidade do que se esperava. Este é exatamente o problema que Aikido se propôs resolver: monitorizar milhões de pacotes de código aberto em busca de patches relevantes para a segurança que nunca chegam a qualquer base de dados oficial, e alimentar as descobertas diretamente na Aikido para que os utilizadores sejam alertados automaticamente.
Como é que as CVEs são identificadas e atribuídas?
Qualquer pessoa pode comunicar uma vulnerabilidade: empresas de segurança, investigadores independentes, programadores individuais e até mesmo utilizadores curiosos. Muitas organizações têm programas de recompensas por bugs que pagam aos investigadores por descobertas válidas, e os projetos de código aberto dependem normalmente da divulgação feita pela comunidade.
Assim que uma vulnerabilidade é comunicada, uma Autoridade de Numeração CVE (CNA) valida-a, atribui-lhe um ID CVE, redige uma breve descrição e adiciona referências antes de a publicar na lista oficial de CVE. As CNAs são organizações autorizadas pela MITRE a atribuir CVEs dentro de um âmbito definido, incluindo grandes fornecedores como a Microsoft, a Google e a RedHat, fundações de código aberto como a Python Software Foundation, empresas de investigação em segurança, bem como plataformas como o Django e o GitLab. Normalmente, um ID CVE é atribuído antes de a vulnerabilidade ser tornada pública. Os fornecedores mantêm os detalhes em segredo enquanto desenvolvem e testam uma correção, divulgando depois tudo de uma só vez. Isto é conhecido como divulgação coordenada, o padrão amplamente recomendado para a comunicação responsável de vulnerabilidades, apoiado pela CISA, ENISA e FIRST.
Nem todos os problemas comunicados são elegíveis. É necessário cumprir três critérios:
- Corrigível de forma independente: a falha pode ser corrigida por si só, independentemente de outros erros.
- Confirmado pelo fornecedor: O fornecedor confirma que o problema representa um risco de segurança, ou um relatório de terceiros demonstra o seu impacto.
- Afeta uma única base de código: se uma vulnerabilidade afetar vários produtos, cada um recebe o seu próprio CVE. Os registos são mantidos o mais isolados possível.
Como posso encontrar registros CVE?
As informações do CVE são gratuitas e estão disponíveis ao público. Para acompanhar em tempo real as novas entradas, siga @CVEnew no X. Com um ritmo atual de mais de 130 novos CVEs por dia, as atualizações são muito rápidas. Para acesso em massa aos registos históricos desde 1999, o CVE.org/Downloads disponibiliza a base de dados completa através de um repositório GitHub no formato JSON 5.0/5.1, atualizada aproximadamente a cada sete minutos. O CVEdetails.com oferece 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 fundamental é comparar o nome do pacote e o número da versão para garantir que está a consultar o CVE correto para a sua dependência específica. Ferramentas como Aikido tratam disso automaticamente, comparando os nomes e as versões dos pacotes com bases de dados de vulnerabilidades, pelo que não precisa de o fazer manualmente.
O que é a pontuação CVSS?
O CVSS (Common Vulnerability Scoring System) é a norma utilizada para classificar a gravidade de uma vulnerabilidade numa escala de 0,0 a 10,0. A maioria das entradas CVE inclui uma pontuação CVSS, o que permite às equipas de segurança avaliar rapidamente a gravidade de uma falha. As pontuações CVSS são normalmente atribuídas pelo NVD no âmbito do seu processo de enriquecimento, embora as CNAs também possam fornecer pontuações. Em caso de divergência, ambas podem ser indicadas.
Como uma pontuação CVSS é calculada?
O CVSS v4.0 é composto por quatro grupos de métricas:
- Base: capta as características intrínsecas de uma vulnerabilidade que se mantêm constantes ao longo do tempo
- Ameaça: reflete a forma como essas características variam em função da atividade de exploração no mundo real
- Ambiental: tem em conta fatores específicos da estrutura da sua organização
- Complementar: acrescenta contexto adicional sem afetar a pontuação final
Qual é a escala de pontuação CVSS?
A atual escala de pontuação CVSS (v4.0) inclui cinco categorias:
- Excelente (9,0–10,0)
- Elevado (7,0–8,9)
- Médio (4,0–6,9)
- Baixo (0,1–3,9)
- Nenhum (0,0)
Para contextualizar a dimensão, eis alguns exemplos reais:
- Crítica: CVE-2021-44228 (Log4Shell). Pontuação CVSS v3.1: 10,0. Uma vulnerabilidade de execução remota de código no Apache Log4j. Um atacante poderia executar código arbitrário num servidor enviando uma mensagem de registo especialmente criada para o efeito. Uma das vulnerabilidades mais graves alguma vez divulgadas.
- Alto: CVE-2017-0144 (EternalBlue). Pontuação CVSS v3.1: 8,8. Uma falha no SMB (Server Message Block) do Windows. Originalmente desenvolvida como uma exploração pela NSA, foi divulgada em 2017 e quase imediatamente utilizada nos ataques de ransomware WannaCry e NotPetya, que causaram prejuízos na ordem dos milhares de milhões em todo o mundo.
Nos níveis mais baixos, os exemplos de vulnerabilidades conhecidas são mais raros, uma vez que as vulnerabilidades de baixa gravidade não costumam chegar às manchetes. Na prática:
- Gravidade média: Normalmente inclui falhas que requerem condições específicas para serem exploradas, por exemplo, uma vulnerabilidade de cross-site scripting que necessita da interação do utilizador, ou uma configuração incorreta que expõe dados não críticos.
- Baixo: Falhas que exigem acesso local ou condições invulgares; por exemplo, um ficheiro de configuração com credenciais predefinidas ao qual só se pode aceder localmente.
- Nenhuma: Problema relatado sem impacto na 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 apresentadas diretamente na página de registo de cada CVE no NVD, com suporte tanto para pontuações v3.x como v4.0, quando disponíveis. Tenha em conta que, à medida que a cobertura de enriquecimento do NVD se reduz, as pontuações podem estar em falta ou basear-se exclusivamente na avaliação do remetente, em vez de numa análise independente. A base de dados de vulnerabilidades Aikido constitui uma referência cruzada útil, recorrendo a várias fontes em vez de apenas ao NVD.
O que é um CWE?
A Common Weakness Enumeration (CWE) é uma lista de vulnerabilidades comuns de software e hardware desenvolvida pela comunidade e mantida pela MITRE. O principal objetivo da CWE é impedir as vulnerabilidades na origem, eliminando os erros mais comuns antes da entrega dos produtos. Proporciona também aos programadores uma estrutura comum para debater e abordar ameaças à segurança, com correspondências diretas para bases de dados de vulnerabilidades como a CVE.
A principal diferença: o CWE descreve a falha subjacente que conduz a uma vulnerabilidade, enquanto o CVE identifica uma instância específica de uma vulnerabilidade. Pense no CWE como a categoria e no CVE como a ocorrência. Tal como o CVE, o CWE possui o seu próprio sistema de classificação de gravidade através do CWSS e do CWRAF.
Veja as 25 CWE mais perigosas para 2025.
Por que razão a monitorização de CVE está a tornar-se mais difícil
O problema do volume é real: as notificações de vulnerabilidades (CVE) aumentaram 263% entre 2020 e 2025, e as notificações nos primeiros três meses de 2026 são quase um terço superiores às do mesmo período do ano passado. Esse crescimento só está a acelerar, e os registos de código aberto são uma das principais razões para tal.
A IA reduziu drasticamente as barreiras à publicação de pacotes de código aberto, e os registos estão a sentir o impacto. O número crescente de pacotes recebidos significa que uma revisão significativa é cada vez mais rara, e a infraestrutura criada para rastrear e contextualizar vulnerabilidades está sob a mesma pressão.
O NVD foi criado para enriquecer cada CVE, adicionando pontuações CVSS, listas de produtos e contexto técnico que tornam os registos CVE brutos realmente utilizáveis. O NIST enriqueceu quase 42 000 CVEs em 2025, o que representa um aumento de 45% em relação a qualquer ano anterior. Mas esse aumento de produtividade não foi suficiente para acompanhar o crescimento das submissões. Conforme abordámos acima, o NIST deixou agora de dar prioridade ao enriquecimento da maioria dos CVEs. As ferramentas em que a sua equipa confia para identificar e pontuar vulnerabilidades estão, para uma parte crescente do universo CVE, a operar com dados incompletos sem o informar.
Os limites das CVEs: o que não é comunicado
O problema do NVD é apenas parte da história. A questão mais profunda é que os CVEs abrangem apenas o que é divulgado, e muito não é.
Numa única semana de monitorização Aikido , 12 das 16 vulnerabilidades sinalizadas não tinham qualquer CVE atribuído. E não se tratava de casos marginais obscuros. A Axios, com 56 milhões de downloads semanais do npm, corrigiu silenciosamente uma vulnerabilidade de poluição de protótipos que ainda não tem CVE. O Apache ECharts corrigiu um problema de cross-site scripting e nunca o divulgou. Das vulnerabilidades que acabaram por receber um CVE, o tempo médio entre a correção e a divulgação foi de 27 dias, com algumas a demorar até nove meses.
Em vez de depender de bases de dados centralizadas, a Intel utiliza modelos de linguagem de grande escala (LLMs) treinados especificamente para analisar registos de alterações, notas de lançamento e mensagens de commit em milhões de pacotes de código aberto, identificando correções relevantes para a segurança antes mesmo de estas receberem um ID CVE e cruzando as informações com cinco bases de dados de vulnerabilidades principais para obter uma cobertura mais abrangente. Se não houver qualquer divulgação, os engenheiros Aikido validam e publicam um aviso com um ID Aikido . No seu primeiro ano, 67% das vulnerabilidades sinalizadas pela Intel nunca tinham sido divulgadas em qualquer base de dados pública. A Intel alimenta diretamente a Aikido , pelo que, quando é encontrada uma nova vulnerabilidade, os utilizadores são alertados automaticamente, mesmo antes de lhe ter sido atribuído um CVE.
O que posso fazer para manter uma postura de segurança robusta?
Nem todas as vulnerabilidades CVE são um problema para si. É necessária uma abordagem em camadas. As pontuações CVSS são um ponto de partida útil, mas não têm em conta o seu contexto específico. Um indicador mais prático é o catálogo KEV da CISA: se uma vulnerabilidade CVE estiver listada nesse catálogo, significa que está a ser ativamente explorada em ambiente real. No entanto, o KEV abrange menos de 1% de todas as vulnerabilidades CVE e concentra-se principalmente em vulnerabilidades do perímetro da rede, pelo que está longe de ser exaustivo.
O Sistema de Pontuação de Previsão de Exploração (EPSS) é outra funcionalidade útil. Este sistema prevê a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias com base em Threat Intelligence do mundo real, ajudando-o a retirar a prioridade da longa lista de CVEs que provavelmente nunca serão exploradas. Aikido nativamente a priorização baseada no EPSS, rebaixando automaticamente as questões de baixo risco para que a sua equipa se possa concentrar no que realmente importa.
Antes de escalar qualquer vulnerabilidade, tenha em conta o seguinte:
- Acessibilidade: A função vulnerável pode não estar acessível na sua aplicação, uma das principais razões pelas quais reachability analysis, e não as pontuações CVSS brutas, deve orientar a sua priorização.
- Impacto nos negócios: O componente afetado não deve afetar sistemas críticos, dados de clientes ou operações essenciais.
- Contexto específico: os sistemas personalizados ou legados podem apresentar perfis de risco diferentes daqueles previstos na descrição padrão do CVE.
- Controlos existentes: É possível que já disponha de medidas de proteção que neutralizam o risco.
- Limitações de recursos: Não é realista resolver tudo. Dê prioridade ao que é realmente viável e tem impacto.
Obtenha um scanner de vulnerabilidades
O melhor ponto de partida é Aikido , uma plataforma criada especificamente para eliminar o ruído que torna a utilização da maioria dos scanners CVE tão cansativa. Os scanners tradicionais apresentam centenas de alertas brutos, independentemente de uma vulnerabilidade ser realmente explorável no seu ambiente. reachability analysis Aikido reachability analysis os caminhos de execução através do seu código para determinar quais as vulnerabilidades que podem ser genuinamente alcançadas e acionadas, filtrando problemas inacessíveis, falsos positivos e resultados irrelevantes, alcançando frequentemente redução de ruído de até 95%.
Fique à frente da CurVE
Os CVEs descrevem vulnerabilidades que já foram identificadas e catalogadas. Quando um CVE é publicado, os atacantes podem já ter tido dias ou semanas para agir. E, como vimos acima, muitas vulnerabilidades nunca recebem um CVE.
Manter-se à frente significa mais do que aplicar correções reativas. Mantenha as dependências atualizadas e verifique o seu código em relação aos Top 10 OWASP benchmarks de conformidade Top 10 OWASP e CIS, as ferramentas padrão para identificar as vulnerabilidades mais comuns e as configurações de segurança incorretas básicas. Pode verificar as suas pontuações OWASP e CIS diretamente no Aikido. Para ameaças que ainda não foram catalogadas, Aikido monitoriza mais de 4,3 milhões de pacotes de código aberto para detetar vulnerabilidades antes que estas tenham um ID CVE.
Veja quais as vulnerabilidades CVE que afetam efetivamente o seu código-fonte.
{{cta}}
