Mudança prioriza CVEs no catálogo KEV da CISA e falhas em software crítico, deixando registros fora dos critérios marcados como Not Scheduled no NVD.
| Componente | Processo de enriquecimento de CVEs no National Vulnerability Database, incluindo pontuação, metadados e status operacional de registros. |
| Vetor | Crescimento de 263% nas submissões de CVEs entre 2020 e 2025, com volume dos três primeiros meses de 2026 quase um terço acima do observado no ano anterior. |
| Impacto | CVEs fora dos critérios de priorização continuam listados no NVD, mas não recebem enriquecimento automático do NIST e podem ser marcados como Not Scheduled. |
| Prioridade | Ajustar fluxos de gestão de vulnerabilidades para combinar NVD, catálogo KEV da CISA, pontuações fornecidas por CNAs e inteligência de explorabilidade. |
| Critérios | Priorização aplicada desde 15 de abril de 2026 para CVEs no catálogo KEV da CISA e CVEs associados a software crítico definido pela Executive Order 14028. |
| Backlog | CVEs não enriquecidos com data de publicação no NVD anterior a 1º de março de 2026 serão movidos para Not Scheduled, exceto quando já estiverem no KEV. |
| Reanálise | CVEs modificados só serão reanalisados quando a alteração impactar materialmente os dados de enriquecimento; solicitações específicas podem ser enviadas para nvd at nist[.]gov. |
O NIST alterou a forma como o National Vulnerability Database trata o enriquecimento de CVEs. A partir de 15 de abril de 2026, o processo deixa de tentar enriquecer automaticamente todos os registros e passa a priorizar categorias com maior potencial de risco sistêmico. Os registros que não atenderem aos critérios definidos continuam existindo no NVD, mas podem receber o status Not Scheduled, indicando que não há programação automática para enriquecimento pelo NIST. Na prática, isso separa a existência formal de um identificador CVE da disponibilidade de metadados adicionais produzidos pelo NVD, como análise complementar, classificação operacional e dados que muitas organizações usam em fluxos de priorização.
A motivação declarada para a mudança é o aumento de 263% nas submissões de CVEs entre 2020 e 2025. O volume também continuou subindo em 2026: nos três primeiros meses do ano, as submissões ficaram quase um terço acima do patamar observado no ano anterior. Mesmo com maior velocidade operacional, o NIST informou ter enriquecido quase 42.000 CVEs em 2025, número 45% superior ao de qualquer ano anterior. Ainda assim, dados citados no contexto indicam que aproximadamente 10.000 vulnerabilidades de 2025 permaneciam sem pontuação CVSS, enquanto cerca de 14.000 registros CVE-2025 haviam sido enriquecidos, algo em torno de 32% da população de CVEs daquele ano.
A alteração afeta diretamente programas que tratavam o NVD como fonte única de enriquecimento. O identificador CVE permanece útil para referência, correlação e comunicação, mas a ausência de enriquecimento automático reduz a previsibilidade de campos usados por scanners, plataformas de gestão de vulnerabilidades, inventários de exposição e auditorias. Equipes de segurança precisarão distinguir com mais cuidado entre um CVE publicado, um CVE enriquecido, um CVE com pontuação fornecida pela CNA e um CVE confirmado em exploração no catálogo KEV da CISA. Essa distinção é importante porque o novo modelo desloca parte da priorização para sinais de explorabilidade, criticidade do software e impacto operacional, em vez de depender apenas da completude do registro no NVD.
O novo fluxo do NVD prioriza dois grupos principais. O primeiro é formado por CVEs que aparecem no catálogo Known Exploited Vulnerabilities da CISA, que reúne vulnerabilidades conhecidas como exploradas. O segundo cobre CVEs em software crítico conforme a Executive Order 14028, incluindo software projetado para executar com privilégios elevados ou gerenciados, com acesso privilegiado a recursos de rede ou computação, que controla acesso a dados ou tecnologia operacional, ou que opera fora dos limites normais de confiança com acesso elevado. Esses critérios favorecem falhas que podem afetar componentes amplamente distribuídos, controles de acesso, recursos privilegiados ou pontos centrais de confiança.
Quando uma submissão não se enquadra nesses grupos, o registro pode ser mantido no NVD sem enriquecimento automático. O status Not Scheduled passa a ter peso operacional: ele não significa que a vulnerabilidade seja irrelevante, nem que sistemas afetados estejam fora de risco, mas indica que o NIST não programou o trabalho de enriquecimento para aquele CVE. Para times que automatizam filas de correção com base em campos do NVD, isso exige tratamento explícito para registros incompletos. Um CVE sem enriquecimento pode não ter dados suficientes para alimentar regras antigas de priorização, ainda que continue associado a um produto real e a uma falha real.
Outra mudança reduz duplicidade na atribuição de severidade. Quando a CVE Numbering Authority já tiver fornecido uma pontuação de severidade, o NIST deixará de fornecer rotineiramente uma pontuação separada para o mesmo CVE. Isso aumenta a importância da origem da pontuação usada internamente pelas organizações. Em ambientes com exigências de auditoria, convém registrar se a severidade veio da CNA, do NVD, de uma ferramenta interna ou de inteligência externa. Sem essa rastreabilidade, duas áreas podem classificar o mesmo CVE de maneira diferente e gerar conflito entre relatórios de conformidade, filas de engenharia e decisões de aceitação de risco.
O tratamento de alterações também ficou mais restrito. Um CVE modificado será reanalisado apenas quando a modificação impactar materialmente os dados de enriquecimento. Solicitações específicas podem ser enviadas ao endereço nvd at nist[.]gov, inclusive quando um CVE de alto impacto tiver sido colocado em Not Scheduled. O mesmo canal aparece para pedidos de reanálise. Esse mecanismo cria uma exceção operacional, mas não substitui a necessidade de as organizações manterem critérios próprios para avaliar exposição, pois a aceitação de uma solicitação depende da revisão e do agendamento aplicável pelo NIST.
A superfície afetada não é um produto vulnerável específico, e sim a cadeia de consumo de dados de vulnerabilidades. Plataformas de gestão de vulnerabilidades, scanners, ferramentas de SBOM, inventários de ativos, sistemas de ticket, painéis executivos e controles de conformidade podem depender de campos enriquecidos do NVD. Quando esses campos deixam de estar presentes em parte dos registros, a automação pode subestimar itens sem pontuação, ocultar CVEs em painéis filtrados por severidade ou atrasar a criação de tarefas. O risco está na lacuna entre publicação do CVE e capacidade interna de contextualizar exposição real.
O backlog também muda. CVEs não enriquecidos com data de publicação no NVD anterior a 1º de março de 2026 serão movidos para Not Scheduled, exceto CVEs já incluídos no catálogo KEV. Isso afeta especialmente bases históricas e auditorias que esperavam enriquecimento posterior de registros antigos. Um controle que verifica pendências apenas por ausência de CVSS pode passar a carregar uma fila estática de itens sem perspectiva automática de atualização. A decisão defensiva não deve ser simplesmente ignorar esses registros; o caminho mais robusto é cruzar o CVE com presença de ativo, criticidade do software, exposição de rede, privilégio exigido e sinais de exploração conhecidos.
O impacto também alcança processos de desenvolvimento e AppSec. Dependências com CVEs recentes podem aparecer em ferramentas de composição de software sem metadados completos do NVD, principalmente quando a falha não estiver nas categorias priorizadas. Isso pode afetar pipelines que bloqueiam builds por severidade mínima, relatórios que exigem pontuação CVSS e políticas que usam o NVD como autoridade única. A adaptação técnica é tratar enriquecimento ausente como estado próprio, não como severidade baixa nem como ausência de vulnerabilidade.
- Registros CVE continuam listados no NVD mesmo quando não recebem enriquecimento automático pelo NIST.
- Itens fora dos critérios de priorização podem ser marcados como
Not Scheduled. - CVEs no catálogo KEV da CISA permanecem dentro da categoria priorizada.
- CVEs de software crítico conforme a Executive Order 14028 recebem prioridade no novo modelo.
- Registros anteriores a 1º de março de 2026 que estejam no backlog sem enriquecimento serão movidos para
Not Scheduled, salvo exceção do KEV.
A mudança exige hunting voltado ao processo de gestão, não apenas ao endpoint ou à rede. O primeiro ponto observável é a presença de CVEs sem enriquecimento em ferramentas internas. Equipes devem identificar consultas, integrações e painéis que presumem a existência de pontuação CVSS, vetores completos ou metadados do NVD. Falhas nesse tratamento podem aparecer como campos nulos, registros descartados por filtros, tickets não criados, exceções silenciosas em ETL ou divergência entre scanners. Em vez de converter automaticamente ausência de pontuação em baixa prioridade, o processo deve sinalizar o item como incompleto e encaminhá-lo para correlação adicional.
A telemetria de vulnerabilidades precisa combinar fontes. O catálogo KEV da CISA deve ser tratado como sinal forte de exploração conhecida, mas não cobre todos os cenários de risco local. Pontuações fornecidas por CNAs podem estar disponíveis mesmo quando o NIST não produzir uma pontuação separada. Inventário de ativos, exposição de internet, privilégio do componente, função do sistema e presença em software crítico ajudam a definir prioridade defensiva. O objetivo técnico é impedir que a mudança de status no NVD remova vulnerabilidades reais da fila de análise apenas porque o enriquecimento automático não ocorreu.
Também é necessário revisar métricas históricas. Indicadores como tempo médio para correção por severidade, volume de CVEs críticos e cobertura de enriquecimento podem mudar por causa da política do NVD, não necessariamente por melhora ou piora real do ambiente. Um aumento de CVEs sem pontuação pode refletir a nova estratégia de priorização, e não ausência de risco. Relatórios executivos e controles de auditoria devem separar vulnerabilidades sem enriquecimento, vulnerabilidades com pontuação de CNA, vulnerabilidades no KEV e vulnerabilidades com enriquecimento completo do NVD.
- CVEs com status
Not Scheduledpresentes em ativos inventariados ou dependências usadas em produção. - Registros sem CVSS que foram descartados por regras de filtragem ou não geraram ticket de correção.
- Divergência entre pontuação da CNA, dados internos e campos enriquecidos do NVD.
- CVEs de ativos críticos que não aparecem em painéis por falta de metadados complementares.
- Dependências com identificador CVE válido, mas sem dados suficientes para políticas antigas de bloqueio em CI/CD.
A resposta deve começar pela revisão das integrações que consomem o NVD. Qualquer automação que dependa de campos enriquecidos precisa reconhecer explicitamente o estado Not Scheduled e a ausência de pontuação. Esse estado deve alimentar uma fila de correlação, não um descarte. Para cada CVE sem enriquecimento em ativo relevante, a equipe deve validar se há presença no ambiente, se o componente executa com privilégio elevado, se controla acesso a dados, se fica exposto a rede ou se se enquadra em software crítico. Essa triagem baseada em exposição reduz dependência de um único campo de severidade.
Programas maduros também devem ajustar políticas de priorização. O catálogo KEV da CISA passa a ser uma fonte essencial para exploração conhecida, enquanto pontuações de CNAs devem ser armazenadas com indicação de origem. Quando houver conflito ou ausência de pontuação, a organização deve preservar a decisão e os critérios usados: criticidade do ativo, alcance do componente, privilégio necessário, impacto técnico confirmado e disponibilidade de mitigação. Essa documentação evita que a falta de enriquecimento do NVD seja confundida com aceitação automática de risco.
Para o backlog, a ação defensiva é separar os CVEs movidos para Not Scheduled antes de 1º de março de 2026 e cruzá-los com inventário real. Itens sem presença no ambiente podem ser mantidos como referência de baixa urgência operacional, enquanto itens presentes em software crítico ou ativos expostos devem seguir para análise. Quando um CVE de alto impacto for classificado como não programado e houver justificativa técnica, o pedido de enriquecimento ou reanálise pode ser encaminhado para nvd at nist[.]gov. Esse pedido não deve ser o único controle; a organização ainda precisa decidir correção, mitigação temporária ou aceitação formal com base na própria exposição.
Por fim, as equipes devem atualizar métricas e comunicação interna. Relatórios devem explicar a diferença entre CVE publicado, CVE enriquecido, CVE com pontuação de CNA e CVE em exploração conhecida. Pipelines de engenharia devem tratar dados ausentes como caso analisável, principalmente em dependências e componentes privilegiados. Em auditorias, a evidência mais defensável passa a ser a combinação de inventário, fonte da severidade, status do NVD, presença no KEV e decisão documentada de remediação.
- Mapear integrações que consomem campos enriquecidos do NVD e registrar como elas lidam com
Not Scheduled. - Criar fila separada para CVEs sem enriquecimento, correlacionando com inventário, criticidade e exposição real.
- Usar o catálogo KEV da CISA como sinal de exploração conhecida dentro da priorização de correção.
- Armazenar a origem da severidade quando a pontuação vier da CNA ou de outra fonte usada internamente.
- Revisar CVEs do backlog anteriores a 1º de março de 2026 e pedir reanálise apenas quando houver impacto material sustentado por evidência técnica.
0 Comentários