O NIST Parou de Enriquecer a Maioria das CVEs. E Agora?

O que aconteceu em 15 de abril de 2026

Em 15 de abril de 2026, durante a conferência VulnCon26 em Scottsdale, Arizona, Harold Booth, cientista da computação do NIST, apresentou um anúncio que, para quem acompanha o ecossistema de vulnerabilidades, não foi exatamente uma surpresa, mas foi um marco. O National Vulnerability Database (NVD) mudou oficialmente para um modelo de enriquecimento baseado em risco. Na prática, isso significa que a maioria das CVEs publicadas a partir de agora não receberá a análise detalhada que o mercado de segurança tratou como padrão durante duas décadas.

Até então, o modelo da NVD era universal: toda CVE publicada recebia scores CVSS atribuídos pelo NIST, classificação CWE, mapeamento de produtos afetados via CPE e referências técnicas adicionais. Esse enriquecimento alimentava scanners de vulnerabilidade, plataformas de gestão de risco, ferramentas de compliance e workflows de priorização em organizações de todos os portes ao redor do mundo.

A partir de agora, apenas três categorias de CVEs serão priorizadas para enriquecimento:

• CVEs presentes no catálogo CISA KEV (Known Exploited Vulnerabilities)
• CVEs em software usado pelo governo federal americano
• CVEs em software crítico conforme definido pela Executive Order 14028

Todo o restante será registrado na NVD, mas categorizado como "Not Scheduled" (substituindo o antigo status "Deferred"), sem score CVSS do NIST, sem mapeamento CPE, sem classificação CWE. Além disso, aproximadamente 29.000 CVEs acumuladas no backlog desde 2024 foram movidas para essa mesma categoria, efetivamente reconhecendo que não serão processadas.

---

Por que o NIST chegou a esse ponto

É importante entender que a NVD não falhou por negligência. O NIST enriqueceu quase 42.000 CVEs em 2025, um aumento de 45% em relação a qualquer ano anterior. A equipe trabalhou mais rápido do que nunca. Simplesmente não foi suficiente.

Os números explicam o porquê. As submissões de CVEs cresceram 263% entre 2020 e 2025. Nos três primeiros meses de 2026, o volume já é quase um terço maior que o mesmo período do ano anterior. E o FIRST, organização que mantém o EPSS, projeta entre 59.000 e 118.000 novas CVEs para 2026. Jerry Gamblin, engenheiro da Cisco, é ainda mais específico: projeta 70.135 CVEs até o final de 2026, um crescimento de 45,6% em relação às 48.171 reportadas em 2025.

Essa aceleração tem três motores que operam simultaneamente:

A explosão de código gerado por IA. O GitHub processou 1 bilhão de commits em 2025 e está no ritmo de 14 bilhões em 2026, um aumento de 14x ano a ano, impulsionado quase inteiramente por agentes de codificação com IA. Cada commit puxa dependências open source, introduz novos caminhos de código e expande a superfície de ataque que o ecossistema de vulnerabilidades precisa catalogar.

A descoberta automatizada de vulnerabilidades. Modelos de IA como o Claude Mythos da Anthropic estão encontrando milhares de vulnerabilidades de alta severidade, incluindo bugs que escaparam de pesquisadores humanos por décadas. O AISLE descobriu todas as 12 CVEs de uma release coordenada do OpenSSL de janeiro de 2026. O custo de encontrar uma vulnerabilidade está se aproximando de zero.

A inundação de relatórios de baixa qualidade. O GitHub reportou que o volume de relatórios de vulnerabilidade recebidos nos últimos 90 dias foi 224% maior que nos 90 dias anteriores, com a qualidade descrita como uma "preocupação enorme". Relatórios gerados por IA estão inundando o sistema com submissões duplicadas, incompletas ou sem o contexto necessário para enriquecimento.

O resultado é um descompasso econômico fundamental: o custo de encontrar vulnerabilidades está caindo exponencialmente, mas o custo de enriquecê-las na NVD permanece limitado por uma equipe de 21 analistas e ciclos de financiamento governamental. Esse descompasso não vai se resolver. Vai se agravar.

---

O impacto real para quem gerencia vulnerabilidades

