NVD na era da IA: por que a inteligência de vulnerabilidades precisa de múltiplas fontes

Há mais de vinte anos, a comunidade global de segurança trabalha com uma premissa confortável: uma fonte pública centralizada poderia ajudar a acompanhar, analisar e enriquecer informações sobre as vulnerabilidades de software do mundo no ritmo necessário para o setor.

Quando o National Vulnerability Database (NVD) foi criado, o ciclo de vida das vulnerabilidades de código aberto avançava em um ritmo completamente diferente. Os ecossistemas de código aberto eram menores, os ciclos de lançamento eram mais lentos e o volume de vulnerabilidades divulgadas publicamente era mais fácil de administrar com o enriquecimento centralizado.

Mas o ecossistema de software moderno já superou esse modelo legado. Em 15 de abril de 2026, o National Institute of Standards and Technology (NIST) recalibrou sua abordagem operacional e atualizou seu antigo compromisso de enriquecer universalmente as informações sobre vulnerabilidades. Diante de um volume insustentável de envios, a agência anunciou um modelo de triagem priorizada e declarou explicitamente que, com os recursos atuais, não é mais realista enriquecer por completo todas as CVEs.

O que isso significa para a Snyk

Impacto geral: atuação independente

A Snyk não depende exclusivamente do NVD para enriquecer informações sobre vulnerabilidades. Por isso, o anúncio do NIST não muda nossa abordagem à inteligência de vulnerabilidades. Pelo contrário, reforça o caminho que seguimos há anos, como explicamos anteriormente em "Como os usuários da Snyk evitam atrasos do NVD". O NVD continua sendo uma fonte importante, mas é apenas uma parte de um ecossistema de inteligência mais amplo, que inclui várias fontes de vulnerabilidades, validação por analistas de segurança e contexto de código aberto.

Essa abordagem ajuda os clientes a continuar tomando decisões de priorização bem fundamentadas, mesmo com a evolução dos modelos públicos de enriquecimento.

Em vez de depender de ciclos de validação do setor público, enriquecemos nossos dados por meio de processos internos em várias camadas. Quando aplicável, apresentamos os vetores CVSS do NVD ao lado de nossas próprias avaliações CVSS para ajudar você a entender como uma vulnerabilidade é avaliada em diferentes fontes. A Snyk Intelligence foi desenvolvida para ajudar os clientes a entender não apenas se uma CVE existe, mas também o que ela significa no contexto de software de código aberto. Ela esclarece quais versões de pacotes estão vulneráveis, se há uma correção disponível, como o risco é avaliado entre as fontes e exatamente como priorizar a correção.

Além de coletar avisos de vulnerabilidades de diversas fontes, a Snyk aprimora, reavalia continuamente e atualiza o banco de dados de segurança por meio de:

• Pesquisa de segurança interna

• Integração de inteligência de ameaças: diversos sinais, incluindo atividades de exploração, menções nas redes sociais e publicação de provas de conceito (PoCs)

• Contribuições da comunidade: divulgações responsáveis da comunidade de código aberto, incluindo pesquisadores independentes e mantenedores de projetos

• Colaborações acadêmicas e de pesquisa

• Priorização centrada nos clientes: ajudamos os clientes a transformar dados brutos de vulnerabilidades em inteligência acionável, que dá suporte aos fluxos de trabalho de priorização de desenvolvedores e equipes de AppSec

• Inteligência assistida por IA e validada por pessoas: à medida que o volume de vulnerabilidades cresce, a Snyk usa fluxos de trabalho assistidos por IA e automação para coletar, filtrar, priorizar e enriquecer sinais de vulnerabilidades em grande escala. Mas a automação, por si só, não basta. A Snyk mantém uma abordagem com participação humana, na qual analistas de segurança treinados validam e aprovam sugestões geradas por IA para ajudar a garantir que os clientes recebam inteligência de vulnerabilidades confiável, precisa e acionável.

Uma nova era para os dados de ameaças

O que exatamente mudou?

O NVD adotou um modelo de triagem baseado em risco, deixando para trás a meta anterior de enriquecer de forma universal e imediata as informações sobre vulnerabilidades. Essa mudança estrutural pode criar pontos cegos significativos no setor, especialmente para scanners legados que dependem muito dos dados do NVD para obter pontuações CVSS e enriquecer informações sobre softwares que deixaram de ser prioritários. Com a nova abordagem, o NVD dará prioridade ao enriquecimento completo das CVEs que atendam a pelo menos um dos seguintes critérios:

• CVEs incluídas no Catálogo de Vulnerabilidades Conhecidamente Exploradas (KEV) da CISA (com a meta de enriquecê-las em até um dia útil após o recebimento).

• CVEs de softwares usados pelo governo federal dos EUA.

• CVEs de softwares críticos, conforme definido pela Ordem Executiva 14028.

