O que é um CVE? Estrutura, gravidade e como corrigir vulnerabilidades

Vá direto para um resumo gerado por IA desta postagem do blog

Já viu códigos “CVE-” aparecerem rapidamente durante a instalação de um software e se perguntou o que eles significavam? Você não é o único; todos nós já passamos por isso. Esses códigos são importantes sinais de alerta em matéria de segurança cibernética. Vou orientá-lo sobre a composição de um identificador CVE, explicar sua estrutura e explorar conceitos como “dependências transitivas” e as melhores práticas para corrigir vulnerabilidades.

O que é um CVE?

As vulnerabilidades costumavam ter nomes específicos para cada falha, como “traversal de caminho no IIS”, mas, à medida que as vulnerabilidades se acumularam ao longo de décadas, tornou-se necessário adotar um identificador padronizado.

Um identificador de Vulnerabilidades e Exposições Comuns (CVE) fornece um nome padronizado para falhas de segurança cibernética identificadas e de conhecimento público. Essa terminologia comum permite que profissionais de segurança e fornecedores se comuniquem de forma rápida e precisa sobre pontos fracos específicos. Identificar CVEs em softwares é essencial — especialmente em ambientes com muitos componentes externos —, pois permite que as equipes de segurança priorizem a aplicação de patches, avaliem riscos e corrijam rapidamente os defeitos antes que sejam explorados, protegendo assim os dados e a disponibilidade do sistema.

Você pode pensar em um CVE como um número de rastreamento, assim como quando você faz um pedido de um pacote na sua loja favorita. É uma forma de acompanhar o(s) bug(s) e manter-se a par de quais versões de um pacote foram afetadas pela vulnerabilidade.

Para ter uma visão geral completa das melhores práticas, você pode se informar mais sobre a aplicação de patches para vulnerabilidades CVE em nosso guia detalhado.

A estrutura de um CVE

Um CVE tem o seguinte formato: ‘CVE-2025-1111’ – o prefixo CVE, seguido do ano em que a falha foi descoberta e, em seguida, um identificador exclusivo.

Esse número é atribuído pela MITRE Corporation e por uma rede global de mais de 490 CNAs. Essas CNAs (Autoridades de Numeração de CVE) incluem fornecedores de TI, como Microsoft, Red Hat e Oracle, além de diversas organizações e pesquisadores de segurança.

O Banco de Dados Nacional de Vulnerabilidades (NVD) tem a função de enriquecer cada CVE assim que ele é publicado na lista de CVEs. Na prática, isso significa que há uma transferência entre o MITRE e o NVD, que então enriquece o CVE com metadados adicionais. Há um processo pelo qual ele passa assim que essa transferência é concluída. De acordo com NIST, o processo inclui:

Analisar o material fornecido junto com o CVE.
Um CWE (CEnumeração de Pontos Fracos Comuns) é atribuído à vulnerabilidade para classificá-la.
São atribuídas métricas de explorabilidade (segundo as métricas do CVSS v3.1 ou v4.0) e de impacto.
Uma declaração do CPE (Common Platform Enumerator) está associada à vulnerabilidade.
Por fim, um analista sênior realiza uma verificação de controle de qualidade antes que os dados enriquecidos sejam publicados.

Assim que o CVE for publicado, poderá haver mais trabalhos de manutenção daqui para frente. Podem ocorrer modificações, adição de material de referência, atualização de descrições, etc.

Compreendendo a vulnerabilidade

Ao executar o comando `npm audit` ou simplesmente instalar um pacote no seu projeto, você pode ver uma saída como esta: 7 vulnerabilidades de alta gravidade. Você pode estar se perguntando: “O que são essas vulnerabilidades e como elas se apresentam?” A saída inicial não lista os CVEs; em vez disso, ela lista os pacotes afetados e suas versões. Aqui está um exemplo da saída do `npm audit` ao instalar o Angular v18 (a imagem fica mais confusa em versões mais antigas, como o Angular 16, onde a acumulação de dependências obsoletas já dura mais de um ano):


resumo  4.0.0 - 4.58.0

Gravidade: alta

Rollup 4 apresenta vulnerabilidade de gravação arbitrária de arquivos via traversal de caminho - https://github.com/advisories/GHSA-mw96-cpmx-2vgc

Correção disponível via `npm audit fix --force`

Instalará @angular-devkit/build-angular@19.2.22, o que representa uma alteração compatibilidade

