Una Common Vulnerability and Exposure (CVE) es una falla de seguridad conocida y catalogada. Cuando una vulnerabilidad obtiene una CVE, significa que la comunidad de seguridad la ha identificado, nombrado y añadido a una base de datos pública (principalmente cve.org con puntuación y contexto añadidos por la National Vulnerability Database (NVD) de NIST) para que cualquiera pueda consultarla y actuar en consecuencia. El seguimiento de las CVEs proporciona al mundo de la seguridad un punto de referencia común, permitiendo a los equipos priorizar y responder a las fallas conocidas antes de que los atacantes las exploten. ¿Sencillo en teoría, verdad?
Pero hay un problema: más de 48.000 CVEs fueron publicadas solo en 2025. Esto supone 131 nuevas vulnerabilidades cada día. Los modelos de IA y las capacidades de escaneo están haciendo que el descubrimiento de vulnerabilidades sea más rápido y accesible que nunca, pero validar los hallazgos a escala es más difícil porque el volumen de envíos supera la infraestructura diseñada para gestionarlos. La NVD está cediendo bajo el volumen, y un número creciente de vulnerabilidades reales nunca llegan a ser reportadas.
Esta guía cubre cómo funcionan las CVEs, cómo se puntúan, dónde está fallando el sistema y qué están haciendo los equipos para adelantarse a ello.
¿Qué incluye un registro CVE?
Un ID de CVE es como un número de serie, con el formato: 'CVE-YYYY-#####'.
Cada registro contiene:
- ID de CVE
- Descripción
- Referencias
- Asignación de CNA
- Fecha de creación del registro
Los registros de CVE más antiguos también pueden incluir campos heredados, como fase, votos, comentarios y propuesto, que ya no se utilizan en las nuevas entradas.
¿Quién mantiene la base de datos CVE?
La respuesta corta es: ninguna organización única lo hace. Y ese es cada vez más el problema.
La corporación MITRE supervisa el programa CVE en sí, asignando IDs y manteniendo la lista oficial, y todos los registros CVE son de libre consulta y uso. La NVD ha sido históricamente donde esas entradas CVE en bruto se enriquecen con puntuaciones CVSS, detalles de parches y contexto técnico. También es donde la mayoría de las herramientas de seguridad extraen sus datos. La Cybersecurity and Infrastructure Security Agency (CISA) proporciona apoyo financiero. Otras bases de datos, como la CERT/CC Vulnerability Notes Database y GitHub Advisory, cubren lagunas adicionales.
Pero ninguna de estas fue nunca verdaderamente completa, y en 2026, las grietas son difíciles de ignorar. NIST ha adoptado un enfoque 'basado en el riesgo' que prioriza las CVEs para el software del gobierno de EE. UU. y aquellas en el catálogo de Known Exploited Vulnerabilities (KEV), dejando el resto sin enriquecer, con el creciente retraso efectivamente movido a 'no programado'. El programa CVE de MITRE ha enfrentado problemas de financiación. La UE ha lanzado su propia alternativa, la European Vulnerability Database (EUVD), pero aún está en sus primeras etapas y sigue dependiendo en gran medida de la sincronización con la NVD. Ya no existe una única fuente de verdad, y depender de una sola base de datos significa tener menos cobertura y visibilidad de lo esperado. Este es exactamente el problema que Aikido Intel pretendía resolver: monitorizar millones de paquetes de código abierto en busca de parches relevantes para la seguridad que nunca llegan a ninguna base de datos oficial, y alimentar los hallazgos directamente en la plataforma Aikido para que los usuarios sean alertados automáticamente.
¿Cómo se encuentran y asignan las CVEs?
Cualquiera puede reportar una vulnerabilidad: empresas de seguridad, investigadores independientes, desarrolladores individuales, incluso usuarios curiosos. Muchas organizaciones ejecutan programas de bug bounty que pagan a los investigadores por hallazgos válidos, y los proyectos de código abierto suelen depender de la divulgación comunitaria.
Una vez reportada una vulnerabilidad, una CVE Numbering Authority (CNA) la valida, asigna un ID de CVE, escribe una breve descripción y añade referencias antes de publicarla en la lista oficial de CVE. Las CNAs son organizaciones autorizadas por MITRE para asignar CVEs dentro de un ámbito definido, incluyendo grandes proveedores como Microsoft, Google y RedHat, fundaciones de código abierto como Python Software Foundation, firmas de investigación de seguridad, así como plataformas como Django y GitLab. Normalmente, un ID de CVE se asigna antes de que la vulnerabilidad se haga pública. Los proveedores mantienen los detalles en secreto mientras desarrollan y prueban una solución, y luego divulgan todo a la vez. Esto se conoce como divulgación coordinada, el estándar ampliamente recomendado para la notificación responsable de vulnerabilidades, respaldado por CISA, ENISA y FIRST.
No todos los problemas reportados califican. Se deben cumplir tres criterios:
- Solucionable de forma independiente: La falla puede corregirse por sí misma, independientemente de otros errores.
- Reconocido por el proveedor: El proveedor confirma que el problema representa un riesgo de seguridad, o un informe de terceros demuestra su impacto.
- Afecta a una única base de código: Si una vulnerabilidad afecta a múltiples productos, cada uno obtiene su propia CVE. Los registros se mantienen lo más aislados posible.
¿Cómo puedo encontrar registros de CVE?
La información de CVE es gratuita y de acceso público. Para una fuente de nuevas entradas en tiempo real, siga a @CVEnew en X. Con una tasa actual de más de 130 nuevas CVEs al día, la información avanza rápidamente. Para acceso masivo a registros históricos desde 1999, CVE.org/Downloads ofrece la base de datos completa a través de un repositorio de GitHub en formato JSON 5.0/5.1, actualizada aproximadamente cada siete minutos. CVEdetails.com proporciona una interfaz más accesible y con capacidad de búsqueda, con actualizaciones diarias.
¿Cómo asocias tus librerías con el CVE correcto?
Al analizar una vulnerabilidad, la clave es hacer coincidir el nombre del paquete y el número de versión para asegurarse de que está consultando la CVE correcta para su dependencia específica. Herramientas como Aikido gestionan esto automáticamente al hacer coincidir los nombres de los paquetes y las versiones con las bases de datos de vulnerabilidades, para que no tenga que hacerlo manualmente.
¿Qué es la puntuación CVSS?
El CVSS (Common Vulnerability Scoring System) es el estándar utilizado para calificar la gravedad de una vulnerabilidad en una escala de 0.0 a 10.0. La mayoría de las entradas CVE incluyen una puntuación CVSS, lo que permite a los equipos de seguridad evaluar rápidamente la seriedad de una falla. Las puntuaciones CVSS son típicamente asignadas por la NVD como parte de su proceso de enriquecimiento, aunque las CNA también pueden proporcionar puntuaciones. Cuando no coinciden, ambas pueden aparecer listadas.
¿Cómo se calcula una puntuación CVSS?
CVSS v4.0 se compone de cuatro grupos de métricas:
- Base: captura las características intrínsecas de una vulnerabilidad que son constantes en el tiempo
- Amenaza: refleja cómo esas características cambian en función de la actividad de explotación en el mundo real
- Ambiental: tiene en cuenta factores específicos de la configuración de su organización
- Suplementario: añade contexto adicional sin afectar la puntuación final
¿Qué es la escala de puntuación CVSS?
La (v4.0) Escala de Puntuación CVSS actual incluye cinco categorías:
- Crítica (9.0–10.0)
- Alta (7.0–8.9)
- Media (4.0–6.9)
- Baja (0.1–3.9)
- Ninguna (0.0)
Para contextualizar la escala, aquí tiene algunos ejemplos reales:
- Crítica: CVE-2021-44228 (Log4Shell). Puntuación CVSS v3.1: 10.0. Una ejecución remota de código en Apache Log4j. Un atacante podría ejecutar código arbitrario en un servidor enviando un mensaje de registro especialmente diseñado. Una de las vulnerabilidades más graves jamás reveladas.
- Alta: CVE-2017-0144 (EternalBlue). Puntuación CVSS v3.1: 8.8. Un fallo en Windows SMB (Server Message Block). Desarrollado originalmente como un exploit por la NSA, se filtró en 2017 y fue casi inmediatamente utilizado como arma en los ataques de ransomware WannaCry y NotPetya, que causaron miles de millones en daños en todo el mundo.
Para los niveles inferiores, los ejemplos conocidos son más raros, ya que las vulnerabilidades de baja gravedad no suelen ser noticia. En la práctica:
- Media: Típicamente incluye fallos que requieren condiciones específicas para su explotación, por ejemplo, una vulnerabilidad de cross-site scripting que necesita interacción del usuario, o una mala configuración que expone datos no críticos.
- Baja: Fallos que requieren acceso local o condiciones inusuales, por ejemplo, un archivo de configuración con credenciales predeterminadas al que solo se puede acceder localmente.
- Ninguna: Un problema reportado sin impacto de seguridad confirmado
Descarga una copia de la guía de usuario completa del sistema de puntuación CVSS.
¿Cómo encuentro una puntuación CVSS para un registro CVE?
Las puntuaciones CVSS se muestran directamente en la página de registro de cada CVE en la NVD, con soporte para puntuaciones v3.x y v4.0 donde estén disponibles. Tenga en cuenta que a medida que la cobertura de enriquecimiento de la NVD se reduce, las puntuaciones pueden faltar o basarse únicamente en la evaluación del remitente en lugar de un análisis independiente. La base de datos de vulnerabilidades de Aikido es una referencia cruzada útil, que se nutre de múltiples fuentes en lugar de solo la NVD.
¿Qué es una CWE?
Common Weakness Enumeration (CWE) es una lista desarrollada por la comunidad de debilidades comunes de software y hardware, mantenida por MITRE. El objetivo principal de CWE es detener las vulnerabilidades en su origen, eliminando los errores más comunes antes de que se entreguen los productos. También proporciona a los desarrolladores un marco compartido para discutir y abordar las amenazas de seguridad, con mapeos directos a bases de datos de vulnerabilidades como CVE.
La distinción clave: CWE describe la debilidad subyacente que conduce a una vulnerabilidad, mientras que CVE identifica una instancia específica de una vulnerabilidad. Piense en CWE como la categoría, CVE como la ocurrencia. Al igual que CVE, CWE tiene su propio sistema de puntuación de gravedad a través de CWSS y CWRAF.
Eche un vistazo a las 25 CWE más peligrosas para 2025.
Por qué la monitorización de CVE es cada vez más difícil
El problema del volumen es real: las entregas de CVE aumentaron un 263% entre 2020 y 2025, y las entregas en los primeros tres meses de 2026 son casi un tercio más altas que en el mismo período del año pasado. Ese crecimiento solo se está acelerando, y los registros de código abierto son una de las principales razones.
La IA ha reducido drásticamente la barrera para publicar paquetes de código abierto, y los registros lo están notando. El número de paquetes que llegan significa que una revisión significativa es cada vez más rara, y la infraestructura construida para rastrear y contextualizar las vulnerabilidades está bajo la misma presión.
La NVD fue construida para enriquecer cada CVE, añadiendo puntuaciones CVSS, listas de productos y contexto técnico que hacen que los registros CVE brutos sean realmente utilizables. NIST enriqueció casi 42.000 CVEs en 2025, lo que supone un 45% más que en cualquier año anterior. Pero ese aumento de productividad no fue suficiente para seguir el ritmo del creciente número de entregas. Como cubrimos anteriormente, NIST ha despriorizado ahora el enriquecimiento para la mayoría de los CVEs. Las herramientas en las que su equipo confía para detectar y puntuar vulnerabilidades están, para una parte creciente del universo CVE, operando con datos incompletos sin informarle.
Los límites de los CVE: lo que no se informa
El problema de la NVD es solo una parte de la historia. El problema más profundo es que los CVE solo cubren lo que se divulga, y mucho no lo hace.
En una sola semana de monitorización de Aikido Intel , 12 de 16 vulnerabilidades señaladas no tenían ningún CVE asignado. Tampoco eran casos extremos oscuros. Axios, con 56 millones de descargas semanales de npm, parcheó silenciosamente una vulnerabilidad de contaminación de prototipos que aún no tiene CVE. Apache ECharts parcheó un problema de cross-site scripting y nunca lo divulgó. De las vulnerabilidades que finalmente obtuvieron un CVE, el tiempo promedio desde el parche hasta la divulgación fue de 27 días, y algunas tardaron hasta nueve meses.
En lugar de depender de bases de datos centralizadas, Intel utiliza LLM entrenados a medida para escanear registros de cambios, notas de lanzamiento y mensajes de commit en millones de paquetes de código abierto, detectando parches relevantes para la seguridad antes de que obtengan un ID de CVE, y realizando referencias cruzadas con cinco bases de datos clave de vulnerabilidades para una cobertura más amplia. Si no existe una divulgación, los ingenieros de seguridad de Aikido validan y publican un aviso con un ID de vulnerabilidad de Aikido. En su primer año, el 67% de las vulnerabilidades señaladas por Intel nunca se habían divulgado a ninguna base de datos pública. Intel se integra directamente en la plataforma Aikido, por lo que cuando se encuentra una nueva vulnerabilidad, los usuarios son alertados automáticamente, incluso antes de que se le asigne un CVE.
¿Qué puedo hacer para mantener una postura de seguridad sólida?
No todos los CVE son su problema. Necesita un enfoque por capas. Las puntuaciones CVSS son un punto de partida útil, pero no tienen en cuenta su contexto específico. Una señal más accionable es el catálogo KEV de CISA: si un CVE aparece allí, está siendo explotado activamente en la naturaleza. Pero KEV cubre menos del 1% de todos los CVE y se inclina hacia las vulnerabilidades del perímetro de la red, por lo que está lejos de ser exhaustivo.
El Exploit Prediction Scoring System (EPSS) es otra capa útil. Predice la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días basándose en inteligencia de amenazas del mundo real, ayudándole a despriorizar la larga cola de CVEs que es poco probable que alguna vez sean explotados. Aikido admite la priorización basada en EPSS de forma nativa, degradando automáticamente los problemas de bajo riesgo para que su equipo pueda centrarse en lo que importa.
Antes de escalar cualquier vulnerabilidad, considere:
- Alcanzabilidad: La función vulnerable puede no ser alcanzable en su aplicación, una razón clave por la que el análisis de alcanzabilidad, y no las puntuaciones CVSS brutas, debería impulsar su priorización.
- Impacto en el negocio: El componente afectado puede no afectar a sistemas críticos, datos de clientes u operaciones centrales.
- Entorno único: Los sistemas personalizados o heredados pueden enfrentar perfiles de riesgo diferentes a los que asume la descripción estándar de CVE.
- Controles existentes: Puede que ya tenga defensas implementadas que neutralicen el riesgo.
- Restricciones de recursos: Arreglar todo no es realista. Priorice lo que es realmente explotable e impactante.
Obtén un escáner de vulnerabilidades
El mejor lugar para empezar es Aikido Security, una plataforma construida específicamente para eliminar el ruido que hace que la mayoría de los escáneres CVE sean agotadores de usar. Los escáneres tradicionales muestran cientos de alertas brutas, independientemente de si una vulnerabilidad es realmente explotable en su entorno. El análisis de alcanzabilidad de Aikido rastrea las rutas de ejecución a través de su código para determinar qué vulnerabilidades pueden ser realmente alcanzadas y activadas, filtrando problemas no alcanzables, falsos positivos y hallazgos irrelevantes, logrando a menudo hasta un 95% de reducción de ruido.
Adelántese a la CurVE
Los CVE describen vulnerabilidades que ya han sido identificadas y catalogadas. Para cuando se publica un CVE, los atacantes pueden haber tenido días o semanas para actuar sobre él. Y como vimos anteriormente, muchas vulnerabilidades nunca obtienen un CVE.
Mantenerse a la vanguardia significa más que parches reactivos. Mantenga las dependencias actualizadas y verifique su código contra el Top 10 OWASP 2025 y los puntos de referencia de cumplimiento de CIS, las herramientas estándar para identificar las debilidades más comunes y las configuraciones de seguridad incorrectas básicas. Puede verificar sus puntuaciones OWASP y CIS directamente en Aikido. Para las amenazas que aún no han sido catalogadas, Aikido Intel monitoriza más de 4.3 millones de paquetes de código abierto para detectar vulnerabilidades antes de que tengan un ID de CVE.
Vea qué CVEs afectan realmente a su base de código.
{{cta}}
