01El ciclo de vida: del inventario a la verificación
La gestión de vulnerabilidades es un proceso continuo, no un proyecto puntual. Comienza con un inventario completo de activos, porque solo los sistemas conocidos pueden analizarse – incluidos los recursos en la nube, los contenedores y los servicios accesibles desde Internet. Le siguen escaneos regulares, a ser posible autenticados, desde dentro y desde fuera, la priorización de los hallazgos basada en el riesgo, la remediación mediante parche, cambio de configuración o controles compensatorios, así como la verificación mediante un nuevo escaneo. Solo este ciclo cerrado, con tiempos de tramitación documentados, hace que el proceso sea gestionable y auditable.
02CVSS 4.0: clasificar correctamente la severidad
El Common Vulnerability Scoring System de FIRST está disponible en la versión 4.0 desde noviembre de 2023 y comprende cuatro grupos de métricas: Base, Threat, Environmental y Supplemental. La métrica de amenaza «Exploit Maturity» refleja si existe código de exploit disponible o si la vulnerabilidad ya se está explotando activamente; la nomenclatura CVSS-B/-BT/-BE/-BTE hace transparente qué grupos se han incorporado a una puntuación. El propio FIRST aclara que CVSS mide la severidad técnica y no debe servir como única medida del riesgo. Quien parchea únicamente según la puntuación Base trata con alta urgencia muchas vulnerabilidades que nunca llegan a explotarse – y pasa por alto otras activamente atacadas con puntuación media.
03EPSS y CISA KEV: explotación en lugar de intuición
El Exploit Prediction Scoring System (EPSS) de FIRST es un modelo de machine learning que estima a diario, para cada CVE publicada, la probabilidad de que sea explotada activamente en los próximos 30 días; las puntuaciones están disponibles gratuitamente vía CSV y API. El catálogo Known Exploited Vulnerabilities (KEV) de CISA, la agencia estadounidense de ciberseguridad, recoge en cambio vulnerabilidades cuya explotación ya está demostrada. En la práctica, tres señales se complementan: CVSS responde a cuán grave sería una explotación, EPSS a cuán probable es, y KEV a si ya está ocurriendo. Los hallazgos listados en el KEV en sistemas accesibles deben situarse al principio de la cola, independientemente de la puntuación Base.
04SLA de parcheo: plazos según el riesgo, no plazos genéricos
Unos SLA sólidos definen plazos de corrección vinculantes por criticidad y exposición, junto con un proceso de excepciones con aceptación documentada del riesgo. Como modelo de referencia sirve la directiva BOD 26-04 de CISA (10/06/2026, sustituye a la BOD 22-01): deriva los plazos de cuatro criterios – accesibilidad desde Internet, estado KEV, automatizabilidad del ataque e impacto técnico – y los escalona desde 3 días (incluida una revisión forense cuando una entrada en el KEV se combina con el control total del sistema) pasando por 14 y 60 días hasta la corrección con la siguiente actualización regular. La directiva solo es vinculante para las agencias federales estadounidenses, pero como modelo de plazos basado en el riesgo ofrece también a las empresas una orientación comprensible.
05Zero-days: actuar antes de que exista el parche
Se considera zero-day una vulnerabilidad que se explota o se hace pública antes de que el fabricante proporcione un parche – a la defensa le quedan «cero días» de margen. Como el parcheo clásico no es posible, entran en juego medidas compensatorias: el parcheo virtual bloquea los intentos de explotación delante de la aplicación mediante reglas WAF o IPS, sin modificar el código; OWASP clasifica expresamente este enfoque en su Virtual Patching Cheat Sheet como una solución transitoria que no sustituye a la corrección propiamente dicha. A ello se suman los workarounds de los avisos de los fabricantes, la segmentación de red y la desactivación temporal de funciones expuestas. El requisito previo es una monitorización sistemática de los avisos de seguridad – por ejemplo, de los boletines de los fabricantes, del servicio de alertas e información de CERT-Bund/BSI y del catálogo KEV.
06Anclaje en el SGSI e indicadores
ISO/IEC 27001:2022 ancla el tema en el control 8.8 del anexo A («Management of technical vulnerabilities»): hay que obtener información sobre las vulnerabilidades técnicas, evaluar la propia exposición y adoptar medidas adecuadas. También NIS2 (Directiva (UE) 2022/2555) exige en el art. 21(2)(e) medidas de seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluidas la gestión y la divulgación de vulnerabilidades. El proceso se gestiona mediante indicadores como el tiempo medio de corrección (MTTR) por clase de criticidad, la tasa de cumplimiento de los SLA, la cobertura de escaneo del inventario, la antigüedad de las vulnerabilidades abiertas – en particular las listadas en el KEV – y la tasa de reaparición tras la verificación. Estos valores deben formar parte del reporting periódico a la dirección del SGSI.