node_modules/rollup

  @angular/build  18.1.0-next.0 - 19.2.21 || 20.0.0-próximo.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17

  Depende das versões vulneráveis do rollup

  node_modules/@angular/build

    @angular-devkit/build-angular  *

    Depende de versões vulneráveis do @angular/build

    Depende de versões vulneráveis do copy-webpack-plugin

    node_modules/@angular-devkit/build-angular

Isso significa que o pacote de atualizações foi instalado como uma dependência transitiva. As versões afetadas são 4.0.0 – 4.58.0. Essas versões apresentam uma vulnerabilidade de segurança de alta gravidade. A vulnerabilidade é conhecida como falha de “Gravação Arbitrária de Arquivo por meio de Traversal de Caminho”. Isso significa que um agente mal-intencionado pode criar uma entrada que induza o rollup a gravar um arquivo em locais nos quais você não pretendia gravar. Esse é um exemplo clássico de vulnerabilidade na cadeia de suprimentos de software. Você instalou um pacote, mas o rollup veio junto, e você não o instalou intencionalmente.

@angular-devkit/build-angular

  └── @angular/build (versões vulneráveis)

        └── rollup (4.0.0 - 4.58.0) ← o pacote vulnerável

Corrigindo falhas

Se continuarmos a trabalhar com base no exemplo do rollup , há algumas maneiras diferentes de corrigir essa vulnerabilidade, caso você não esteja escrevendo ativamente correções CVE como desenvolvedor de aplicativos de segurança. Você pode executar npm audit fix –force, e isso poderia resolver o problema, mas essa abordagem traz suas próprias desvantagens...

Se você executar esse comando, ele também atualizará @angular-devkit/build-angular para a versão 19.2.22. Essa versão está marcada como uma alteração compatibilidade e pode afetar as configurações de compilação e as APIs. Isso pode exigir alterações no código mais adiante, e quem tem tempo para isso?

Algumas coisas que você pode fazer para descobrir como resolver o problema:

Verifique qual é a sua versão do Angular para avaliar qual seria a magnitude da mudança para a nova versão.
Consulte o registro de alterações do @angular-devkit/build-angular para a versão atualizada.
Crie um novo branch e execute a correção nesse branch, nunca no branch principal.
Reconheça a mudança e adie-a caso ela seja muito arriscada.

Substituições

Usar uma substituição é uma solução temporária que pode ajudar você a seguir em frente, mas também apresenta riscos. Isso pode forçar o uso de uma versão específica e corrigida do pacote de atualizações sem precisar recorrer à atualização incompatível do @angular-devkit/build-angular.

Você pode adicionar a versão corrigida ao seu package.jsoda seguinte maneira. A versão no exemplo JSON é a versão corrigida mais recente, de fevereiro de 2026.

{

  "overrides": {

    "rollup": "^4.59.0"

  }

}

Certifique-se de executar npm install para instalar a versão corrigida e verifique novamente se ela foi instalada executando npm audit. Você deverá verificar que a vulnerabilidade foi eliminada.

A razão pela qual essa solução funciona é que o campos de substituição está dizendo ao npm: “seja como for, sem exceções, instale este pacote”. Ele ignorará completamente a árvore de dependências transitivas usando o overrides.

As substituições são uma boa abordagem quando:

Você realmente precisa enviar o produto, mas está impedido pela atualização que está em andamento
Como a vulnerabilidade está em uma ferramenta de compilação e não em uma ferramenta de produção, o risco é menor
A versão foi testada e confirmou-se que tudo está funcionando corretamente

Existem maneiras melhores de lidar com isso, já que o substituições é apenas temporário. Você pode aceitar a alteração que causa quebra de compatibilidade, desde que a teste em um branch e os testes sejam aprovados. Se não houver problemas e a alteração tiver sido revisada, siga em frente. Se houver um patch disponível que não cause quebra de compatibilidade, use-o. Verifique o changelog em busca de patches principais/secundários que não prejudiquem a compilação. Uma última coisa a fazer é avaliar o risco real.

Conforme mencionado acima, o rollup é uma ferramenta de compilação, não uma ferramenta de produção, portanto o risco é menor. Normalmente, ela não é executada em ambientes de produção. O uso de substituições pode acabar criando uma falsa sensação de segurança. Você deixará de receber avisos do npm audit, mas também estará introduzindo alterações não testadas em seu projeto/compilação.

A conclusão é simples: se você puder aceitar a mudança que causa incompatibilidade, faça isso. Se não puder, use substituições.

Resumo