Introducción: Gestión de vulnerabilidades basada en riesgos según la Ley de Ciberresiliencia
Los equipos modernos ya saben que solucionar todas las vulnerabilidades es imposible. Lo que realmente importa es solucionar las correctas. Por eso, la gestión de vulnerabilidades basada en riesgos se ha convertido en el enfoque preferido para los equipos de DevSecOps. Sin embargo, en la Unión Europea, esto ya no es solo una buena práctica. La Ley de Resiliencia Cibernética introduce obligaciones legales concretas, especialmente cuando el software incluye problemas enumerados en la CISUn catálogo de vulnerabilidades explotadas conocidas.
En este nuevo contexto, la priorización de vulnerabilidades pasa de ser una opción de seguridad a un requisito de cumplimiento. Los equipos deben demostrar que comprenden qué vulnerabilidades se explotan activamente y cómo deciden qué corregir primero. Y el tiempo ya no es un concepto abstracto: Las obligaciones de información de la CRA sobre vulnerabilidades explotadas activamente e incidentes graves se aplican a partir del 11 de septiembre de 2026.y el conjunto completo de obligaciones principales entrará en vigor en diciembre de 2027. Cualquier modelo de priorización que utilice una organización hoy en día debe ser defendible conforme a ese requisito de presentación de informes en cuestión de semanas, no de trimestres.
Gestión de vulnerabilidades basada en riesgos y vulnerabilidades explotadas conocidas
La gestión de vulnerabilidades basada en riesgos se centra en la exposición real, no en la gravedad pura. En lugar de tratar todos los CVE por igual, los equipos priorizan en función de la explotación, la accesibilidad y el impacto.
Aquí es donde las vulnerabilidades explotadas conocidas juegan un papel central. Cuando aparece un CVE en el CISUn catálogo de vulnerabilidades explotadas conocidas confirma que los atacantes ya las utilizan en entornos reales. Esta señal tiene mucha más relevancia que una puntuación teórica.
Si quieres una explicación más profunda de qué son los KEV y cómo identificarlos, puedes leer nuestra publicación anterior. Vulnerabilidades conocidas explotadas: ¿Qué corregir primero?En este artículo, nos centramos en cómo los KEV se integran en los modelos de cumplimiento y priorización contemplados en la Ley de Resiliencia Cibernética.
Lo que realmente exige la Ley de Resiliencia Cibernética
La Ley de Resiliencia Cibernética es una normativa de la UE que establece obligaciones obligatorias de ciberseguridad para los productos con elementos digitales vendidos en la UE. Requiere que los proveedores gestionen las vulnerabilidades a lo largo del ciclo de vida del producto y eviten lanzar software con vulnerabilidades conocidas que hayan sido explotadas. Según la documentación oficial de la UELos fabricantes deben:
- Identificar y gestionar vulnerabilidades a lo largo del ciclo de vida del producto.
- Prevenir el envío de software con vulnerabilidades explotadas conocidas
- Notifique las vulnerabilidades explotadas activamente y los incidentes graves dentro de las 24 horas posteriores a su detección, una obligación de notificación que será de obligado cumplimiento a partir del 11 de septiembre de 2026.
- Mantener evidencia del manejo de vulnerabilidadescisiones
En otras palabras, una vez que aparece una vulnerabilidad en el CISIgnorar el Catálogo de Vulnerabilidades Explotadas Conocidas (KPI) genera riesgos tanto de seguridad como regulatorios, y a partir de septiembre de 2026, ese riesgo viene con un plazo para su notificación.
¿Qué es la Ley de Resiliencia Cibernética (CRA)?
El Ley de Resiliencia Cibernética Es un reglamento de la UE que define los requisitos obligatorios de ciberseguridad para el software y los productos digitales vendidos en Europa. Exige a los proveedores que gestionen las vulnerabilidades a lo largo del ciclo de vida del producto y eviten lanzar software con... vulnerabilidades conocidas explotadas.
Lista de verificación de gestión de vulnerabilidades basada en riesgos de CRA Ready
Por qué los vehículos eléctricos son fundamentales para el cumplimiento de la CRA
El CISUn catálogo de vulnerabilidades explotadas conocidas (CVE, por sus siglas en inglés) enumera las CVE que los atacantes ya explotan en la práctica. En otras palabras, elimina la ambigüedad en la priorización.
En lugar de preguntarse "¿Podría explotarse esto?", los equipos ahora deben hacerse una pregunta mucho más directa: "¿Ya se está explotando esto y, aun así, lo estamos lanzando al mercado?".
Según la Ley de Ciberresiliencia, esta distinción tiene importancia legal. En consecuencia, las vulnerabilidades clave se convierten en el principal factor desencadenante de los acuerdos de nivel de servicio (SLA) de remediación y el bloqueo de versiones. En este contexto, la gestión de vulnerabilidades basada en riesgos se alinea naturalmente con las expectativas regulatorias.
Analizamos con mayor profundidad el aspecto de la notificación de incidentes en una sesión conjunta con Nariman Aga-Tagiyev, arquitecto de ciberseguridad en SecureHabits.nl: 24 horas para informar: Cómo sobrevivir al plazo de notificación de la CRA. Describe el ciclo de vida de incidentes en tres etapas que la CRA espera que las organizaciones sigan, desde una preocupación reportada, pasando por una investigación, hasta un incidente confirmado que inicia el plazo de 24 horas para reportar.
CVSS, EPSS y KEV cumplen diferentes propósitos
Para priorizar correctamente, los equipos primero deben comprender qué representa realmente cada señal.
- CVSS muestra un impacto potencial
- EPS estima la probabilidad de explotación
- CISCatálogo de vulnerabilidades explotadas conocidas Confirma que la explotación ya ocurre
Cada métrica por separado puede ser engañosa. Sin embargo, al usarlas en conjunto, los equipos obtienen un contexto mucho más claro. Por ello, la combinación de estas señales constituye la base de una gestión eficaz de vulnerabilidades basada en riesgos.
Gestión de vulnerabilidades basada en riesgos en la práctica
En la práctica, un modelo de priorización basado en riesgos sigue un flujo claro y repetible.
- Detectar vulnerabilidades en el código y las dependencias
- Comparar coincidencias con el CISCatálogo de vulnerabilidades explotadas conocidas
- Evaluar la probabilidad de explotación mediante EPSS
- Verifique la accesibilidad en su aplicación o pipeline
- Aplicar reglas de remediación según la exposición y el rol del producto
Como resultado, los equipos dejan de tratar las listas de vulnerabilidades como registros estáticos y comienzan a tratarlas como soluciones de seguridad concretas.cisiones.
Diferentes modelos de priorización que utilizan los equipos hoy en día
No todos los equipos priorizan el riesgo de la misma manera. En generalVemos tres modelos comunes en entornos reales.
1. Modelo de gravedad primero
Los equipos solucionan problemas basándose únicamente en CVSS.
Este modelo es fácil de adoptar. Sin embargo, genera controversia y no cumple con las expectativas de la Ley de Ciberresiliencia.
2. Modelo impulsado por la verosimilitud
Los equipos confían en EPSS para predecir qué podrían explotar los atacantes a continuación.
Este enfoque mejora la concentración. Aun así, sigue pasando por alto vulnerabilidades que los atacantes ya explotan.
3. Modelo consciente de la explotación
Los equipos combinan EPSS con el CISUn catálogo de vulnerabilidades explotadas conocidas y contexto técnico.
Por el contrario, este modelo respalda mejor la gestión de vulnerabilidad basada en riesgos y se relaciona directamente con las obligaciones de la CRA.
Cómo Xygeni operacionaliza la priorización de CRA Ready
xygeni ayuda a los equipos a convertir la regulación en un flujo de trabajo diario. En lugar de depender únicamente de dashboards, Xygeni hace cumplir decisLas imágenes se ubican exactamente donde ocurren los cambios en el código. Como resultado, la priorización se vuelve automática y consistente.
Las capacidades clave incluyen:
- Correlación automática con la CISCatálogo de vulnerabilidades explotadas conocidas
- Puntuación de probabilidad de explotación basada en EPSS
- Análisis de alcanzabilidad para confirmar la exposición real
- Guardrails Ese bloque se fusiona o libera cuando los KEV afectan el código accesible
- Remediación automatizada mediante seguridad pull requests
- Registros de auditoría completos para demostrar el cumplimiento de la Ley de Resiliencia Cibernética
En resumen, los equipos no solo ven el riesgo, sino que actúan sobre él de forma repetible y auditable.
Ejemplo de desarrollo a desarrollo: KEV bloquea un lanzamiento
Imagine que una actualización de dependencia introduce un CVE.
- La vulnerabilidad aparece en la CISCatálogo de vulnerabilidades explotadas conocidas
- Xygeni lo detecta durante el pull request
- El análisis de accesibilidad confirma que la ruta del código se ejecuta
- Guardrails bloquear la fusión automáticamente
- El bot propone una actualización segura y ejecuta pruebas.
El desarrollador resuelve el problema en el mismo flujo de trabajo. La versión se mantiene conforme. No se requieren reuniones.
En otras palabras, se trata de una gestión de vulnerabilidad basada en riesgos aplicada exactamente donde los desarrolladores ya trabajan.
Por qué esto es importante más allá del cumplimiento
Aunque la Ley de Resiliencia Cibernética desencadenó este cambio, los beneficios van más allá. Los equipos que priorizan el uso de KEV, EPSS y contexto:
- Reducir la fatiga por alerta
- Acortar el tiempo de remediación
- Evite los parches de emergencia
- Envíe software más seguro con confianza
En general, el cumplimiento se convierte en el resultado natural de implementar la seguridad de la manera correcta.
Reflexiones finales: La CRA hace obligatoria la gestión basada en riesgos
La Ley de Resiliencia Cibernética formaliza lo que los equipos de seguridad ya aprendieron a base de experiencia. No todas las vulnerabilidades son igual de importantes.
El CISUn catálogo de vulnerabilidades explotadas conocidas define qué vulnerabilidades utilizan los atacantes actualmente. EPSS predice qué vulnerabilidades utilizarán próximamente. El contexto muestra si le afecta.
En conjunto, conforman la gestión moderna de vulnerabilidades basada en riesgos, y a partir del 11 de septiembre de 2026, dejará de ser opcional. Los equipos que ya pueden responder a la pregunta "¿se ha explotado esta vulnerabilidad y, aun así, la vamos a distribuir?" cumplirán con el plazo de notificación de la CRA sin problemas. Los equipos que no pueden hacerlo están comprobando lo cortas que son realmente 24 horas.
Xygeni ayuda a los equipos a aplicar este modelo de forma continua, automática y de una manera que los desarrolladores realmente acepten.
Sobre la autora
Escrito por Fátima Said, Gerente de Marketing de Contenidos especializado en Seguridad de Aplicaciones en Seguridad Xygeni.
Fátima crea contenido sobre seguridad de aplicaciones (AppSec) fácil de usar para desarrolladores y basado en investigaciones. ASPMy DevSecOps. Traduce conceptos técnicos complejos en ideas claras y prácticas que conectan la innovación en ciberseguridad con el impacto en el negocio.