Qualquer CVE fora dessas categorias será sistematicamente classificada como "Prioridade mais baixa — sem previsão de enriquecimento imediato". Para entender a dimensão dessa lacuna de cobertura, vale olhar os números: embora 48.185 CVEs únicas tenham sido publicadas somente em 2025, o catálogo de Vulnerabilidades Conhecidamente Exploradas (KEV) da CISA registrou cerca de 245 novas entradas até o fim de 2025. Para saber mais sobre o volume de vulnerabilidades e as tendências do KEV em 2026, confira As vulnerabilidades conhecidamente exploradas da CISA aumentaram 20% em 2025.
Depender exclusivamente dessa estrutura pública significa ajustar os scanners das organizações a uma lista altamente seletiva, aprovada pelo governo. Com isso, elas correm o risco de perder contexto crítico sobre o vasto universo de pacotes de código aberto que, mesmo sem serem classificados como críticos ou explorados ativamente, ainda formam a base da segurança de aplicações modernas.

Além disso, uma parcela significativa das CVEs históricas publicadas antes de 1º de março de 2026 foi classificada como “Sem previsão”, e muitas outras receberam a classificação “Modificada após o enriquecimento”, que indica que elas não serão necessariamente reavaliadas, como aconteceria no modelo antigo. Isso reflete a reclassificação de vulnerabilidades que estavam acumuladas, como parte do modelo de enriquecimento atualizado, e mostra a dimensão da gestão desse acúmulo na nova abordagem.

É importante destacar que o NIST também introduziu uma mudança operacional significativa na forma de lidar com pontuações e modificações, para reduzir a duplicação de esforços:

• Simplificação das pontuações de gravidade: o NIST não fornecerá mais rotineiramente uma pontuação de gravidade separada quando a Autoridade de Numeração de CVEs (CNA) que enviou a CVE — como o fornecedor do software ou o mantenedor do pacote — já tiver fornecido uma.

• Tratamento de CVEs modificadas: em vez de reanalisar todas as CVEs modificadas, como a política anterior determinava, o NIST só fará isso se tiver conhecimento de uma modificação que afete de forma significativa os dados de enriquecimento.

Isso torna ainda mais importante que as equipes de segurança entendam a origem e o contexto do enriquecimento das informações sobre vulnerabilidades. Quando o NIST não fornece uma pontuação de gravidade independente adicional, as organizações podem precisar depender mais das pontuações fornecidas pelas CNAs, dos metadados dos fornecedores e de outras fontes de enriquecimento. Os dados das CNAs são valiosos e muitas vezes vêm dos mantenedores mais próximos do software afetado, mas também podem apresentar diferenças nas metodologias de pontuação, interpretações de risco, incentivos para divulgação ou pressões operacionais, como prazos de correção e expectativas de SLA.
Por isso, a transparência das fontes, a validação independente e a inteligência de vulnerabilidades baseada em múltiplas fontes são mais importantes do que nunca.

Era inevitável

Essa mudança não aconteceu da noite para o dia. Ela é o resultado de anos de pressão sobre a estrutura de fato de gestão de vulnerabilidades. Quando o número anual de envios de CVEs saltou 263%, de cerca de 18.000 em 2020 para mais de 48.000 em 2025, as contas simplesmente deixaram de fechar para os processos do NVD. Isso ocorreu devido a mudanças estruturais no sistema de CVEs, que adotou um modelo federado, em vez de centralizado, para atribuir CVEs. Com isso, eliminou-se um gargalo administrativo e permitiu-se que um conjunto muito maior e mais diverso de entidades contribuísse para o catálogo público de vulnerabilidades. Ao mesmo tempo, a IA está acelerando a pesquisa de vulnerabilidades. Ela ajuda pesquisadores a avançar mais rápido em várias etapas do processo, da descoberta e validação à criação de provas de conceito e à elaboração de relatórios. Isso não significa que todo relatório gerado por IA tenha alta qualidade, mas indica que o volume e a velocidade dos sinais de vulnerabilidade provavelmente continuarão aumentando.

A atualização do NIST reflete essa realidade. Mesmo depois de enriquecer quase 42.000 CVEs em 2025 — 45% a mais do que em qualquer ano anterior —, o NIST declarou que o aumento da produtividade ainda não foi suficiente para acompanhar o crescimento dos envios.

O novo modelo baseado em risco busca ajudar o NIST a se concentrar nas CVEs mais críticas, estabilizar o programa e desenvolver os sistemas automatizados e as melhorias nos fluxos de trabalho necessários para garantir sua sustentabilidade a longo prazo. Assim, embora a responsabilidade de inserir dados de alta qualidade no processo de gestão de vulnerabilidades passe a recair novamente sobre fornecedores de software e pessoas que reportam vulnerabilidades, cabe aos usuários finais e às ferramentas que utilizam interpretar todas essas informações.

