Qué es un CVE: definición, cómo funciona y por qué importa

Un CVE (Common Vulnerabilities and Exposures) es un identificador único, público y permanente que se asigna a cada vulnerabilidad de seguridad documentada en software o hardware utilizado en el mundo real. Sirve para que cualquier fabricante, investigador, equipo defensivo o auditor pueda referirse exactamente al mismo fallo (CVE-2025-40652) sin ambigüedad, en cualquier parte del mundo y en cualquier herramienta. Es la columna vertebral del sistema global de gestión de vulnerabilidades: si una vulnerabilidad no tiene CVE, en la práctica no existe para los sistemas automatizados de detección, parcheo y compliance.

Esta guía explica qué es un CVE, cómo se asigna, en qué se diferencia de CVSS, CWE y EPSS, dónde se publica oficialmente y cómo afecta a la operativa diaria de cualquier empresa.

Qué es un CVE: definición técnica

Un CVE es un registro público en una base de datos centralizada que identifica de forma única una vulnerabilidad concreta en un producto concreto. El sistema CVE lo coordina MITRE Corporation desde 1999 con financiación del Department of Homeland Security estadounidense, y a día de hoy contiene cientos de miles de identificadores acumulados.

La estructura del identificador es transparente:

• CVE-2025-40652 significa: año de asignación 2025, número secuencial 40652.
• El número no se reutiliza nunca. Si una entrada se rechaza después, queda marcada como REJECTED pero el ID se quema.
• No todos los CVE asignados se publican: algunos quedan en estado RESERVED mientras el fabricante prepara el parche y se hace público al divulgarse.

Cada entrada CVE incluye al menos: descripción técnica, producto y versión afectados, fechas de publicación y modificación, referencias a fuentes oficiales (advisory del fabricante, NVD, INCIBE-CERT, GHSA), y clasificación de tipo de fallo (CWE).

Lo que hace útil al CVE no es la tecnología (es básicamente una base de datos) sino el acuerdo global: todos los actores del ecosistema lo aceptan como referencia común, desde el fabricante de software hasta el SIEM que detecta el ataque, pasando por la herramienta de gestión de vulnerabilidades, el WAF, el feed de threat intelligence y los marcos de compliance.

Cómo se asigna un CVE: el rol de los CNAs

Una vulnerabilidad recibe CVE cuando una entidad acreditada como CNA (CVE Numbering Authority) se lo asigna. MITRE delega esta autoridad en cientos de organizaciones: fabricantes (Microsoft, Cisco, Red Hat, Oracle), CERTs nacionales (CISA, INCIBE-CERT, JPCERT/CC), proveedores cloud (AWS, Azure, Google), bug bounty platforms (HackerOne) y algunos researchers independientes con credenciales reconocidas.

El flujo típico:

1. Un investigador encuentra un fallo en un producto. Puede ser interno del fabricante, externo independiente o externo bajo programa de bug bounty.
2. Se reporta al fabricante siguiendo divulgación responsable.
3. El CNA correspondiente reserva un CVE (estado RESERVED). Si el fabricante es CNA, lo hace él mismo. Si no, se solicita al CNA paraguas o a MITRE directamente.
4. El fabricante desarrolla y publica el parche dentro del plazo acordado (típicamente 90 días desde el reporte).
5. El CVE se publica con descripción, scoring CVSS y referencias al advisory.
6. NVD enriquece la entrada con análisis adicional: vector CVSS calculado por NIST, mapeo CWE, referencias adicionales.

En España, INCIBE-CERT actúa como CNA paraguas para investigadores y fabricantes que no tienen acceso directo a un CNA propio. Por eso varias de nuestras propias advisories (por ejemplo CVE-2025-40652 y CVE-2023-3512) tienen identificador asignado vía INCIBE-CERT, además del registro paralelo en NVD.

Dónde vive un CVE: NVD, GHSA, INCIBE-CERT y los demás

Una entrada CVE en sí misma vive en el repositorio que mantiene MITRE en cve.org. Pero la mayoría del trabajo operativo se hace contra fuentes derivadas que enriquecen la información:

• NVD (National Vulnerability Database). Operada por NIST. Añade scoring CVSS oficial, mapeo CWE, métricas de impacto y referencias adicionales. Es la fuente que la mayoría de herramientas comerciales consume.
• GitHub Security Advisories (GHSA). Especializada en software open source. Cada GHSA suele tener un CVE asociado y enlaza paquetes afectados (npm, PyPI, RubyGems, Maven).
• INCIBE-CERT. El CERT español. Publica avisos en castellano, mapea CVEs internacionales a productos afectados en España y opera como CNA para advisories descubiertos por equipos españoles.
• CISA Known Exploited Vulnerabilities (KEV) Catalog. Subset crítico: CVEs que CISA ha confirmado están siendo explotados activamente. Es el feed que más vale la pena seguir si tienes que priorizar parches.
• Vendor advisories. Cada fabricante (Microsoft Security Response Center, Red Hat Security Advisories, Cisco PSIRT, AWS Security Bulletins) publica sus propios bulletins enlazando los CVEs.
• Feeds especializados. Tenable, Rapid7, Qualys, CVE Details, Vulners. Comerciales o gratuitos según el caso.

