La Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) exige a los fabricantes remediar las vulnerabilidades "sin demora" (Anexo I Parte II letra 2)) y notificar las que están siendo activamente explotadas en un plazo de 24 horas (Artículo 14(1)), pero no nombra ningún sistema de puntuación. CVSS, EPSS y el catálogo KEV de CISA son las herramientas del sector utilizadas para cumplir esas obligaciones. Esta página cubre qué mide cada una, cómo combinarlas en una priorización defendible y cómo la puntuación se conecta con la notificación del Artículo 14 y la divulgación coordinada de vulnerabilidades.
Resumen
- El CRA no exige ningún sistema de puntuación. La letra 2) del Anexo I Parte II exige la remediación "sin demora" 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 la señal binaria de "activamente explotada" que informa más directamente las decisiones de notificación del Artículo 14(1), aunque el Artículo 14(1) 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 del Artículo 14 son factuales, no se basan en puntuaciones. La explotación activa y el incidente grave se determinan conforme a las definiciones legales, siendo la puntuación una evidencia de apoyo.
Los cuatro números que enmarcan las decisiones de gravedad del CRA: gravedad inherente, probabilidad de explotación, el reloj de notificación y el techo de sanciones.
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 nombrado. El lenguaje operativo relevante está en el Anexo I Parte II, que enumera los requisitos de gestión de vulnerabilidades que todo fabricante debe cumplir durante el periodo de soporte:
- La letra 2) exige a los fabricantes "gestionar y remediar las vulnerabilidades sin demora, incluso proporcionando actualizaciones de seguridad".
- La letra 4) exige que, una vez disponible una actualización de seguridad, los fabricantes compartan información sobre la vulnerabilidad corregida "incluyendo una descripción de las vulnerabilidades, información que permita a los usuarios identificar el producto con elementos digitales afectado, los impactos de las vulnerabilidades, su gravedad e información clara y accesible que ayude a los usuarios a remediarlas".
El Artículo 13(8) enmarca estas obligaciones bajo un deber de gestión "eficaz" durante todo el periodo de soporte. La expresión "sin demora" de la letra 2) del Anexo I Parte II y "sin demora injustificada" del Artículo 14 establecen el estándar temporal. Ninguna de las dos expresiones equivale a un número fijo de días. Ambas están sujetas a la interpretación de las autoridades de vigilancia del mercado y, en última instancia, de 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 del Anexo I Parte II, véase gestión de vulnerabilidades. Para las cadencias de notificación del Artículo 14, 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 tiene tres tipos de puntuación:
Captura las características de la vulnerabilidad que no cambian con el tiempo ni entre despliegues: vector de ataque, complejidad, privilegios requeridos, interacción del usuario, alcance e impacto sobre la confidencialidad, la integridad y la disponibilidad. Es lo que publican la mayoría de las entradas CVE y lo que la gente entiende por "la puntuación CVSS".
Ajusta la puntuación base en función de factores variables en el tiempo: madurez del código de explotación, nivel de remediación y confianza en el informe. Raramente se publica en las entradas CVE públicas.
Ajusta la puntuación base según el contexto de despliegue propio: criticidad del activo, controles compensatorios e impacto real en el entorno particular. Esta es la puntuación que un fabricante debería calcular para su propio producto.
CVSS v4.0 fue publicado por FIRST en noviembre de 2023. Refina v3.1 con métricas de requisitos de ataque más precisas y métricas suplementarias de seguridad, automatización, recuperación y densidad de valor. La adopción es gradual: la mayoría de los 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 un CVE sea explotado en la práctica 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, telemetría de explotación 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 superar 0.5 en cuestión de días.
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 binaria de "¿se está explotando activamente este CVE?". Un CVE está en el catálogo o no lo está. CISA añade un CVE cuando dispone de evidencia fiable de explotación activa contra cualquier objetivo.
KEV es una fuente del gobierno estadounidense, pero es el catálogo público más autoritativo de explotación confirmada disponible para los defensores que no forman parte de la comunidad de inteligencia. Los fabricantes de la UE lo utilizan ampliamente porque actualmente no existe ningún catálogo equivalente de ENISA.
A efectos del Artículo 14(1), la inclusión en KEV es una señal sólida de que una vulnerabilidad está "activamente explotada" en el sentido del reglamento. No es la única señal: el Artículo 14(1) es más amplio y se activa ante 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 que está siendo explotada contra los clientes propios pero que todavía no está en KEV sigue activando el Artículo 14(1). La determinación del Artículo 14(1) es factual, no basada en listas.
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 | CVSS Crítico (9.0+) Y (incluido en KEV O EPSS > 0.5) | Días, no semanas | Candidato a notificación del Artículo 14(1) si la explotación afecta al propio 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 conforme a la letra 2) del Anexo I Parte II con documentación |
| 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 las autoridades de vigilancia del mercado una base documentada y repetible para las decisiones de remediación que examinarán cuando una vulnerabilidad grave se haga pública. Las autoridades no aceptarán "parcheamos cuando pudimos" como defensa de la letra 2) del Anexo I Parte II; sí aceptarán "nuestra política clasifica cada CVE en la recepción, este CVE cayó en la banda Alta, lo publicamos dentro del SLA de 30 días, aquí están las marcas de tiempo".
Correspondencia entre gravedad y activadores de notificación del Artículo 14
El Artículo 14 se divide en dos flujos con los mismos relojes de 24 horas y 72 horas pero con plazos de informe final distintos:
- Vulnerabilidad activamente explotada (Artículo 14(1) y 14(2)). Aviso temprano de 24 horas, notificación de vulnerabilidad de 72 horas, informe final de 14 días desde que una medida correctora o paliativa esté disponible.
- Incidente grave (Artículo 14(3) y 14(4)). 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: un actor malicioso ha utilizado la vulnerabilidad contra el propio producto. El Artículo 14(5) define un "incidente grave" como aquel que "afecta negativamente o es capaz de afectar negativamente a la capacidad de un producto con elementos digitales para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes", o que "ha dado lugar o es capaz de dar lugar a la introducción o ejecución de código malicioso en un producto con elementos digitales o en los sistemas de red e información de un usuario".
CVSS y EPSS apoyan la determinación. Un CVE Crítico según CVSS con EPSS > 0.9 y presencia en KEV sugiere con fuerza el ámbito del Artículo 14(1) una vez que existe evidencia de que la explotación afecta al propio producto. No reemplazan la determinación. El reloj de 24 horas comienza 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 del Artículo 14, véase notificación de vulnerabilidades. Para el canal de recepción 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. Véase SBOM para la mecánica de mapeo subyacente.
- 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, cuando KEV añada uno de los propios CVE, o cuando un cliente reporte 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 de "sin demora" de la letra 2) del Anexo I Parte II.
- 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 del Artículo 14. El Artículo 14(1) se activa ante 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 letra 4) del Anexo I Parte II exige comunicar la "gravedad" al divulgar 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 que produzca resultados operativos equivalentes es admisible 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" de la letra 2) del Anexo I Parte II 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 del Artículo 14?
No cambia el momento en que comienza el reloj. El reloj comienza cuando el fabricante tiene conocimiento de la explotación activa, 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" de la letra 2) del Anexo I Parte II. El estándar del sector de CVSS más EPSS más KEV es la vía de menor resistencia porque cualquier autoridad de vigilancia del mercado lo reconocerá.
¿Sanciona el CRA una puntuación de gravedad incorrecta?
El CRA sanciona el incumplimiento de la gestión eficaz de vulnerabilidades (Anexo I Parte II) y el incumplimiento de la notificación conforme al Artículo 14. Una política de puntuación defendible con aplicación documentada es lo que protege al fabricante. Una puntuación individual incorrecta no es una infracción; un proceso ausente o incoherente sí lo es.
¿Debemos usar CVSS v3.1 o v4.0?
Ambas, donde estén disponibles. CVSS v4.0 fue publicado por FIRST en noviembre de 2023 y refina v3.1 con métricas de requisitos de ataque más precisas y métricas suplementarias de seguridad, automatización, recuperación y densidad de valor. La adopción es gradual: la mayoría de los feeds públicos de CVE siguen publicando v3.1 y el soporte de herramientas para v4.0 es desigual. 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.