Durante duas décadas, a NVD (Base de Dados Nacional de Vulnerabilidades) serviu de base de facto para a gestão de vulnerabilidades. Os scanners, os SIEM, as ferramentas de aplicação de patches e os quadros de conformidade partiam todos do pressuposto de que, quando um CVE aparecia na NVD, os analistas do NIST iriam adicionar prontamente as pontuações de gravidade, as correspondências de versões de produtos e os metadados contextuais que tornam um ID de CVE bruto realmente útil.
Em 15 de abril de 2026, essa suposição deixou oficialmente de ser válida.
O NIST anunciou que o NVD está a passar para um modelo de enriquecimento baseado no risco. A maioria das novas CVEs que entram na base de dados deixará de receber, por predefinição, a pontuação CVSS atribuída pelo NIST, o mapeamento de produtos CPE e a análise independente. Para as organizações cujos fluxos de trabalho de vulnerabilidades dependem de dados enriquecidos pelo NVD, isto cria um problema de cobertura real e crescente. Para os criadores e fornecedores de produtos de segurança que incorporam esses dados nas suas ferramentas, isto levanta uma questão ainda mais premente: o que é que o seu feed lhe está a dizer agora, exatamente?
O NVD já não consegue acompanhar o ritmo das vulnerabilidades comunicadas
De acordo com o próprio comunicado do NIST, as submissões de CVE aumentaram 263 % entre 2020 e 2025, e as submissões no primeiro trimestre de 2026 já eram quase um terço superiores às do mesmo período do ano anterior.
O NIST atualizou cerca de 42 000 CVEs em 2025, o que representa um aumento de 45 % em relação a qualquer ano anterior. No entanto, este aumento de produtividade não foi suficiente para acompanhar o crescimento do número de submissões, o que levou à criação de um sistema formal de triagem.
A partir de 15 de abril de 2026, o NIST apenas irá complementar as vulnerabilidades que constem no catálogo KVE (Known Exploited Vulnerabilities) da CISA, no software utilizado pelo governo federal ou no software designado como crítico ao abrigo do Decreto Presidencial 14028. Todas as restantes vulnerabilidades serão listadas no NVD, mas sem o complemento adicionado pelo NIST, e não serão processadas de imediato.
Consequentemente, cerca de 300 000 CVEs em atraso, publicados antes de 1 de março de 2026, foram transferidos em bloco para a categoria «Sem data prevista».
No que diz respeito às CVEs que, doravante, não se enquadrem nos critérios de prioridade do NIST, as pontuações de gravidade passarão a basear-se nos dados auto-declarados pela Autoridade de Numeração de CVEs (CNA) — frequentemente o fornecedor do software afetado —, em vez de resultarem de uma análise independente do NIST. O NIST deixará também de recalcular as pontuações de gravidade quando uma CNA já tiver fornecido uma.
Todos os principais scanners de vulnerabilidades, todas as regras de correlação SIEM, todas as pontuações de risco de terceiros e todos os quadros de conformidade regulamentar, desde o PCI DSS até ao FedRAMP, dependem do pipeline de enriquecimento do NVD.
Com a atualização, esse fluxo de trabalho foi agora formalmente reduzido, o que faz com que vulnerabilidades potencialmente perigosas não sejam catalogadas como tal, nem detetadas atempadamente.
Há um fator de aceleração adicional que vale a pena compreender, uma vez que a redução do enriquecimento está a colidir com a rápida proliferação da deteção de ameaças assistida por IA.
Os modelos avançados de IA e as ferramentas de programação estão a reduzir significativamente as dificuldades na identificação de vulnerabilidades exploráveis e de vias de ataque complexas nas aplicações, o que está a provocar um aumento acentuado nas divulgações de CVE. Em fevereiro de 2026, o Fórum de Equipas de Resposta a Incidentes e Segurança (FIRST) previu que seriam comunicados 50 000 CVE adicionais em 2026, um número recorde. A infraestrutura de enriquecimento atual não está preparada para lidar com este volume mantendo os níveis de qualidade anteriores.
Por que razão os produtos desenvolvidos exclusivamente com base na NVD apresentam um problema
Um registo CVE bruto inclui normalmente um ID, uma descrição e referências. Os metadados que orientam a gestão automatizada de vulnerabilidades têm, historicamente, provindo dos analistas do NVD. Estes dados referem-se a pontuações de gravidade CVSS validadas de forma independente, mapeamentos de produtos CPE e classificações de vulnerabilidades CWE.
Mas é o «enriquecimento» que torna um CVE passível de ação. Sem ele, os fluxos de trabalho que dele dependem sofrem uma degradação previsível.
A priorização baseada no CVSS enfraquece
Quando um scanner ou uma ferramenta de aplicação de correções espera uma classificação de gravidade fornecida pelo NVD e não a encontra, a vulnerabilidade pode ser identificada como «gravidade desconhecida», ficar fora do âmbito das políticas de correção baseadas no SLA ou perder prioridade.
A atualização do NIST de abril de 2026 confirmou que:
- As CVEs que não se enquadram nos novos critérios de prioridade não serão automaticamente submetidas a uma avaliação independente
- O NIST deixará de gerar a sua própria pontuação CVSS quando uma CNA já tiver fornecido uma (mesmo que essa CNA seja o fornecedor do software afetado)
Um mapeamento CPE deficiente ou inexistente resulta numa deteção deficiente de CVE
A própria documentação da NVD descreve a identificação de produtos como uma parte fundamental do processo de enriquecimento, uma vez que permite aos utilizadores verificar programaticamente se uma vulnerabilidade conhecida afeta os produtos no seu ambiente.
Se os mapeamentos de CPE estiverem ausentes, incompletos ou atrasados, as ferramentas que dependem principalmente da correspondência de CPE podem não apresentar a correspondência ou apresentá-la com atraso.
Os fornecedores de produtos de segurança estão entre os mais afetados, uma vez que os seus produtos dependem frequentemente da correspondência de CPE e do enriquecimento de CVE. As ferramentas de gestão de patches, proteção de terminais, controlo de acesso à rede e gestão de ativos dependem de informações precisas sobre vulnerabilidades para determinar o que está afetado, qual a gravidade do problema e quais as medidas a tomar em seguida.
Para as equipas que estão a desenvolver novos produtos de segurança, basear-se apenas no NVD significa partir de uma base que pode já apresentar lacunas importantes: cobertura limitada de vulnerabilidades «zero-day», falta de informações adicionais para uma parte crescente de CVEs e ciclos de atualização que podem ter dificuldade em acompanhar o ritmo da descoberta e exploração de vulnerabilidades impulsionadas pela IA.
Para as equipas que já dispõem de capacidades de aplicação de patches ou correção, o risco é diferente, mas igualmente importante. A eficácia de um mecanismo de correção depende inteiramente da informação sobre vulnerabilidades que recebe. Se essa informação for incompleta, atrasada ou excessivamente dependente do enriquecimento de dados provenientes do NVD, os fluxos de trabalho a jusante podem não identificar os produtos afetados, atribuir menor prioridade a vulnerabilidades de gravidade desconhecida ou não agir a tempo, antes que a exposição aumente.
Se esses produtos herdarem os pontos fracos da NVD, esses pontos fracos poderão ser herdados por todos os clientes a jusante.
É precisamente essa lacuna que a Avaliação de Vulnerabilidades do OESIS Framework foi concebida para colmatar: ajudar as equipas de produtos de segurança a reforçar a informação sobre vulnerabilidades sem dependerem exclusivamente do enriquecimento de dados do NVD.
Como OPSWAT esta questão de forma diferente
OPSWAT o módulo de avaliação de vulnerabilidades do OESIS Framework especificamente para os criadores de produtos de segurança que necessitam de dados de vulnerabilidades fiáveis e úteis para a tomada de medidas, integrados nas suas ferramentas.
Concebido para colmatar a lacuna
O módulo agrega várias fontes, em vez de depender de uma única fonte.
Recorre a uma variedade de fontes comerciais e abertas de vulnerabilidades para garantir uma cobertura atempada e precisa de centenas de fornecedores e aplicações.
O catálogo de vulnerabilidades OESIS abrange atualmente mais de 65 000 CVEs únicas e mais de 150 000 instâncias de vulnerabilidades, sendo atualizado de forma contínua — várias vezes ao dia — em vez de aguardar os ciclos de processamento do NVD.
Uma pontuação de gravidade proprietária que vai além do CVSS, fornecendo mais contexto.
Os dados de vulnerabilidades OPSWAT incluem o OPSWAT Score, uma classificação proprietária que vai além da base CVSS, incorporando sinais adicionais, incluindo a popularidade do CVE, o risco de comprometimento e o ciclo de vida do CVE.
Num contexto em que uma parte crescente das pontuações CVSS pode ser auto-declarada pela CNA, esta camada independente de análise poderia ajudar os produtos de segurança a fornecer aos seus utilizadores um indicador de priorização mais fundamentado.
O serviço de informações sobre vulnerabilidades da OESIS suporta duas formas de integração, sem necessidade de uma fase de implementação complexa:
- Feed do catálogo: Compare os dados de vulnerabilidades do OESIS com o seu inventário de software existente no servidor — sem necessidade de agentes nos terminais. Os produtos existentes com funcionalidades de inventário de software podem utilizar os dados do OESIS para detetar vulnerabilidades nos ativos geridos.
- Endpoint (KitSoftware )Endpoint : Incorpore a estrutura OESIS diretamente no seu produto para vulnerability detection em tempo real no próprio dispositivo. Ideal para produtos de segurança que funcionam em terminais
Investigação interna sobre vulnerabilidades
A equipa interna de investigação de ameaças OPSWAT, a Unit 515, realiza investigação contínua em segurança ofensiva, simulação de ataques, testes avançados e divulgação responsável em infraestruturas críticas e software empresarial. A equipa identificou e comunicou mais de 50 vulnerabilidades de dia zero, incluindo descobertas críticas em software amplamente utilizado, como plataformas ICS/OT, tais como PLCs Delta, e plataformas nativas de IA.
O efeito líquido para os criadores de produtos de segurança é que as suas ferramentas poderão manter uma cobertura mais abrangente das vulnerabilidades, mesmo que o âmbito de enriquecimento do NVD se reduza — sem que os clientes tenham de aceitar uma visibilidade reduzida ou soluções alternativas manuais.
Detecção + Correção: O ciclo completo
A deteção identifica os pontos vulneráveis. A correção resolve o problema. Em conjunto, ajudam a fechar o ciclo de risco tanto quanto possível. O OESIS Vulnerability Assessment encarrega-se da deteção e da priorização. Patch Management OESIS Patch Management está disponível para equipas que pretendam ambas as funcionalidades numa única estrutura:
- Detecção: Aplicações vulneráveis, com correspondência de versão, OPSWAT e sinalizadas pelo KEV
- Priorização: OPSWAT ajuda a identificar o que deve ser corrigido em primeiro lugar, com base em sinais de exploração reais
- Correção: O seu pipeline atual pode processar os resultados do OESIS — ou o OESIS Patch Management aplicar patches, impor versões ou bloquear o acesso diretamente
- Verificação: O OESIS realiza uma nova verificação após a correção para ajudar a confirmar que o terminal está limpo antes de o acesso ser restabelecido
A deteção sem correção é um relatório. A deteção com correção é um risco resolvido. O OESIS tem como objetivo proporcionar ao seu produto ambas as coisas, ajudando a fechar os ciclos de deteção e correção mais rapidamente para acompanhar melhor as ameaças à velocidade da IA.
As vulnerabilidades do AI-Speed requerem a detecção do AI-Speed
Os produtos de segurança não podem dar-se ao luxo de tratar as informações sobre vulnerabilidades como uma dependência de back-end de evolução lenta. À medida que o volume de CVE aumenta e o enriquecimento se torna menos consistente, as equipas de produto precisam de uma forma de manter os fluxos de trabalho de deteção, priorização e correção alinhados com a exposição real.
É aí que entra a Avaliação de Vulnerabilidades do OESIS Framework. Oferece aos criadores de produtos uma forma prática de reforçar a cobertura de vulnerabilidades sem terem de reconstruir do zero a sua pilha de terminais ou de correção. Para as equipas que estão a lançar um novo produto, pode ajudar a estabelecer uma cobertura fiável numa fase mais precoce. Para as equipas que estão a melhorar um produto existente, oferece uma forma mais simples de comparar a cobertura, validar melhorias e decidir como deve ser uma integração mais profunda.