Leia também: O que é CVSS e como funciona

Para entender o impacto, é preciso lembrar como a maioria dos programas de gestão de vulnerabilidades funciona hoje. O fluxo típico é:

1. Um scanner detecta software instalado nos ativos
2. O software é correlacionado com CVEs usando dados CPE da NVD
3. Cada CVE recebe um score CVSS da NVD para classificação de severidade
4. O time prioriza pela severidade e aplica patches

Quando o enriquecimento da NVD desaparece para a maioria das CVEs, cada etapa desse fluxo é afetada:

Correlação quebrada. Sem CPE (Common Platform Enumeration), a ferramenta não consegue associar uma CVE ao software instalado no ativo. A vulnerabilidade existe, mas o scanner não sabe que ela afeta o ambiente. Não há alerta. O ativo permanece exposto sem visibilidade.

Severidade ausente. Sem CVSS do NIST, a CVE não tem score de referência para priorização. Ela pode aparecer na fila como "sem classificação" ou simplesmente não aparecer. O time não sabe se é urgente ou pode esperar.

Compliance comprometida. Frameworks como ISO 27001, PCI DSS e NIST CSF referenciam a NVD explícita ou implicitamente como fonte de identificação e pontuação de vulnerabilidades. Se a NVD não enriquece a maioria das CVEs, como demonstrar que a organização está gerenciando vulnerabilidades conhecidas conforme exigido?

Falsa sensação de segurança. Este é o risco mais perigoso. Uma ferramenta que depende exclusivamente da NVD e não encontra vulnerabilidades para determinado software pode dar a impressão de que o ambiente está seguro. Na realidade, as vulnerabilidades existem: elas simplesmente não foram enriquecidas pela NVD e, portanto, não aparecem no radar.

---

O modelo centralizado não escala mais

O que o NIST reconheceu explicitamente é algo que parte da comunidade de segurança argumentava há anos: o modelo de enriquecimento centralizado, onde uma única entidade processa todas as vulnerabilidades do mundo, não é sustentável na velocidade atual do ecossistema de software.

Não se trata de uma falha de gestão. Trata-se de um problema estrutural. A produção de vulnerabilidades cresce exponencialmente enquanto a capacidade de processá-las é linear.

O mercado global já está respondendo com iniciativas distribuídas:

CISA Vulnrichment: programa lançado pela CISA para preencher a lacuna de enriquecimento, adicionando CVSS, CPE, CWE e dados SSVC diretamente nos registros CVE via container ADP (Authorized Data Publisher). Disponível publicamente no GitHub.

EUVD (European Vulnerability Database): base europeia de vulnerabilidades desenvolvida pela ENISA sob a diretiva NIS2, operacional desde maio de 2025. Oferece três visões: vulnerabilidades críticas, falhas ativamente exploradas e vulnerabilidades coordenadas por CSIRTs europeus. A partir de setembro de 2026, a notificação de vulnerabilidades ativamente exploradas será obrigatória para fabricantes sob o Cyber Resilience Act.

GCVE (Global CVE Allocation System): sistema descentralizado mantido pelo CIRCL Luxembourg, lançado em janeiro de 2026. Agrega informações de mais de 25 fontes públicas e permite que organizações autorizadas aloquem identificadores de vulnerabilidade de forma independente, reduzindo pontos únicos de falha.

CVE Foundation: organização nonprofit em formação nos EUA, buscando estabelecer financiamento diversificado (setor privado + multi-governo) para o programa CVE, após a crise de financiamento de abril de 2025 quando o contrato CISA/MITRE quase expirou.

Plataformas comerciais e comunitárias: diversas empresas e projetos open source estão construindo camadas próprias de enriquecimento de CVEs, usando dados dos CNAs (CVE Numbering Authorities), advisories de vendors e inteligência de exploits para compensar as lacunas da NVD.

A tendência é clara: o futuro da inteligência de vulnerabilidades é multi-fonte e distribuído. Nenhuma entidade única vai processar todas as vulnerabilidades do mundo. Organizações e ferramentas que dependem de uma única fonte estão construindo sobre uma fundação que já declarou não poder sustentar o peso.

---

O que muda na priorização: CVSS sem NVD não é o fim

