NVD en la era de la IA: por qué necesitamos inteligencia de vulnerabilidades de múltiples fuentes

Durante más de veinte años, la comunidad global de seguridad ha operado bajo una suposición cómoda: que una fuente pública centralizada podía ayudar a rastrear, analizar y enriquecer las vulnerabilidades de software del mundo al ritmo que necesitaba la industria.

Cuando se estableció la National Vulnerability Database (NVD), el ciclo de vida de las vulnerabilidades de código abierto avanzaba a un ritmo radicalmente diferente. Los ecosistemas de código abierto eran más pequeños, los ciclos de lanzamiento eran más lentos y el volumen de vulnerabilidades divulgadas públicamente era más fácil de gestionar mediante el enriquecimiento centralizado.

Pero el ecosistema de software moderno ya superó oficialmente ese paradigma heredado. El 15 de abril de 2026, el National Institute of Standards and Technology (NIST) recalibró su enfoque operativo y modificó su antiguo mandato de enriquecer todas las vulnerabilidades. Ante un flujo insostenible de envíos, la agencia anunció un modelo de clasificación por prioridades y afirmó explícitamente que, con los recursos actuales, ya no es realista enriquecer por completo cada CVE.

Qué significa esto para Snyk

Impacto general: operamos de forma independiente

Snyk no depende únicamente de la NVD para enriquecer vulnerabilidades, por lo que el anuncio de NIST no cambia nuestro enfoque respecto a la inteligencia de vulnerabilidades. Más bien, refuerza el enfoque que hemos seguido durante años, como explicamos anteriormente en «Cómo los usuarios de Snyk evitan las demoras de la NVD»: la NVD sigue siendo una fuente importante, pero es solo una parte de un ecosistema de inteligencia más amplio que incluye múltiples fuentes de vulnerabilidades, validación por parte de analistas de seguridad y contexto de código abierto.

Este enfoque ayuda a los clientes a seguir tomando decisiones de priorización fundamentadas, incluso mientras evolucionan los modelos públicos de enriquecimiento.

En lugar de depender de los procesos de validación del sector público, enriquecemos nuestros datos mediante procesos internos de varias capas. Cuando corresponde, presentamos los vectores CVSS de la NVD junto con nuestras propias evaluaciones CVSS para ayudarte a entender cómo se evalúa una vulnerabilidad en distintas fuentes. Snyk Intelligence está diseñado para ayudar a los clientes a entender no solo si existe un CVE, sino también qué significa en el contexto del software de código abierto. Ofrece información fundamental sobre qué versiones de paquetes son vulnerables, si hay una corrección disponible, cómo se evalúa el riesgo en distintas fuentes y cómo priorizar exactamente la corrección.

Además de recopilar avisos de vulnerabilidades de diversas fuentes, Snyk mejora y reevalúa y actualiza continuamente la base de datos de seguridad mediante:

• Investigación de seguridad interna

• Integración de inteligencia de amenazas: diversas señales, como la actividad de explotación, las menciones en redes sociales y la publicación de pruebas de concepto (PoC)

• Contribuciones de la comunidad: divulgaciones responsables de la comunidad de código abierto, incluidos investigadores independientes y responsables de mantenimiento de proyectos

• Colaboraciones académicas y de investigación

• Priorización centrada en el cliente: ayudar a los clientes a convertir datos sin procesar sobre vulnerabilidades en inteligencia práctica que respalde los flujos de trabajo de priorización de desarrolladores y equipos de AppSec

• Inteligencia asistida por IA y validada por personas: a medida que aumenta el volumen de vulnerabilidades, Snyk usa flujos de trabajo asistidos por IA y automatización para recopilar, filtrar, priorizar y enriquecer señales de vulnerabilidades a gran escala. Pero la automatización por sí sola no es suficiente. Snyk mantiene un enfoque con intervención humana, en el que analistas de seguridad capacitados validan y aprueban las sugerencias generadas por IA para ayudar a garantizar que los clientes reciban inteligencia de vulnerabilidades confiable, precisa y práctica.

La nueva era de los datos sobre amenazas

¿En qué consiste exactamente este cambio?

La NVD adoptó un modelo de clasificación por prioridades basado en riesgos y dejó atrás el objetivo anterior de enriquecer todas las vulnerabilidades de inmediato. Este cambio estructural puede generar importantes puntos ciegos en la industria, en particular para los analizadores heredados que dependen en gran medida de los datos de la NVD para obtener puntuaciones CVSS y enriquecer información sobre software que ya no se considera prioritario. Con este nuevo enfoque, la NVD priorizará el enriquecimiento completo de los CVE que cumplan cualquiera de estos criterios:

• CVE incluidos en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA (con el objetivo de enriquecerlos dentro de un día hábil desde su recepción).

• CVE de software utilizado por el gobierno federal de EE. UU.

• CVE de software crítico según la definición de la Orden Ejecutiva 14028.

