Cibersegurança
O NVD não está quebrado — está arquiteturalmente obsoleto
Em 26 de maio de 2026, o Inspetor-Geral do Departamento de Comércio dos Estados Unidos publicou um relatório que confirma o que a comunidade de segurança vinha denunciando há dois anos: o National Vulnerability Database deixou de ser a fonte autoritativa de dados de vulnerabilidade que sustentou vinte anos de práticas de vulnerability management. O número que importa do relatório não é o backlog de 27 mil vulnerabilidades. É os 12%.
Doze por cento foi a taxa de concordância em severidade CVSS entre avaliadores independentes do próprio OIG, testando o mesmo conjunto de vulnerabilidades. Não estamos falando de discrepância marginal. Estamos falando de uma medida que o ecossistema inteiro de cibersegurança tratou como objetiva por duas décadas e que, sob teste interno do governo federal americano, comporta-se como avaliação subjetiva.
Isso muda a conversa. O problema do NVD não é operacional. É arquitetural.
O Que o Relatório Encontrou
A cronologia documentada pelo OIG é direta. Em fevereiro de 2024, o contrato de enrichment do NVD lapsou. Enrichment é o processo manual em que analistas do NIST adicionam metadados a cada CVE recebido: severidade CVSS, categorização CWE, lista de produtos afetados via CPE applicability statement, referências. Sem enrichment, um CVE é uma string identificadora sem contexto operacional. Com enrichment, vira insumo para automação de vulnerability management.
O contrato lapsou e o backlog começou a crescer. NIST anunciou em maio de 2024 que zeraria o atraso até setembro. Não havia plano interno para sustentar a promessa. Em outubro, o NIST passou da própria meta. No fim de 2025, o backlog tinha passado de 27 mil vulnerabilidades. Para 2026, o OIG projeta mais de 60 mil CVEs reportados no ano, perto de dez vezes o volume de uma década atrás.
Quatro achados condensados:
1. NIST não tinha plano estratégico para o NVD quando o OIG perguntou. A capacidade interna estimada pelo OIG, com o contratado treinado e dedicado, era de 5.300 vulnerabilidades por mês, abaixo das 6.200 necessárias para alcançar a meta de setembro de 2024. Equipe não totalmente treinada até novembro daquele ano. Análise de 226 vulnerabilidades adicionadas ao KEV Catalog da CISA entre fev/2024 e dez/2025: 34% não tiveram enrichment no prazo razoável de um dia útil. O KEV Catalog lista vulnerabilidades exploradas ativamente. Agências federais civis americanas têm duas semanas para remediá-las.
2. 80% do tempo dos analistas é gasto em duas atividades: cálculo de CVSS e construção de CPE applicability statements. A taxa de concordância de 12% em CVSS scoring entre avaliadores OIG independentes desmonta a premissa de que o trabalho do NIST agrega valor único nessa atividade. CISA já fornece CVSS. Quase 80% dos participantes do programa CVE também fornecem score em submissão. O OIG estima USD 800 mil de economia ao longo de dois anos se o NIST parar de duplicar essa atividade.
3. NIST e CISA operam dois programas paralelos de enrichment, NVD e Vulnrichment, executados pelo mesmo contratado. CISA lançou Vulnrichment em maio de 2024 e convidou o NIST para emitir comunicado conjunto. O NIST não respondeu nem coordenou. Entre maio de 2024 e dezembro de 2025, o OIG identificou 21 mil casos de duplicação direta, somando USD 200 mil de gasto duplicado documentado.
4. Comunicação institucional falhou. Carta aberta de mais de 50 profissionais de cibersegurança ao Congresso e à Secretaria de Comércio, em abril de 2024, ficou sem resposta. Em pesquisa do OIG com os signatários, 90% disseram-se insatisfeitos com a frequência de atualizações, e 75% afirmaram depender menos do NVD desde o início do backlog.
Esse último número é o que importa mais para o operador. O mercado já se moveu antes do relatório oficial.
Por Que Isso É Arquitetural, Não Operacional
Os 12% de concordância em CVSS scoring expõem algo que vendor e regulador preferem não nomear: CVSS centralizado depende mais de quem faz o score do que do framework em si. CVSS não é um cálculo, é um vocabulário compartilhado para descrever atributos de uma vulnerabilidade: Attack Vector, Attack Complexity, Confidentiality Impact, e assim por diante. Cada métrica admite julgamento. Um analista lendo o mesmo CVE pode classificar o vetor de ataque como Network ou Adjacent dependendo de premissa sobre arquitetura. Resultado: scores diferentes para a mesma vulnerabilidade, dependendo de quem analisa.
Isso não invalida CVSS. Invalida o modelo de uma única agência federal escalar humanos para gerar o score canônico do mundo. A premissa de que existe um score “certo” cai quando o teste interno do próprio governo mostra 12% de concordância. O score CVSS continua útil como atributo comparativo dentro de um pipeline. Perde a aura de verdade objetiva que justificava centralização federal.
Segundo problema. NIST e CISA pagam o mesmo contratado para fazer trabalho sobreposto. Não é falha individual de agência. É sintoma de governança fragmentada. O ecossistema federal de vulnerabilidade se federalizou na prática nos últimos cinco anos: CISA assumiu o KEV Catalog, criou o Vulnrichment, opera o programa CVE através da MITRE. A governança não acompanhou. Cada agência atua como se fosse provedor único. O mercado vê duas APIs, duas bases, dois feeds, e precisa decidir em qual confiar para qual uso.
Terceiro problema. O modelo “humano enriquece tudo via contrato” tem teto matemático. Capacidade interna estimada do NIST com o time atual: 5.300 vulnerabilidades por mês. Projeção de volume para 2026: 60 mil CVEs por ano, ou seja, 5 mil por mês. Isso é apertado mesmo se o NIST trabalhar 100% em enrichment, e o crescimento de submissões não vai parar. CVE-2017-0144 (EternalBlue) tinha numeração CVE-2017 porque era a 144ª vulnerabilidade reportada naquele ano. Em 2026, o número equivalente está na casa das dezenas de milhares. Mesma estrutura de governança, ordens de magnitude a mais de volume.
Quarto problema. CISA parou de gerar CPE applicability statements em dezembro de 2024, deixando o NIST como única fonte governamental dessa atividade. O motivo informado pela CISA: gerar CPE statements consome tempo demais. Resposta institucional óbvia seria coordenar com o NIST para decidir como ficaria a oferta combinada. Não foi o que aconteceu. CISA simplesmente parou. O NIST não tinha como absorver o volume extra. O mercado descobriu por feed que essa atividade tinha ficado mais lenta.
Junte os quatro pontos e a leitura fica clara. O NVD foi desenhado para uma era de menos volume, dentro de um arranjo institucional onde NIST era a única agência produzindo essa informação. Esse arranjo se desfez no nível de fato, mas não no nível de modelo. O OIG identifica os sintomas operacionais com precisão. Não desafia o modelo.
O Que Mudou Para Quem Opera Vulnerability Management
Setenta e cinco por cento dos signatários da carta aberta de abril de 2024 dizem depender menos do NVD desde o início do backlog. Esse número não saiu da imprensa especializada. Saiu da pesquisa do OIG com os próprios profissionais que assinaram a carta. São pessoas que operam vulnerability management em organizações que vão de fornecedores de software a hyperscalers a governos. Quando 75% deles diminuem dependência de uma fonte, o ecossistema já se moveu.
Pipeline multi-fonte virou default operacional. Em ordem grosseira de utilidade prática para priorização:
- CISA KEV Catalog: lista canônica de vulnerabilidades exploradas ativamente. Pequena, criteriosa, com prazo regulatório federal para agências civis americanas. Tratá-la como sinal de máxima prioridade independente do score CVSS.
- EPSS (Exploit Prediction Scoring System): probabilidade estatística de exploração nos próximos 30 dias, calculada pelo FIRST com base em telemetria de exploração observada. Ordena vulnerabilidades dentro de um mesmo nível de severidade.
- CISA Vulnrichment: enrichment paralelo ao NVD, mantido pela CISA. Cobertura focada em vulnerabilidades relevantes para infraestrutura crítica. Boa cobertura de SSVC (Stakeholder-Specific Vulnerability Categorization), que o NVD não faz.
- GitHub Security Advisories: banco de vulnerabilidades de ecossistemas open source com CVSS, descrição e versões afetadas. Cobertura ampla de dependências npm, PyPI, Maven, Go.
- Vendor advisories diretos: Microsoft Security Response Center, Cisco PSIRT, Red Hat Security Data, Apple Security Updates. Quando disponíveis, são fonte mais rápida e mais precisa que NVD para produtos específicos.
A recomendação prática para o CISO que ainda trata o NVD como ground truth single-source é direta:
- Pare de bloquear triagem aguardando enrichment do NVD. Se o CVE recém-publicado afeta o seu estoque, decida com base em vendor advisory, CISA Vulnrichment ou EPSS.
- Adote CVSS como atributo comparativo, não como objetivo numérico. Use bandas (Critical, High, Medium) para roteamento de SLAs internos. Não persiga decimais.
- Incorpore KEV no critério de máxima prioridade. Se uma vulnerabilidade está no KEV, a discussão é sobre velocidade de remediação, não sobre se vale a pena.
- Use EPSS para ordenar remediação dentro de bandas de severidade. Vinte CVEs Critical no mesmo trimestre? Ordene por EPSS.
- Aceite CVSS de vendor quando disponível. Audite amostralmente, mas pare de esperar que o NIST recalcule um valor que o vendor já forneceu.
Operacionalmente, isso significa montar pipeline com pelo menos três fontes. Politicamente, significa parar de tratar “o NVD diz X” como argumento de autoridade interno.
O Que o Relatório Não Desafia
As seis recomendações do OIG ao NIST são razoáveis e o NIST concordou com todas. Plano estratégico. Plano de backlog com milestones. Política formalizada para minimizar CVSS scoring duplicado. Mecanismo eficiente para contribuições externas de CPE. Coordenação imediata com CISA. Estratégia de comunicação com stakeholders.
Cumprir as seis melhora a operação. Não muda o modelo. NIST pode entregar um NVD com plano estratégico formalizado, backlog zerado, comunicação ativa, e ainda assim ser apenas uma fonte entre várias num pipeline multi-source. Isso não é necessariamente ruim. É só uma realidade que o relatório descreve sem nomear.
Pergunta de governança que continua aberta: quando o setor público falha em manter infra crítica de dados de cibersegurança, quem assume? Existem provedores comerciais oferecendo enrichment próprio: Tenable, Mandiant, Snyk, todos com bases proprietárias. Mas o single-source-of-truth público importa para regulação. PCI DSS 4.0, NIS2 europeia, requisitos LGPD em construção, tudo isso ainda referencia CVSS oficial em texto. Reformular o NVD como hub de coordenação multi-fonte, em vez de produtor único, é decisão de política federal americana que ainda não foi tomada.
Para o operador brasileiro, vale a observação: a regulação que está chegando ainda referencia o NVD como fonte. PCI 4.0 aterrissa em ambientes locais já em 2026. NIS2 influencia vendors europeus que vendem para o Brasil. Regulação brasileira em segurança cibernética, incluindo resoluções do BACEN sobre instituições financeiras, incorpora framework de vulnerabilidade que pressupõe ground truth público. Não dá para abandonar NVD na prática operacional. Dá para deixar de depender exclusivamente dele.
Considerações Finais
O NVD continua importando, mas o papel mudou. Era a fonte única de verdade. É hoje uma fonte entre várias, com problemas estruturais que o OIG documenta com precisão e cujas soluções de fundo o próprio relatório não chega a propor. Quem ainda opera vulnerability management assumindo o oposto está construindo em terreno que afundou.
Para o CISO, três pontos de ação imediatos:
- Diversifique fontes de enrichment. Pipeline com NVD, Vulnrichment, EPSS e vendor advisories é mais resiliente e mais rápido que NVD-only.
- Reveja SLAs internos que pressupõem dados de NVD em tempo real. Boa parte deles foi escrita quando NVD entregava em horas. Hoje pode levar semanas, e algumas vulnerabilidades críticas nunca recebem enrichment completo.
- Documente para auditoria como você compõe sua decisão de priorização. PCI 4.0 e regulação setorial vão perguntar.
Para o setor público brasileiro e órgãos reguladores, fica o aviso: o ecossistema americano que serve de base referencial para boa parte da regulação local está em transição estrutural. Vincular requisitos ao NVD como provedor único, em texto regulatório, gera fragilidade que vai ter custo. Vale acompanhar como NIST e CISA reorganizam o modelo nos próximos doze a vinte e quatro meses, e ajustar referências de acordo.
O OIG fez o que cabia ao OIG: documentou os fatos e recomendou correções pontuais. O resto é discussão de modelo. E essa discussão é nossa.
Fernando Serto
Líder Visionário em Segurança e Infraestrutura de TI | CISO/CTO | Especialista em Segurança Ofensiva e Defensiva e Redução de Riscos | Evangelista | Keynote Speaker