Introducción: Gestión de vulnerabilidades basada en riesgos según la Ley de Ciberresiliencia
Los equipos modernos ya saben que es imposible corregir todas las vulnerabilidades. Lo que realmente importa es corregir las correctas. Por eso 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. Ley de Resiliencia Cibernética introduce obligaciones legales concretas, especialmente cuando el software incluye cuestiones enumeradas en el CISCatálogo de vulnerabilidades explotadas conocidas.
En este nuevo contexto, la priorización de vulnerabilidades deja de ser una decisión de seguridad para convertirse en un requisito de cumplimiento. Los equipos deben demostrar que comprenden qué vulnerabilidades se explotan activamente y cómo deciden qué solucionar primero.
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 vulnerabilidades conocidas explotadas desempeñan un papel central. Cuando aparece una CVE en el CISCatálogo de vulnerabilidades explotadas conocidasEsto confirma que los atacantes ya lo utilizan en entornos reales. Esta señal tiene mucho más peso 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 encajan en los modelos de cumplimiento y priorización bajo el Ley de Resiliencia Cibernética.
Lo que realmente exige la Ley de Resiliencia Cibernética
El Ley de Resiliencia Cibernética Establece obligaciones de ciberseguridad obligatorias para los productos con componentes digitales vendidos en la UE. Según la documentación oficial de la UE:
- https://www.european-cyber-resilience-act.com/
- https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Los fabricantes deben:
- Identificar y gestionar vulnerabilidades a lo largo del ciclo de vida del producto.
- Prevenir el envío de software con vulnerabilidades conocidas explotadas
- Aplicar una remediación oportuna una vez que se conozca la explotación
- Mantener evidencia del manejo de vulnerabilidadescisiones
En otras palabras, una vez que aparece una vulnerabilidad en el CISCatálogo de vulnerabilidades explotadas conocidas, ignorarlo crea tanto el riesgo de seguridad como el riesgo regulatorio.
¿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 priorización de vulnerabilidades de CRA Ready
| Requisito | Lo que espera la CRA | Mejores prácticas para equipos |
|---|---|---|
| Conciencia de explotación | Prevenir el envío de software con vulnerabilidades explotadas conocidas | Coincidir automáticamente los hallazgos con los CISCatálogo de vulnerabilidades explotadas conocidas |
| Priorización basada en riesgos | Centrarse en las vulnerabilidades que crean un riesgo real de seguridad | Combine KEV, EPSS, accesibilidad y exposición de activos |
| Remediación oportuna | Aplicar correcciones sin demoras irrazonables una vez que se conozca la explotación | Defina acuerdos de nivel de servicio (SLA) de reparación inmediata para KEV alcanzables y aplíquelos en CI/CD |
| Monitoreo continuo | Manejar las vulnerabilidades durante todo el ciclo de vida del producto | Ejecute exploraciones continuas en el código, las dependencias y pipelines |
| Controles de liberación | Evite lanzar productos con fallas explotadas activamente | Fusiones o implementaciones de bloques cuando los KEV afectan el código accesible |
| Decistrazabilidad de iones | Demuestre cómo la vulnerabilidadcisSe hicieron iones | Mantener registros de auditoría para acciones de detección, priorización y remediación. |
| Integración con desarrolladores | Las medidas de seguridad no deben interrumpir los flujos de trabajo de desarrollo | Priorización de superficies directamente en pull requests y CI pipelines |
| Responsabilidad del ciclo de vida | Mantener la seguridad después de la liberación | Seguimiento de los cambios de KEV y EPSS para las versiones enviadas |
Por qué los vehículos eléctricos son fundamentales para el cumplimiento de la CRA
El CISCatálogo de vulnerabilidades explotadas conocidas Enumera los CVE que los atacantes ya explotan. En otras palabras, elimina la ambigüedad en la priorización.
En lugar de preguntar "¿Podría esto explotarse?", los equipos ahora deben hacer una pregunta mucho más directa:
“¿Esto ya se está explotando y lo estamos enviando de todos modos?”
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.
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.
Más bien que confiando sólo en dashboards, Xygeni hace cumplir decisiones exactamente donde ocurren los cambios de código. Como resultadoLa 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 Ley de Resiliencia Cibernética el cumplimiento
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 las opciones de fondo Ley de Resiliencia Cibernética Desencadenó este cambio y los beneficios fueron aún mayores.
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
El Ley de Resiliencia Cibernética Formaliza lo que los equipos de seguridad ya aprendieron a base de esfuerzo. No todas las vulnerabilidades son igualmente importantes.
El CISCatálogo de vulnerabilidades explotadas conocidas Define lo que usan los atacantes hoy. EPSS predice lo que usarán próximamente. El contexto muestra si te afecta.
Juntos forman la modernidad. gestión de vulnerabilidades basada en riesgos.
Xygeni ayuda a los equipos a aplicar este modelo de forma continua, automática y de una manera que los desarrolladores realmente acepten.
Sobre el Autor
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.