Todo CVE que no pertenezca a estas categorías queda sistemáticamente relegado al estado «Prioridad más baja: no programado para enriquecimiento inmediato». Para dimensionar esta brecha de cobertura, considera las cifras: aunque solo en 2025 se publicaron 48,185 CVE únicos, el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA registró alrededor de 245 entradas nuevas a fines de 2025. Para obtener más contexto sobre el volumen de vulnerabilidades de 2026 y las tendencias del KEV, consulta Las vulnerabilidades explotadas conocidas de CISA aumentaron un 20 % en 2025.
Depender exclusivamente de este marco público implica que las organizaciones están configurando sus analizadores para centrarse en una lista muy selectiva, aprobada por el gobierno. Al hacerlo, corren el riesgo de pasar por alto información fundamental sobre el vasto universo de paquetes de código abierto que, aunque no estén clasificados actualmente como críticos ni se estén explotando de forma activa, siguen siendo la base de la seguridad de las aplicaciones modernas.

Además, una parte significativa de los CVE históricos publicados antes del 1 de marzo de 2026 se clasificó como «No programado», y muchos más se marcaron como «Modificado después del enriquecimiento», un estado que indica que no necesariamente se volverán a evaluar como habría ocurrido con el modelo anterior. Esto refleja la reclasificación de vulnerabilidades que antes estaban pendientes como parte del modelo de enriquecimiento actualizado y pone de relieve la magnitud de la gestión del trabajo acumulado que ahora forma parte del nuevo enfoque.

Es importante destacar que NIST también introdujo un cambio operativo significativo en la forma de gestionar las puntuaciones y modificaciones para reducir la duplicación de esfuerzos:

• Optimización de las puntuaciones de gravedad: NIST ya no proporcionará de forma rutinaria una puntuación de gravedad independiente cuando la Autoridad de Numeración de CVE (CNA) que envió el CVE —como el proveedor de software o el responsable de mantenimiento del paquete— ya haya proporcionado una.

• Gestión de CVE modificados: en lugar de volver a analizar todos los CVE modificados, como exigía la política anterior, NIST ahora solo lo hará si tiene conocimiento de una modificación que afecte de manera sustancial los datos de enriquecimiento.

Esto hace que sea aún más necesario que los equipos de seguridad entiendan el origen y el contexto del enriquecimiento de vulnerabilidades. Cuando NIST no proporcione una puntuación de gravedad independiente adicional, es posible que las organizaciones deban depender más de las puntuaciones proporcionadas por las CNA, los metadatos de los proveedores y otras fuentes de enriquecimiento. Los datos de las CNA son valiosos y, a menudo, provienen de responsables de mantenimiento que conocen mejor el software afectado. Sin embargo, también pueden presentar diferencias en las metodologías de puntuación, las interpretaciones del riesgo, los incentivos para la divulgación o las presiones operativas, como los plazos de corrección y las expectativas de los SLA.
Por eso, la transparencia sobre las fuentes, la validación independiente y la inteligencia de vulnerabilidades de múltiples fuentes son más importantes que nunca.

Era inevitable

Este cambio no ocurrió de la noche a la mañana; culmina años de presión sobre el sistema de gestión de vulnerabilidades que, en la práctica, se había convertido en el estándar. Cuando los envíos anuales de CVE aumentaron un 263 %: de aproximadamente 18,000 entradas en 2020 a más de 48,000 en 2025, las operaciones de la NVD dejaron de ser sostenibles. Esto se debió a cambios estructurales en el sistema CVE, que adoptó un modelo federado en lugar de centralizado para asignar CVE. Así se eliminó un cuello de botella administrativo y se permitió que un grupo mucho más amplio y diverso de entidades contribuyera al catálogo público de vulnerabilidades. Al mismo tiempo, la IA está acelerando el ritmo de la investigación de vulnerabilidades. Ayuda a los investigadores a avanzar más rápido en distintas etapas del proceso, desde el descubrimiento y la validación hasta la creación de pruebas de concepto y la elaboración de informes. Esto no significa que todos los informes generados por IA sean de alta calidad, pero sí que es probable que el volumen y la velocidad de las señales de vulnerabilidades sigan aumentando.

La actualización de NIST refleja esta realidad. Incluso después de enriquecer casi 42,000 CVE en 2025 —un 45 % más que en cualquier año anterior—, NIST afirmó que el aumento de la productividad aún no bastaba para mantenerse al día con el creciente volumen de envíos.

El nuevo modelo basado en riesgos busca ayudar a NIST a enfocarse en los CVE más críticos, estabilizar el programa y desarrollar los sistemas automatizados y las mejoras en los flujos de trabajo necesarios para garantizar su sostenibilidad a largo plazo. Así, aunque la responsabilidad de ingresar datos de alta calidad en el proceso de gestión de vulnerabilidades recae ahora en los proveedores de software y quienes reportan vulnerabilidades, los usuarios finales y las herramientas que utilizan deben encargarse de darle sentido a toda esa información.