Leia também: EPSS: o que é e por que CVSS não basta para priorizar vulnerabilidades

Aqui é importante separar o impacto no enriquecimento do impacto na priorização. São problemas diferentes.

O enriquecimento (CPE, CVSS, CWE pela NVD) é uma camada de dados. A priorização é uma decisão de risco. E a priorização moderna já não deveria depender exclusivamente do CVSS da NVD.

Como discutimos em profundidade no artigo sobre EPSS, a combinação de CVSS (severidade técnica), EPSS (probabilidade de exploração) e CISA KEV (exploração confirmada), aplicada sobre o contexto do ativo, é significativamente mais eficaz do que priorizar por CVSS isoladamente. Dos três, apenas o CVSS tinha dependência forte da NVD. O EPSS é mantido independentemente pelo FIRST com atualização diária. O CISA KEV é mantido diretamente pela CISA.

Isso significa que mesmo em um cenário onde a NVD não enriquece uma CVE, os sinais mais importantes de exploração ativa continuam disponíveis. Uma organização que já adotou priorização baseada em risco real, com EPSS, KEV e contexto de ativo, está em posição muito melhor do que uma que depende exclusivamente de CVSS para decidir o que corrigir.

O problema residual é a correlação: saber quais ativos são afetados pela CVE. Sem CPE da NVD, essa associação precisa vir de outras fontes. É aqui que a arquitetura da ferramenta de gestão de vulnerabilidades faz toda a diferença.

---

O que a supply chain de março de 2026 ensinou

Leia também: Risco na cadeia de suprimentos de software

As mudanças da NVD não acontecem no vácuo. Elas coincidem com um momento em que a cadeia de suprimentos de software está sob ataque intenso.

Entre 19 e 31 de março de 2026, cinco grandes projetos open source foram comprometidos em rápida sucessão: o scanner Trivy da Aqua Security, GitHub Actions da Checkmarx, a biblioteca LiteLLM no PyPI, o SDK da Telnyx e o Axios, uma das bibliotecas JavaScript mais populares do mundo com mais de 100 milhões de downloads semanais.

O ataque ao Trivy é particularmente instrutivo. Custou aproximadamente $150 e usou uma ferramenta assistida por IA para obter acesso a credenciais que permitiram publicar versões maliciosas de imagens de container e dezenas de GitHub Actions. Qualquer equipe que executou um scan Trivy durante uma janela de três dias pode ter tido seus segredos expostos.

A lição é dupla. Primeiro, a velocidade de exploração é incompatível com o modelo de "esperar a NVD enriquecer para agir". O tempo médio até a exploração de um CVE caiu de 63 dias em 2018 para menos de um dia em 2024. Esperar que a NVD processe e enriqueça uma CVE antes de tomar ação não é mais viável.

Segundo, a confiança cega em fontes únicas, seja a NVD ou um registry público de pacotes, é um risco em si. A resiliência vem da diversificação de fontes e da verificação independente.

---

Checklist: como avaliar se sua ferramenta está preparada

Leia também: Scan de vulnerabilidades: o que é e como funciona

Independentemente de qual ferramenta de gestão de vulnerabilidades sua organização utiliza, estas são as perguntas que determinam a exposição às mudanças da NVD:

1. A ferramenta depende exclusivamente da NVD para correlação CVE-ativo? Se sim, CVEs que a NVD não enriquecer com CPE não serão associadas aos ativos do ambiente. A cobertura vai degradar progressivamente.

2. A ferramenta obtém CVSS apenas da NVD? Se sim, CVEs "Not Scheduled" aparecerão sem score de severidade, impossibilitando priorização. Verifique se a ferramenta consegue usar CVSS de fontes alternativas (CNAs, vendors, plataformas de inteligência).

3. A ferramenta integra EPSS e CISA KEV? Se sim, a priorização por risco de exploração continua funcionando independentemente da NVD. Se não, a perda do CVSS deixa a organização sem nenhum critério quantitativo de priorização.

4. A ferramenta cobre pacotes open source por ecossistema? Fontes como OSV.dev operam por ecossistema de pacotes (pip, npm, Maven) e não dependem de CPE. Se a ferramenta integra essas fontes, a cobertura de open source não é afetada.

