Un número todavía no es un riesgo.

Qué es realmente una CVE

CVE son las siglas de Common Vulnerabilities and Exposures. Un número como CVE-2026-12345 es un identificador y nada más: dice que una vulnerabilidad se ha notificado y catalogado. No dice si el producto funciona en su entorno, si es accesible, si se está explotando ni qué ocurre si se explota.

Justo ahí fallan la mayoría de los procesos de vulnerabilidades. Producen listas en lugar de decisiones. Una lista con 4.000 hallazgos abiertos no es evidencia de una gestión de vulnerabilidades que funcione: es la evidencia de que no existe ninguna.

Las cuatro magnitudes que solo juntas dicen algo

1. 1
   CVSS — cuán grave seríaEl valor de 0 a 10 describe la gravedad técnica en condiciones de laboratorio. Es independiente de su entorno y se mantiene igual durante años. Por sí solo no sirve para priorizar: hay muchas más vulnerabilidades con CVSS 9 que capacidad para cerrarlas todas a la vez.
2. 2
   EPSS — cuán probable esEl Exploit Prediction Scoring System estima la probabilidad de que una vulnerabilidad se explote realmente en los próximos 30 días. El valor cambia a diario. La gran mayoría de las CVE nunca se explotan: EPSS es lo que hace visible a la pequeña minoría.
3. 3
   KEV — ¿ya se está explotando?El catálogo de vulnerabilidades explotadas conocidas recoge lo que está demostradamente bajo ataque. Si una vulnerabilidad figura ahí y funciona en su entorno, la discusión sobre prioridades ha terminado.
4. 4
   Su entorno — ¿le afecta siquiera?La magnitud que ningún servicio externo conoce: si el producto funciona en su entorno, en qué versión, accesible desde fuera o en la red interna, y qué datos hay detrás. Sin un inventario de sus sistemas, toda evaluación de vulnerabilidades es una suposición.

Qué exigen los marcos

La gestión de vulnerabilidades aparece en todos los marcos principales, con distinto grado de exigencia y distinta evidencia.

• ISO/IEC 27001:2022, anexo A 8.8 — debe obtenerse información sobre las vulnerabilidades técnicas de los sistemas en uso, evaluarse la exposición y adoptarse las medidas adecuadas. La evidencia es el camino de decisión documentado, no la lista del escáner.
• NIS2 / § 30 BSIG, medida 5 — seguridad en la adquisición, el desarrollo y el mantenimiento, incluyendo expresamente el tratamiento y la divulgación de vulnerabilidades. Lo que se exige es un procedimiento, no una herramienta.
• DORA, gestión del riesgo de TIC — detección de actividades anómalas y vulnerabilidades, además de un programa de pruebas que incluya evaluaciones de vulnerabilidades y escaneos.
• § 75b SGB V, anexos 1 a 5 — sistemas operativos y aplicaciones actualizados y aplicación de parches de seguridad, escalonados según el tamaño de la consulta.

Un procedimiento que aguanta en la auditoría

Cuatro pasos que juntos producen la evidencia que un auditor quiere ver.

1. 1
   Saber qué operaUn inventario mantenido de sistemas, versiones y responsables. Sin él, todo lo demás es entretenimiento. Es lo primero que pide el auditor.
2. 2
   Suscribirse a las fuentes en lugar de buscarAvisos exactamente de los productos que usted utiliza, no el flujo completo de todas las publicaciones. Quien lo lee todo no lee nada.
3. 3
   Evaluar con plazo, no con intuiciónDefina de antemano qué combinación de gravedad, explotabilidad y accesibilidad dispara qué plazo. Esa definición es en sí misma una evidencia, y le protege el día que un plazo se rompe.
4. 4
   Justificar las excepciones y ponerles fechaLo que no se cierra necesita una justificación, una medida compensatoria y una fecha de revisión. Una excepción sin plazo es una no conformidad en la auditoría.

Avisos de vulnerabilidades

Seguimos los avisos de todos modos y los clasificamos: qué es relevante, a quién afecta y qué hay que hacer. Díganos si desea recibir esa clasificación. El catálogo en sí es de acceso público en cvedetails.com.