Para una empresa, lo razonable es automatizar consumo de NVD + KEV + advisories de fabricantes que usas y dejar el resto para investigación puntual.

CVE, CVSS, CWE y EPSS: aclarando la sopa de siglas

Estos cuatro acrónimos se mezclan habitualmente y no son lo mismo:

• CVE es el identificador. Sólo eso. CVE-2025-40652.
• CVSS (Common Vulnerability Scoring System) es la puntuación de severidad. La versión vigente es CVSS v4.0; muchos CVEs todavía llevan v3.1. Da un score 0-10 y un vector con métricas detalladas (AV:N/AC:L/PR:N/UI:N/...). No mide probabilidad de explotación, sólo impacto teórico.
• CWE (Common Weakness Enumeration) es el tipo de fallo subyacente. CWE-79 es Cross-Site Scripting, CWE-89 SQL Injection, CWE-22 Path Traversal. Un mismo CWE puede asociarse a miles de CVEs. Sirve para entender el patrón.
• EPSS (Exploit Prediction Scoring System) es la probabilidad estimada de que ese CVE concreto sea explotado en los próximos 30 días, según un modelo estadístico mantenido por FIRST. Va de 0% a 100%. Es la métrica que más vale la pena en priorización porque el CVSS no distingue entre un crítico que se explota y un crítico que nadie usará.

La regla práctica: usar CVSS para entender impacto teórico, EPSS para priorizar parcheo real y KEV de CISA para urgencia inmediata (lo que ya se está explotando).

Cómo leer una entrada CVE: ejemplo práctico

Tomemos CVE-2025-40652 (uno de los advisories firmados por nuestro equipo). Los campos que importan operativamente:

1. Descripción: "Stored XSS en CoverManager que permite ejecutar JavaScript en la sesión del usuario víctima."
2. Producto afectado: CoverManager, versiones anteriores al parche del fabricante.
3. CVSS v4.0: 5.3 MEDIUM, vector AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N. Atacante remoto, sin autenticación, con interacción pasiva del usuario.
4. CWE: CWE-79 (XSS).
5. Estado: parcheada por el fabricante.
6. Referencias: NVD, INCIBE-CERT, advisory técnico del descubridor.

Con eso, un equipo defensivo decide en 60 segundos: ¿afecta a algún producto que usamos? ¿qué versión tenemos? ¿está parcheada? ¿hay mitigación temporal mientras se actualiza?

Por qué los CVEs importan a tu empresa

Tres razones operativas que afectan a cualquier organización:

1. Compliance. NIS2, DORA, ENS, ISO 27001 y PCI DSS exigen un proceso documentado de gestión de vulnerabilidades. Sin tracking de CVEs, no hay proceso. El auditor pedirá evidencia (informe mensual de CVEs aplicables, cobertura de parches, justificación de los pendientes).
2. Threat intelligence operativa. Los CVEs publicados son la señal pública de "esto que tienes en producción acaba de volverse explotable". Sin un proceso que vigile el flujo, dependes de que un atacante te lo recuerde.
3. Comunicación con proveedores y clientes. Cuando un cliente B2B te pregunta "¿estáis afectados por CVE-XXXX-YYYY?", la respuesta debe ser inmediata y verificable. Esa capacidad de respuesta forma parte de la confianza comercial, no sólo de la seguridad técnica.

Cómo trackear CVEs que afectan a tu stack

El proceso mínimo viable que cualquier empresa con CISO debería tener:

1. Inventario de software y versiones. Si no sabes qué tienes desplegado, no puedes saber si un CVE te afecta. Es el cero del cero. Lo cubren los CMDB y los SBOM (Software Bill of Materials).
2. Suscripción a feeds. NVD JSON feed (gratis), CISA KEV (gratis), advisories de los fabricantes que usas. Para mid-market y enterprise, una herramienta de vulnerability management comercial (Tenable, Rapid7, Qualys, Snyk para dependencias) automatiza el matching.
3. Triage y priorización. CVSS te dice gravedad, EPSS te dice probabilidad real de explotación, KEV te dice si está pasando ahora. Combina las tres.
4. SLA de remediación documentado. Críticos en CISA KEV: 24-72 horas. Críticos sin explotación activa: 7-15 días. Resto: 30-90 días según severidad. Lo importante es tenerlo escrito y cumplirlo.
5. Integración con SIEM y EDR. El SIEM y el EDR modernos correlacionan CVEs detectados en activos contra el feed de KEV para alertar cuando un activo vulnerable empieza a recibir tráfico anómalo.

