🚨 NVD Abandona Maioria dos CVEs: Segurança de Contêineres Precisa de Múltiplas Fontes Já!

Em 15 de abril, o NIST anunciou que o National Vulnerability Database (NVD) não enriquecerá mais a maioria dos CVEs. Para a segurança de contêineres, essa mudança não é um ajuste — é o fim de uma era de dependência cega de uma única fonte. Scanners, SLAs e pipelines de priorização precisam se reinventar.

O Fim do Padrão Ouro

O NVD sempre foi a espinha dorsal do enriquecimento de vulnerabilidades: cada CVE ganhava um CPE (para identificar produtos afetados), uma pontuação CVSS e uma classificação CWE. Com o aumento de 263% nas submissões desde 2020, o NIST admitiu que não consegue manter o ritmo.

O novo modelo prioriza apenas CVEs no catálogo KEV da CISA, software usado pelo governo federal e "software crítico" da Ordem Executiva 14028. Todos os demais CVEs publicados antes de 1º de março de 2026 foram movidos para "Não Agendado".

"Se não for crítico para o governo federal ou para exploração ativa conhecida, você está por conta própria." — NIST, na prática

O que exatamente muda?

• CPE → não será mais gerado para a maioria dos CVEs
• CVSS → pontuação oficial desaparece
• CWE → classificação de fraqueza ausente

Impacto imediato: scanners e workflows que tratam o NVD como verdade única passarão a ignorar vulnerabilidades reais.

O Efeito em Cadeia nos Contêineres

Em ambientes de contêineres, a varredura de vulnerabilidades depende de dois mecanismos fornecidos pelo NVD. Quando um deles quebra, a cascata de falsos negativos se espalha por toda a cadeia de dependências.

1. O CPE — a chave que conecta CVE a pacotes

Scanners como Trivy, Grype e Snyk usam CPE para casar vulnerabilidades com componentes em camadas de imagem. Sem CPE, o CVE se torna operacionalmente invisível.

Exemplo prático:
Um CVE crítico no OpenSSL é publicado em junho de 2025. O NVD não o enriquece com CPE. Seu scanner de contêiner simplesmente ignora o alerta. Imagens upstream propagam o gap para dezenas de serviços downstream.

2. CVSS — a régua de priorização quebra

Equipes usam a pontuação CVSS para definir SLAs: "crítico em 7 dias, alto em 30". Sem o campo cvss do NVD, a severidade padrão retorna como "DESCONHECIDA" ou o CVE é excluído dos workflows automatizados.

Resultado: CVEs reais e perigosos ficam invisíveis para dashboards, tickets e pipelines de correção.

O Gap se Espalha: Implicações Técnicas e Operacionais

Observação: Scanners que usam múltiplas fontes (GitHub Advisory Database, Red Hat, Ubuntu CVE Tracker) e identificadores como PURL (em vez de CPE) são menos expostos — porque não tratam o NVD como única verdade.

O Que Fazer Agora — Um Roteiro Prático

Auditoria de achados abertos

CVEs publicados antes de 1º de março de 2026 foram movidos para "Não Agendado". Sua base de vulnerabilidades não mais receberá atualizações do NVD.

• Faça uma fotografia do estado atual de todos os CVEs abertos que dependiam do NVD
• Documente pontuação alternativa (ex.: CVSS do GitHub Advisory Database, Red Hat ou dados do fornecedor)
• Atualize SLAs e registros de risco com a nova fonte

Perguntas certas para seu fornecedor de scanner

• "Quantas fontes de advisory seu scanner consulta além do NVD?"
• "Você usa PURL como identificador primário ou ainda depende de CPE?"
• "Se um CVE não tem CVSS no NVD, qual fonte é usada como fallback?"
• "Você fornece documentação para auditorias de compliance sobre a origem das pontuações?"

Adote inteligência multivendor

Soluções como Docker Hardened Images já utilizam 22 fontes de advisory e PURLs, além de VEX para filtrar vulnerabilidades não exploráveis. Esse modelo é o que se tornará prática padrão.

Resumo prático:

• Crie um pipeline de coleta que agregue CVEs de várias fontes
• Use OpenVEX para gerar VEX statements próprios
• Integre o KEV da CISA como fonte de priorização explícita

Impacto no Mercado e Compliance

Para fornecedores de segurança

• Quem depende exclusivamente do NVD perde credibilidade
• Diferenciação passa pela profundidade da inteligência de ameaças e pela capacidade de validar dados em múltiplas fontes
• Scanners de código aberto baseados em Trivy-Grype que já usam múltiplos bancos ganham vantagem

Para compliance (FedRAMP, PCI-DSS, SOC 2)

Frameworks frequentemente referenciam o NVD como fonte autoritativa. Com a mudança, haverá maior variância na aplicação de pontuações e SLAs.

• Riscos: organizações sem linguagem de fallback em seus SSPs podem falhar em auditorias
• Ação: documente no SSP quais fontes são usadas para cada CVE; estabeleça uma política de equivalência (se o NVD não fornece CVSS, use a nota do GitHub Advisory Database); registre a mudança de fonte nos riscos tratados

A Descentralização da Inteligência de Vulnerabilidades

O NVD não está morrendo, mas está se retirando para um papel de curadoria mínima. Isso reconhece que uma única entidade não consegue mais gerenciar o tsunami de CVEs impulsionado por IA.

O futuro da segurança de contêineres será descentralizado.

• Equipes precisarão de pipeline de inteligência própria: agregar, confiar, pontuar
• Fornecedores que sobreviverem serão aqueles que abstraem a complexidade de múltiplas fontes em uma única interface confiável
• A confiança será conquistada por transparência: saber de onde veio cada dado, sua qualidade e como se relaciona com o runtime real do contêiner

"A mudança do NVD é um chamado à maturidade. Não se trata de abandonar o NVD, mas de não tratá-lo como verdade absoluta."

Sua organização de segurança de contêineres deve se preparar para um mundo onde a inteligência de vulnerabilidades é distribuída e a validação é contínua.

Comece hoje: audite suas fontes, diversifique seus identificadores, e proteja cada camada de suas imagens — mesmo quando a fonte que todos usavam começa a se calar.