Por que isso está acontecendo agora?

O principal fator por trás desse aumento exponencial de CVEs pode ser resumido em duas letras: IA.
Como mostramos em nossa análise aprofundada sobre “Pesquisa de vulnerabilidades na era da IA”, a inteligência artificial mudou completamente a dinâmica econômica da busca por bugs. Ferramentas automatizadas de descoberta baseadas em IA conseguem analisar bases de código de forma autônoma, encontrar falhas e gerar milhares de relatórios brutos de vulnerabilidades em uma fração do tempo que um pesquisador humano levaria para chegar aos mesmos resultados.
Isso cria um ciclo contínuo de retroalimentação: as ferramentas de detecção por IA estão avançando e analisando bases de código existentes de forma abrangente, introduzindo um volume sem precedentes de dados no cenário de vulnerabilidades.

No entanto, esse volume não é apenas resultado da IA; também decorre de uma grande mudança operacional na forma como as vulnerabilidades são reportadas. O crescimento exponencial começou anos antes, com a expansão do modelo federado de CVEs. Em 2018, o programa foi descentralizado por meio da rápida ampliação da rede de Autoridades de Numeração de CVEs (CNAs). Antes, um pequeno grupo de organizações cuidava do registro dos dados. Hoje, mais de 500 CNAs independentes — incluindo fornecedores de software, mantenedores de pacotes e provedores de nuvem — publicam divulgações diretamente no catálogo global ao mesmo tempo.

Na Snyk, vemos nisso uma das razões pelas quais a inteligência de vulnerabilidades precisa evoluir. O desafio não é apenas coletar mais dados. O mais importante é contextualizar, validar, enriquecer e priorizar esses dados, para que as equipes de segurança e desenvolvimento possam se concentrar nos problemas que realmente importam.

Qualidade acima do ruído

As equipes de segurança e desenvolvimento precisam de inteligência de vulnerabilidades em que possam confiar, que consigam entender e à qual possam dar uma resposta.

A Snyk acredita em mapeamento preciso de vulnerabilidades. Em vez de atribuir o risco a um projeto inteiro de código aberto, a Snyk Open Source identifica, sempre que possível, o pacote afetado, o intervalo de versões vulneráveis, o componente ou caminho de código relevante, a correção disponível e as evidências que embasam o aviso. Isso reduz ruídos desnecessários e oferece aos desenvolvedores e agentes de correção orientações mais claras sobre o que realmente precisa ser corrigido.

Como mencionamos, relatórios gerados por IA podem ajudar a encontrar pistas úteis, mas, na nossa experiência, também costumam apresentar análises incompletas, descobertas duplicadas e sinais de baixa qualidade que exigem uma validação cuidadosa. Já vimos repetidamente relatórios de vulnerabilidades sem evidências suficientes, com avaliações de impacto pouco claras ou com descobertas que não passam pela análise dos mantenedores. Por exemplo, quando o mantenedor de um projeto rejeita um relatório de vulnerabilidade, a Snyk realiza uma análise adicional antes de decidir se, e como, a informação deve ser incluída na inteligência de vulnerabilidades da Snyk.

Esse foco deliberado em evidências, atribuição e validação ajuda a reduzir a fadiga de alertas e permite que as equipes de engenharia e AppSec se concentrem em vulnerabilidades precisas, relevantes e que possam ser corrigidas.

O que vem pela frente

A atualização do NVD é um sinal claro de que o gerenciamento de vulnerabilidades entrou em uma nova fase. O CVE continua sendo um identificador compartilhado essencial, e o NVD permanece uma importante fonte pública de enriquecimento de dados sobre vulnerabilidades. Mas, à medida que o volume de vulnerabilidades aumenta e a IA acelera sua descoberta, validação e divulgação, as equipes de segurança não podem mais depender de uma única fonte de enriquecimento nem apenas de uma pontuação estática de severidade.

O futuro da inteligência sobre vulnerabilidades será definido por contexto, priorização e capacidade de orientar ações. O objetivo já não é avaliar vulnerabilidades uma a uma, mas oferecer a pessoas e agentes de IA uma visão continuamente atualizada da superfície de ataque, destacando os riscos mais importantes e as intervenções com maior potencial de reduzir a exposição geral.

Para a Snyk, é exatamente nessa direção que a inteligência precisa avançar. A Snyk combina enriquecimento de múltiplas fontes, contexto do ecossistema de código aberto, fluxos de trabalho com auxílio de IA e conhecimento especializado em segurança para ajudar os clientes a transformar um volume bruto de vulnerabilidades em ações bem informadas e priorizadas.

À medida que o cenário de vulnerabilidades continua evoluindo, a inteligência sobre vulnerabilidades também precisa evoluir — indo além do enriquecimento de dados e da pontuação de severidade para se tornar a base de decisões de segurança mais rápidas e bem informadas.