Errores comunes en la gestión de CVEs

Cuatro patrones que rompen procesos por lo demás bien intencionados:

1. Parchear sólo los críticos. Funciona hasta que un atacante encadena medio + medio + bajo y consigue lo que un crítico le habría dado. La gestión por severidad aislada subestima la cadena de ataque.
2. Ignorar dependencias indirectas. Tu app no usa Log4Shell directamente, pero la librería X que sí usas, sí. Sin SBOM o herramienta SCA, no lo ves.
3. Saltarse el triage por urgencia constante. Si todo es crítico, nada es crítico. Sin método para distinguir, el equipo se quema.
4. Confiar sólo en NVD. NVD a veces tarda semanas en enriquecer un CVE recién publicado. Para casos urgentes, complementar con feeds del fabricante directamente y con KEV de CISA.

Preguntas frecuentes sobre CVE

¿Quién decide qué se asigna como CVE y qué no?

Lo decide el CNA correspondiente. Para fabricantes que son CNA propio (Microsoft, Cisco, Red Hat, etc.), lo deciden ellos según sus criterios. Para el resto, lo decide MITRE o el CNA paraguas. Los criterios oficiales requieren que el fallo afecte a un producto público, sea reproducible y tenga implicación de seguridad. Bugs sin impacto de seguridad o sólo en código interno no reciben CVE.

¿Cuánto se tarda en asignar un CVE?

Depende del CNA y la urgencia. Para vulnerabilidades reportadas a fabricantes establecidos (Microsoft, Apple, Google) el CVE suele asignarse en pocos días. Para fabricantes pequeños o vías indirectas vía CNA paraguas, puede llevar varias semanas. La publicación pública del CVE espera al parche o al fin del plazo de 90 días de divulgación responsable, lo que ocurra antes.

¿Qué diferencia hay entre CVE rejected y CVE en estado disputed?

REJECTED significa que el CVE se asignó pero después se determinó que no era una vulnerabilidad real (duplicado, no reproducible, sin impacto de seguridad). DISPUTED significa que el fabricante o un tercero cuestiona la naturaleza del fallo, pero la entrada sigue activa. Conviene revisar el estado antes de aplicar parches urgentes.

¿Es obligatorio publicar un CVE de cualquier vulnerabilidad encontrada?

No. Un investigador puede decidir reportar al fabricante sin solicitar CVE; un fabricante puede parchear sin asignar uno (aunque la práctica responsable es asignarlo para trazabilidad). Bugs internos no expuestos al público quedan fuera del sistema CVE. La inmensa mayoría de los bugs que afectan a un producto comercial sí terminan recibiendo CVE.

¿Cómo se comparten advisories sin un CVE oficial todavía?

Mientras el CVE está en estado RESERVED, los CNAs y fabricantes coordinan privadamente vía canales como PSIRT-to-PSIRT, mailing lists privadas y, en el ámbito europeo, EU-CSIRTs Network. Los detalles públicos sólo se publican cuando el parche está disponible y el CVE pasa a PUBLISHED.

¿Dónde busco si un CVE concreto me afecta?

Pasos en orden: (1) identificar producto y versión exacta en tu inventario; (2) consultar la entrada en cve.org o NVD; (3) revisar el advisory oficial del fabricante para versiones afectadas exactas (NVD a veces lo simplifica); (4) si el producto está en CISA KEV, prioridad máxima; (5) si tu herramienta de vulnerability management ya hizo matching, valida y aplica.

¿Y si encuentro yo una vulnerabilidad? ¿Cómo solicito CVE?

Tres caminos: (a) reportar al fabricante; si es CNA, lo asigna directamente. (b) Si el fabricante no es CNA, contactar al CNA paraguas natural (INCIBE-CERT en España, CISA en EEUU) o a MITRE directamente vía formulario. (c) Si tu organización publica investigación regularmente, plantearos solicitar el estatus CNA propio. La divulgación responsable manda: nada se publica antes del parche.

Recursos relacionados

• Investigación en seguridad y advisories de Secra: los CVEs firmados por nuestro equipo, con detalle técnico de cada uno.
• Qué es un SOC: cómo el SOC integra el feed CVE en su operativa diaria.
• Qué es un SIEM: cómo el SIEM correlaciona CVEs con telemetría de los activos.
• Qué es un EDR: cómo el EDR usa el feed CVE para detectar explotación activa.
• Qué es un pentesting: cómo el pentesting valida si los parches realmente cierran el vector documentado.

Los CVEs en Secra

En Secra mantenemos un programa interno de research que ha publicado advisories en NVD e INCIBE-CERT (incluido CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB), siempre bajo divulgación responsable. Si tu organización quiere reforzar su gestión de vulnerabilidades con auditoría técnica externa o consumo gestionado de feeds CVE, escríbenos a través de contacto.