5. A ferramenta tem fontes próprias de correlação? Ferramentas que construíram bases proprietárias de matching, usando dados dos CNAs, advisories de vendors ou outras fontes, têm menor dependência do CPE da NVD.

6. A ferramenta monitora patches por canal direto do vendor? Para ambientes Windows, a consulta direta ao Microsoft Update Catalog e MSRC API opera sem dependência da NVD. O mesmo vale para outros vendors que mantêm advisories próprios.

---

Como a EcoTrust trata esse desafio

O EcoTrust VulScan foi projetado desde sua concepção para operar com múltiplas fontes de inteligência independentes. Não por antecipação às mudanças da NVD, mas porque a dependência de fonte única sempre foi um risco arquitetural que optamos por não aceitar.

Três trilhas de enriquecimento paralelas

O VulScan executa três trilhas de enriquecimento em paralelo para cada ativo analisado. Cada trilha tem suas próprias fontes de dados e produz achados no formato padronizado da plataforma:

Correlação CVE por software e versão. Identifica CVEs que afetam o software instalado no ativo, cruzando vendor, produto e versão exata contra bases de vulnerabilidades. Utiliza estratégias de matching em múltiplos níveis com filtragem avançada para reduzir falsos positivos.

Patches Windows ausentes. Consulta diretamente o Microsoft Update Catalog e a API MSRC para determinar quais patches de segurança estão ausentes. Resolve automaticamente cadeias de supersedência: se um patch mais recente já está instalado, os anteriores não são reportados como ausentes. Essa inteligência elimina uma das principais fontes de ruído em programas de gestão de vulnerabilidades. Veja também o módulo Patch Management.

Inteligência de exploração e ecossistema. Enriquece cada CVE com sinais de exploração ativa (EPSS diário, CISA KEV, indicador de ransomware, contagem de exploits públicos) e consulta fontes especializadas por tipo de componente: pacotes pip/npm/JAR via OSV.dev, status de fim de vida para 95+ produtos, firmware e BIOS para 9+ fabricantes, bibliotecas embarcadas (OpenSSL, libcurl, zlib, Log4j), drivers de firmware, processadores CPU/GPU e DLLs de sistema Windows.

Detecção de lacunas com validação inteligente

O VulScan inclui um detector de lacunas que identifica automaticamente componentes do inventário, coletados pelo módulo Inventory, que não foram correlacionados por nenhuma das trilhas primárias. Quando lacunas são detectadas, um sistema de validação complementar é acionado para garantir que componentes relevantes não fiquem sem análise.

Seis fontes de inteligência independentes

Das seis fontes de inteligência que o VulScan consulta em paralelo, cinco operam sem qualquer dependência da NVD: FIRST EPSS, CISA KEV, inteligência de exploits (incluindo ransomware e exploits públicos), OSV.dev para pacotes open source e endoflife.date para status de fim de vida. Adicionalmente, o módulo de patches Windows opera via consulta direta ao Microsoft Update Catalog e MSRC, sem dependência da NVD em nenhuma etapa.

Seis tipos de achado por ativo

O resultado para cada ativo inclui: CVEs por software instalado, patches Windows ausentes com supersedência resolvida, inteligência de exploração com EPSS e KEV, advisories de pacotes open source com versões corrigidas, status de fim de vida e vulnerabilidades de firmware e hardware. Tudo isso sem executar scans adicionais na rede.

O que estamos evoluindo

Estamos acelerando investimentos para eliminar os pontos de exposição remanescentes. Nos próximos meses, a base de correlação será expandida para consumir dados diretamente dos CVE Numbering Authorities (CNAs), independentemente do enriquecimento da NVD. Estamos também integrando o VulScan como camada de enriquecimento do Scanner Infra da EcoTrust, estendendo a mesma resiliência multi-fonte para os achados de scans de infraestrutura.

---

Perguntas Frequentes

O que aconteceu com a NVD do NIST em abril de 2026?

O NIST mudou o modelo de enriquecimento da NVD para priorizar apenas CVEs no catálogo CISA KEV, em software do governo federal americano e em software crítico definido pela Executive Order 14028. A maioria das CVEs publicadas a partir de agora não receberá score CVSS, mapeamento CPE ou classificação CWE pelo NIST. Aproximadamente 29.000 CVEs do backlog também foram classificadas como "Not Scheduled".

