La Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) exige a los fabricantes clasificar vulnerabilidades, remediarlas a tiempo y notificar la explotación activa cuando tengan conocimiento de ella. El deber de notificación del Artículo 14 se aplica desde el 11 de septiembre de 2026; las obligaciones de gestión de vulnerabilidades, remediación y divulgación del Artículo 13 y el Anexo I se aplican desde el 11 de diciembre de 2027. El Reglamento no nombra CVSS, EPSS, KEV ni ningún otro sistema de puntuación. Esta página cubre qué mide cada señal, cómo combinarlas en una priorización defendible y cómo la puntuación apoya la notificación de vulnerabilidades y la divulgación coordinada de vulnerabilidades.
Resumen
- El CRA no exige ningún sistema de puntuación. Exige remediación oportuna, pero deja la medición operativa en manos de los fabricantes.
- CVSS mide la gravedad inherente en una escala de 0 a 10: características de la vulnerabilidad independientes de si se observa explotación en la práctica.
- EPSS mide la probabilidad de explotación en una escala de 0 a 1: probabilidad de explotación observada en los próximos 30 días, calculada por el FIRST EPSS Special Interest Group.
- CISA KEV es una señal binaria de explotación activa que puede informar decisiones de notificación, aunque el activador del CRA es más amplio que la inclusión en KEV.
- CVSS, EPSS y KEV combinados ofrecen una matriz de priorización defendible; ninguna señal por sí sola es suficiente.
- Los activadores de notificación son factuales, no se basan en puntuaciones. La explotación activa y los incidentes graves se determinan conforme a las definiciones legales, siendo la puntuación una evidencia de apoyo.
Las cuatro señales que enmarcan las decisiones de gravedad del CRA: gravedad inherente, probabilidad de explotación, reloj de notificación y la fecha en que el deber de notificación pasa a ser vinculante.
Qué dice el CRA sobre la puntuación
Lea el reglamento directamente y no encontrará ninguna mención a CVSS, EPSS ni a ningún otro sistema de puntuación. Las obligaciones operativas son más simples: el fabricante necesita un proceso de gestión de vulnerabilidades que funcione durante todo el periodo de soporte, remedie vulnerabilidades sin demora y publique información clara sobre la gravedad cuando haya una corrección disponible.
- Remediación. Abordar y remediar vulnerabilidades sin demora, también mediante actualizaciones de seguridad.
- Divulgación pública. Cuando haya una actualización de seguridad disponible, compartir una descripción de la vulnerabilidad corregida, los productos afectados, el impacto probable, la gravedad y una guía clara de remediación.
Estas expresiones fijan un estándar, no un número fijo de días. Las interpretan las autoridades de vigilancia del mercado y, en última instancia, los tribunales nacionales.
La puntuación es la forma en que los fabricantes demuestran esa interpretación en auditorías e investigaciones. Un fabricante que puede mostrar una política de gravedad documentada, un sistema de seguimiento que registra CVSS y EPSS en la recepción, un SLA vinculado a las bandas de gravedad y marcas de tiempo de remediación que respetan esos SLA tiene una posición defendible de «sin demora». Uno que no puede, no la tiene.
Para el régimen más amplio de gestión de vulnerabilidades, véase gestión de vulnerabilidades. Para las cadencias de notificación bajo el régimen de incidentes, véase notificación de vulnerabilidades.
CVSS: gravedad inherente
El Common Vulnerability Scoring System, mantenido por el FIRST CVSS Special Interest Group, puntúa una vulnerabilidad en una escala de 0.0 a 10.0. Es la puntuación de gravedad inherente dominante en el sector y la que publican la mayoría de las entradas CVE.
CVSS v3.1 tiene tres tipos de puntuación:
| Tipo de puntuación | Qué mide | Uso para el CRA |
|---|---|---|
| Puntuación base | Características inherentes de la vulnerabilidad: vector de ataque, complejidad, privilegios requeridos, interacción del usuario, alcance e impacto en confidencialidad, integridad y disponibilidad. | Úsela como línea base de recepción porque es la puntuación que publican la mayoría de las entradas CVE. |
| Puntuación temporal | Contexto público variable en el tiempo: madurez del código de explotación, nivel de remediación y confianza en el informe. | Úsela cuando esté disponible, pero no dependa de ella porque las entradas CVE públicas rara vez la incluyen. |
| Puntuación ambiental | Contexto de su producto: criticidad del activo, controles compensatorios, rutas de código alcanzables e impacto real del despliegue. | Úsela para documentar por qué el fabricante elevó, redujo o aplazó una prioridad de remediación. |
CVSS v4.0 fue publicado por FIRST el 1 de noviembre de 2023. Mantiene los grupos Base y Ambiental, reemplaza el grupo Temporal de v3.1 por un grupo Amenaza más estrecho centrado en la madurez de explotación, y añade un grupo Suplementario (que incluye seguridad, automatizabilidad, recuperación y densidad de valor) que registra contexto sin modificar la puntuación final. La adopción es gradual: muchos feeds de CVE siguen publicando v3.1 y el soporte de herramientas para v4.0 es desigual. Ingiera ambas versiones donde estén disponibles y no trate la transición como una rebasificación del trabajo atrasado.
CVSS por sí solo es insuficiente. La investigación empírica muestra de forma consistente que la mayoría de las vulnerabilidades calificadas como «alta» o «crítica» por CVSS nunca se observan siendo explotadas. Una cola basada únicamente en CVSS consume capacidad de ingeniería en riesgos teóricos mientras la explotación real queda sin atender.
EPSS: probabilidad de explotación
El Exploit Prediction Scoring System, también mantenido por FIRST a través de su EPSS SIG, predice la probabilidad de que se observe actividad de explotación contra un CVE en los próximos 30 días. EPSS publica una probabilidad entre 0 y 1 y una clasificación percentil respecto a todos los CVE.
EPSS se calcula mediante un modelo de aprendizaje automático que ingiere atributos de CVE (métricas CVSS, CWE, proveedor y producto afectado, antigüedad) y señales públicas (disponibilidad de PoC, actividad de explotación observada de socios colaboradores y menciones de inteligencia de amenazas). Las puntuaciones se actualizan a diario. Un CVE nuevo sin PoC público suele puntuar por debajo de 0.05; uno con un PoC funcional puede subir de forma apreciable, en función de las demás entradas del modelo.
EPSS por sí solo también es insuficiente. Una puntuación EPSS baja hoy no es garantía para mañana: cuando un investigador publica un exploit funcional, la puntuación cambia. EPSS debe reevaluarse de forma continua, no solo en el momento de la recepción.
CISA KEV: explotación confirmada
El catálogo Known Exploited Vulnerabilities, mantenido por la Agencia de Seguridad de Infraestructura y Ciberseguridad de los EE. UU., es una lista de vulnerabilidades con evidencia fiable de explotación activa confirmada. Un CVE está en el catálogo o no lo está. CISA añade un CVE cuando dispone de evidencia fiable de que la vulnerabilidad ha sido explotada contra un objetivo real.
KEV es una fuente del gobierno estadounidense. Los fabricantes de la UE lo utilizan ampliamente por su amplio soporte en herramientas. Desde el 13 de mayo de 2025, ENISA también gestiona la Base de Datos Europea de Vulnerabilidades (EUVD), que publica el estado de explotación y una vista dedicada de vulnerabilidades explotadas; trátela como una señal adicional de priorización de la UE junto a KEV. Ambas son independientes de la Plataforma Única de Notificación del CRA (Artículo 16), y ninguna es en sí misma el activador de notificación del Artículo 14.
Para el activador de aviso temprano, la inclusión en KEV es una señal sólida de que una vulnerabilidad puede estar «activamente explotada» en el sentido del reglamento. No es la única señal: el activador es más amplio y alcanza cualquier vulnerabilidad activamente explotada, incluidas las detectadas mediante informes de clientes, telemetría interna o inteligencia de amenazas que aún no ha llegado a CISA. Una vulnerabilidad explotada contra sus clientes pero todavía ausente de KEV puede seguir activando el deber. La determinación es factual, no basada en listas, y requiere evidencia fiable de explotación sin permiso.
Combinación de CVSS, EPSS y KEV en una matriz de priorización del CRA
Ninguna señal por sí sola es suficiente. El enfoque defendible consiste en combinar las tres y vincular los SLA de remediación a la banda combinada. El diagrama siguiente muestra el motivo: un CVSS de 9.8 sin explotación observada implica un riesgo real menor que un CVSS de 7 con EPSS de 0.95 y presencia en KEV, aunque el primero parezca peor en una cola basada únicamente en CVSS.
| Banda | Combinación de señales | SLA de remediación | Implicación del CRA |
|---|---|---|---|
| Emergencia | Incluido en KEV O explotación activa confirmada O (CVSS Crítico 9.0+ Y EPSS > 0.5) | Días, no semanas | Revisión urgente de notificación si la explotación puede afectar al producto |
| Alta | CVSS Alto (7.0-8.9) O EPSS > 0.5 | 30 días | La posición de «sin demora» está en riesgo por encima de los 30 días |
| Media | CVSS Medio (4.0-6.9), EPSS < 0.5, no incluido en KEV | 90 días | Defendible con documentación y marcas de tiempo |
| Baja | CVSS Bajo (< 4.0) | Siguiente ciclo regular de publicación | Documentar el aplazamiento en el registro de gestión de vulnerabilidades |
La matriz es la política del fabricante, no un requisito del CRA. Documentarla proporciona a una autoridad de vigilancia del mercado una base documentada y repetible para las decisiones de remediación que puede examinar cuando una vulnerabilidad grave se haga pública. Una política documentada que clasifica cada CVE en la recepción, registra la banda asignada y acredita el envío dentro del SLA correspondiente con marcas de tiempo es mucho más fácil de defender que «parcheamos cuando pudimos».
Nuestra valoración: una cola basada solo en CVSS se está convirtiendo en la señal de alerta en auditoría
Los apartados anteriores son mecánica operativa. El recuadro siguiente recoge nuestra lectura como profesionales del sector, no asesoramiento jurídico.
El Reglamento vigente no nombra ningún sistema de puntuación y no esperamos que lo haga. Pero la dirección es clara. Ahora que la EUVD de ENISA publica una vista de vulnerabilidades explotadas junto a CISA KEV, la evidencia consciente de la explotación es cada vez más difícil de ignorar para las autoridades: «priorizamos por CVSS y nos perdimos la que estaba siendo explotada» es una respuesta más débil cada trimestre. Esperamos que las autoridades de vigilancia del mercado y los CSIRT lean un proceso consciente de EPSS y KEV como la base mínima de un régimen de gestión de vulnerabilidades competente, no como una opción avanzada. Construye para donde se dirige la aplicación normativa, y estarás puntuando por probabilidad de explotación, no solo por gravedad.
Correspondencia entre gravedad y activadores de notificación
La notificación no se basa en puntuaciones. El régimen de notificación de incidentes se divide en dos flujos con los mismos relojes de 24 horas y 72 horas, pero con plazos de informe final distintos:
- Vulnerabilidad aprovechada activamente. Aviso temprano de 24 horas, notificación de vulnerabilidades de 72 horas, informe final a 14 días desde que esté disponible una medida correctora o paliativa.
- Incidente grave. Aviso temprano de 24 horas, notificación de incidente de 72 horas, informe final de 1 mes desde la notificación de 72 horas.
Ninguno de los activadores es un umbral de CVSS. «Activamente explotada» es una determinación factual: existe evidencia fiable de que un actor malicioso explotó la vulnerabilidad sin permiso. Un incidente grave es aquel que puede afectar a la disponibilidad, autenticidad, integridad o confidencialidad de los datos, o a la capacidad del producto para proteger datos o funciones sensibles o importantes, o que puede dar lugar a la introducción o ejecución de código malicioso en el producto o en los sistemas de información y redes de un usuario.
CVSS y EPSS apoyan la determinación. Una vulnerabilidad crítica según CVSS con EPSS > 0.9 y presencia en KEV debe activar una revisión urgente de notificación cuando exista evidencia de que la explotación puede afectar al producto. No reemplazan la determinación. El reloj de 24 horas se ancla en el momento en que el fabricante tiene conocimiento de la explotación activa, no en el momento en que la puntuación CVSS supera cualquier número.
Para la cadencia completa de notificación, véase notificación de vulnerabilidades. Para el canal de recepción aguas arriba que a menudo produce la primera señal de explotación, véase divulgación coordinada de vulnerabilidades.
Operacionalización de la puntuación en el proceso de vulnerabilidades
Un proceso de puntuación alineado con el CRA que funcione tiene seis componentes concretos:
- Ingerir CVSS en el momento del análisis. El pipeline de SBOM a CVE debe asociar puntuaciones base de CVSS a cada hallazgo en la primera detección.
- Actualizar EPSS a diario. Un proceso nocturno que repuntúe las vulnerabilidades abiertas es el mínimo.
- Vigilar CISA KEV. Suscribirse al feed de KEV y escalar automáticamente cualquier vulnerabilidad abierta que entre en el catálogo.
- Establecer SLA por banda en el sistema de seguimiento. Las bandas y los plazos deben ser legibles por máquina para que los elementos vencidos aparezcan sin triaje manual.
- Escalar ante cruces de umbral. Cuando EPSS supere 0.5 para un hallazgo abierto, reclasifícalo (Alta, o Emergencia si CVSS también es 9.0+). Cuando KEV añada uno de tus CVE, o un cliente notifique explotación activa, el elemento pasa automáticamente a la banda de Emergencia.
- Automatizar el mapeo de componentes SBOM a CVE. El mapeo manual se rompe a escala y es la fuente más habitual de vulnerabilidades omitidas en los hallazgos de auditoría.
La incorporación a la Plataforma Única de Notificación de ENISA es una línea de trabajo separada pero relacionada. Véase incorporación al SRP de ENISA.
Errores habituales
- Perseguir el CVSS-9 ignorando el EPSS-0.95. Una vulnerabilidad CVSS-7 con EPSS de 0.95 y un PoC público implica un riesgo real mayor que una vulnerabilidad CVSS-9.8 con EPSS de 0.01.
- Asumir que KEV es completo. KEV es el mejor catálogo público, pero va con retraso. La explotación activa contra los propios clientes puede preceder a la inclusión en KEV días o semanas.
- Tratar el CVSS como un plazo. Un CVSS Crítico no significa «parchear en 24 horas». Significa «revisar esto primero». El plazo proviene del SLA de la política, del EPSS, del estado en KEV y, en última instancia, del estándar esperado de remediación sin demora.
- No actualizar las puntuaciones EPSS. Una vulnerabilidad puntuada con EPSS de 0.02 en la recepción y que nunca se repuntúa permanecerá en la cola de baja prioridad mientras la explotación real crece fuera del campo de visión.
- Ignorar los modificadores ambientales de CVSS. Una puntuación base CVSS de 9.8 para un componente que el propio producto nunca instancia no es un 9.8 en el entorno particular. Documentar la puntuación ambiental y el razonamiento.
- Usar CVSS o EPSS como activador de notificación. El deber de notificación se activa por explotación activa factual. Una puntuación es evidencia de apoyo, no la determinación.
Preguntas frecuentes
¿Exige el CRA el uso de CVSS?
No. El CRA no nombra CVSS ni ningún otro sistema de puntuación. La obligación de divulgación exige comunicar la «gravedad» al publicar una vulnerabilidad corregida, pero no especifica la escala. CVSS es el estándar del sector y la escala más fácil de defender en auditoría. Una escala personalizada o alternativa puede funcionar si está documentada y se aplica de forma coherente.
¿Es obligatorio EPSS conforme al CRA?
No. EPSS no se menciona en el reglamento. Ayuda a demostrar el estándar de «sin demora» porque muestra que la priorización seguía la probabilidad de explotación real, no solo la gravedad inherente. Un fabricante que ignora la probabilidad de explotación y parchea exclusivamente por rango CVSS tendrá dificultades para justificar la remediación lenta de un hallazgo con EPSS alto a posteriori.
¿Cómo afecta la puntuación al reloj de 24 horas?
No cambia el momento en que comienza el reloj. El reloj comienza cuando el fabricante tiene conocimiento de una vulnerabilidad aprovechada activamente, independientemente del CVSS. La puntuación ayuda a clasificar qué señales entrantes alcanzan el umbral de conocimiento, pero una vez que la explotación está acreditada de forma creíble, el reloj corre aunque la puntuación CVSS no esté aún finalizada.
¿Podemos usar un sistema de puntuación personalizado?
Sí, siempre que pueda defenderse en auditoría. Un esquema que combine contexto interno del modelo de amenazas con señales externas es aceptable si está documentado, se aplica de forma coherente y produce resultados de remediación alineados con el estándar de «sin demora». El estándar del sector de CVSS más EPSS más KEV es la vía de menor resistencia porque está ampliamente reconocido.
¿Sanciona el CRA una puntuación de gravedad incorrecta?
No directamente. El riesgo de sanción está en incumplir los requisitos de gestión de vulnerabilidades o en no notificar la explotación activa. Una puntuación individual incorrecta no es automáticamente una infracción, pero un proceso de puntuación ausente o incoherente puede convertirse en evidencia de que la gestión de vulnerabilidades no fue eficaz.
¿Debemos usar CVSS v3.1 o v4.0?
Ambas, donde estén disponibles. CVSS v4.0 fue publicado por FIRST el 1 de noviembre de 2023. Mantiene los grupos Base y Ambiental, reemplaza el grupo Temporal por un grupo Amenaza más estrecho centrado en la madurez de explotación, y añade un grupo Suplementario (que incluye seguridad, automatizabilidad, recuperación y densidad de valor) que registra contexto sin modificar la puntuación. La adopción es gradual: muchos feeds públicos de CVE siguen publicando v3.1. Ingiera ambas señales donde la fuente las proporcione y no trate la transición de v3.1 a v4.0 como una rebasificación del trabajo atrasado.
¿Cuándo empiezan a aplicarse estas obligaciones de notificación?
El Artículo 14, que recoge las obligaciones de notificación descritas en esta página, se aplica desde el 11 de septiembre de 2026. Las obligaciones de gestión de vulnerabilidades, remediación y divulgación del CRA recogidas en el Artículo 13 y el Anexo I se aplican desde el 11 de diciembre de 2027, fecha en la que también entra en vigor la mayor parte del Reglamento. Construye el proceso de puntuación y preparación para la notificación ahora para que esté operativo antes de septiembre de 2026.
¿Qué se entiende por «tener conocimiento» a efectos del reloj de 24 horas?
El reloj de aviso temprano de 24 horas arranca cuando el fabricante tiene conocimiento de una vulnerabilidad aprovechada activamente. Eso significa conocimiento creíble de que un actor malicioso ha explotado el fallo contra un objetivo real, no un informe privado de vulnerabilidad ni una prueba de concepto funcional por sí solos. Una puntuación CVSS o EPSS no arranca el reloj; lo hace la determinación factual de explotación activa.
¿Cómo debemos usar la EUVD de ENISA junto a CISA KEV?
Desde el 13 de mayo de 2025, ENISA gestiona la Base de Datos Europea de Vulnerabilidades (EUVD), que publica el estado de explotación y una vista dedicada de vulnerabilidades explotadas. Úsala como señal de priorización junto a CISA KEV. Ninguno de los dos catálogos es el activador de notificación del Artículo 14, y ambos son independientes de la Plataforma Única de Notificación del CRA del Artículo 16.
¿Cambia VEX la gravedad o las obligaciones de notificación del CRA?
No. Un documento VEX (Vulnerability Exploitability eXchange) no modifica el activador de notificación ni la gravedad inherente de una vulnerabilidad. Es una forma legible por máquina de registrar si tu producto está realmente afectado por una vulnerabilidad conocida (afectado, no afectado, en investigación o corregido) junto al SBOM. Eso lo convierte en evidencia de apoyo sólida para una reducción de puntuación ambiental o un aplazamiento documentado.
¿Deberíamos usar SSVC en lugar de una matriz CVSS?
Puedes hacerlo. SSVC (Stakeholder-Specific Vulnerability Categorization), publicado por CISA con el SEI de Carnegie Mellon, es una alternativa de árbol de decisión que llega a una decisión de remediación (Track, Track*, Attend, Act) a partir de entradas como el estado de explotación, la exposición y el impacto en la misión. El CRA no lo exige. Es un marco reconocido y defendible si prefieres un árbol de decisión a la matriz CVSS + EPSS + KEV de esta página.