¿Por qué ocurre esto ahora?

El principal factor detrás de este aumento exponencial de los CVE se resume en dos letras: IA.
Como destacamos en nuestro análisis detallado «La investigación de vulnerabilidades en la era de la IA», la inteligencia artificial ha cambiado por completo la economía de la búsqueda de errores. Las herramientas automatizadas de descubrimiento impulsadas por IA pueden analizar bases de código de forma autónoma, detectar fallas y generar miles de informes de vulnerabilidades sin procesar en una fracción del tiempo que necesitaría una persona investigadora para lograr los mismos resultados.
Esto crea un ciclo de retroalimentación continuo: las herramientas de detección con IA avanzan y analizan de manera exhaustiva las bases de código existentes, incorporando un volumen de datos sin precedentes al panorama de vulnerabilidades.

Sin embargo, este volumen no se debe únicamente a la IA; también es resultado de un enorme cambio operativo en la forma de reportar vulnerabilidades. El crecimiento exponencial comenzó años antes, con la expansión del modelo federado de CVE. En 2018, el programa se descentralizó mediante una rápida ampliación de su red de autoridades de numeración de CVE (CNA). Antes, un pequeño grupo de organizaciones se encargaba de ingresar los datos; ahora hay más de 500 CNA independientes —incluidos proveedores de software, responsables de mantenimiento de paquetes y proveedores de servicios en la nube— que publican sus divulgaciones directamente en el catálogo global al mismo tiempo.

En Snyk, consideramos que esta es una de las razones por las que debe evolucionar la inteligencia de vulnerabilidades. El desafío no consiste simplemente en recopilar más datos. El verdadero desafío es contextualizarlos, validarlos, enriquecerlos y priorizarlos para que los equipos de seguridad y desarrollo puedan enfocarse en los problemas que realmente importan.

Calidad, no ruido

Los equipos de seguridad y desarrollo necesitan inteligencia de vulnerabilidades confiable, fácil de entender y práctica.

Snyk apuesta por el mapeo preciso de vulnerabilidades. En lugar de asignar el riesgo a todo un proyecto de código abierto, Snyk Open Source identifica, cuando es posible, el paquete específico afectado, el rango de versiones vulnerables, el componente pertinente o la ruta de código, las correcciones disponibles y la evidencia que respalda el aviso. Esto ayuda a reducir el ruido innecesario y ofrece a los desarrolladores y agentes de corrección una orientación más clara sobre lo que realmente deben corregir.

Como mencionamos antes, los informes generados por IA pueden ayudar a detectar indicios útiles, pero, según nuestra experiencia, también suelen presentar análisis incompletos, hallazgos duplicados y señales de baja calidad que requieren una validación cuidadosa. Hemos visto repetidamente informes de vulnerabilidades con evidencia insuficiente, evaluaciones de impacto poco claras o hallazgos que finalmente no superan la revisión de quienes mantienen el proyecto. Por ejemplo, cuando quien mantiene un proyecto rechaza un informe de vulnerabilidad, Snyk realiza una revisión adicional antes de decidir si lo incluirá en su inteligencia de vulnerabilidades y cómo lo representará.

Este enfoque deliberado en la evidencia, la atribución y la validación ayuda a reducir la fatiga por alertas y permite que los equipos de ingeniería y AppSec se concentren en vulnerabilidades precisas, relevantes y prácticas.

Lo que viene

La actualización de NVD es una señal clara de que la gestión de vulnerabilidades ha entrado en una nueva etapa. CVE sigue siendo un identificador compartido fundamental, y NVD continúa siendo una fuente pública importante para enriquecer la información sobre vulnerabilidades. Sin embargo, a medida que aumenta el volumen de vulnerabilidades y la IA acelera su detección, validación y reporte, los equipos de seguridad ya no pueden depender de una sola fuente de enriquecimiento ni únicamente de una puntuación de gravedad estática.

El futuro de la inteligencia sobre vulnerabilidades estará definido por el contexto, la priorización y la capacidad de acción. El objetivo ya no es evaluar las vulnerabilidades una por una, sino ofrecer a las personas y los agentes de IA una visión continuamente actualizada de la superficie de ataque, que destaque los riesgos más importantes y las intervenciones con mayor probabilidad de reducir la exposición general.

Para Snyk, este es precisamente el rumbo que debe tomar la inteligencia. Snyk combina el enriquecimiento de múltiples fuentes, el contexto del ecosistema de código abierto, los flujos de trabajo asistidos por IA y la experiencia humana en seguridad para ayudar a los clientes a pasar de un volumen bruto de vulnerabilidades a acciones informadas y priorizadas.

A medida que el panorama de vulnerabilidades sigue evolucionando, la inteligencia sobre vulnerabilidades también debe hacerlo: debe ir más allá del enriquecimiento y la calificación de gravedad para convertirse en la base de decisiones de seguridad más rápidas y mejor informadas.