Minha ferramenta de gestão de vulnerabilidades vai parar de funcionar?

Depende da arquitetura. Ferramentas que dependem exclusivamente da NVD para correlação (CPE) e priorização (CVSS) terão cobertura progressivamente degradada. Ferramentas que operam com múltiplas fontes, como EPSS, CISA KEV, advisories de vendors e bases próprias de matching, continuam funcionando normalmente. O VulScan da EcoTrust opera com seis fontes independentes, das quais cinco não dependem da NVD.

O CVSS vai deixar de existir?

Não. O CVSS é um padrão mantido pelo FIRST, não pelo NIST. O que muda é que o NIST não atribuirá mais scores CVSS para a maioria das CVEs. Os CNAs (CVE Numbering Authorities) e os próprios vendors continuam atribuindo scores CVSS em seus advisories. Além disso, fontes como EPSS e CISA KEV oferecem sinais de priorização mais eficazes do que o CVSS isoladamente.

O que é o CISA Vulnrichment?

É um programa da CISA que preenche a lacuna de enriquecimento da NVD, adicionando CVSS, CPE, CWE e dados SSVC diretamente nos registros CVE via container ADP (Authorized Data Publisher). Os dados são públicos e estão disponíveis no GitHub. É uma das iniciativas mais importantes para manter a inteligência de vulnerabilidades acessível.

Como saber se minha organização está exposta a essa mudança?

Responda as seis perguntas do checklist deste artigo. Se sua ferramenta depende exclusivamente da NVD para correlação e priorização, a exposição é alta. A recomendação é migrar para uma abordagem multi-fonte com priorização baseada em risco real (EPSS + KEV + contexto de ativo).

---

Conclusão: o modelo mudou, e sua ferramenta precisa acompanhar

A NVD não vai desaparecer. Ela continuará sendo uma fonte importante de dados de vulnerabilidade, especialmente para CVEs no CISA KEV e em software crítico. Mas a era em que a NVD era a fonte única e autoritativa de enriquecimento de CVEs acabou. O NIST disse isso explicitamente.

Para líderes de segurança, a implicação prática é direta: verifique se sua ferramenta de gestão de vulnerabilidades consegue operar com qualidade quando a NVD não enriquece uma CVE. Se a resposta for não, a cobertura vai degradar progressivamente em um cenário onde o volume de CVEs só cresce.

A priorização por risco real, com EPSS, CISA KEV, indicador de ransomware e contexto de ativo, já era a abordagem recomendada antes das mudanças da NVD. Agora, é a única abordagem que escala.

O VulScan da EcoTrust opera com múltiplas fontes de inteligência independentes e três trilhas de enriquecimento paralelas por ativo. Não porque antecipamos essa mudança específica, mas porque sempre acreditamos que depender de fonte única é um risco que não vale a pena correr.

---

Referências

• NIST, "NIST Updates NVD Operations to Address Record CVE Growth", abril 2026. nist.gov
• FIRST, "2026 Vulnerability Forecast: median ~59,000 CVEs", fevereiro 2026. infosecurity-magazine.com
• GitHub, "A Year of Open Source Vulnerability Trends: CVEs, Advisories, and Malware", 2026. github.blog
• Hughes, C., "The NVD Just Threw In The Towel. Now What?", Resilient Cyber, abril 2026. resilientcyber.io
• Hughes, C., "The Software Supply Chain Cannot Scale on Trust Alone", Resilient Cyber, abril 2026. resilientcyber.io
• Verizon, "Data Breach Investigations Report 2025". verizon.com
• FIRST, "Exploit Prediction Scoring System (EPSS)". first.org/epss
• CISA, "Known Exploited Vulnerabilities Catalog". cisa.gov/known-exploited-vulnerabilities-catalog
• ENISA, "European Vulnerability Database (EUVD)". euvd.enisa.europa.eu
• CIRCL, "Global CVE Allocation System (GCVE)". db.gcve.eu
• Lorenc, D., "Open Source Died in March", Chainguard, março 2026. chainguard.dev