En seguridad hay una verdad incomoda que conviene asumir cuanto antes: es imposible parchear todo al instante. Cada año se publican decenas de miles de vulnerabilidades nuevas —el ritmo supera con holgura los 25.000 CVEs anuales— y ninguna organizacion tiene ventanas de mantenimiento, personal ni tolerancia al riesgo operativo suficientes para aplicar cada actualizacion el mismo dia en que aparece. La pregunta correcta, por tanto, no es como parcheo más rápido, sino que parcheo primero.
La gestión de parches y CVEs es el proceso organizativo que responde a esa pregunta de forma sistematica. No consiste en pulsar "actualizar" cuando aparece un aviso, sino en mantener un inventario fiable de activos, escanear con regularidad, priorizar según el riesgo real y no solo la severidad teorica, remediar dentro de plazos definidos y verificar que el parche realmente cerro el agujero. Hecho bien, este ciclo convierte una montaña inabarcable de vulnerabilidades en una cola de trabajo priorizada y manejable.
En este artículo explicamos que es un CVE y como se puntua su severidad con CVSS, por que esa puntuacion no basta para priorizar, como el EPSS y el catalogo KEV de CISA cambian por completo el orden de trabajo, en que consiste el ciclo de gestión de vulnerabilidades de principio a fin, la diferencia entre zero-days y n-days, y como fijar SLAs de parcheo coherentes con exigencias de cumplimiento como NIS2.
Que es un CVE y como se mide su severidad con CVSS
Un CVE (Common Vulnerabilities and Exposures) es un identificador único y publico para una vulnerabilidad concreta de un producto de software o hardware. Sigue el formato CVE-AÑO-NUMERO —por ejemplo CVE-2021-44228, la famosa Log4Shell— y sirve como referencia comun para que fabricantes, investigadores, escaneres de seguridad y equipos de operaciones hablen exactamente de la misma debilidad sin ambiguedad. Cuando un fabricante o un investigador descubre un fallo, se le asigna un CVE que centraliza toda la información asociada.
A cada CVE se le asigna normalmente una puntuacion CVSS (Common Vulnerability Scoring System), una escala de 0 a 10 que mide la severidad técnica. La puntuacion base se calcula a partir de metricas como el vector de ataque (¿es explotable en red o requiere acceso local?), la complejidad, si necesita privilegios o interaccion del usuario, y el impacto sobre confidencialidad, integridad y disponibilidad. De ahi salen las categorias habituales: critica (9.0–10), alta (7.0–8.9), media (4.0–6.9) y baja (0.1–3.9).
El CVSS es útil como primera aproximacion y como lenguaje comun, pero tiene una limitacion de fondo: describe lo grave que seria una explotacion en el peor caso teorico, no la probabilidad de que esa explotacion ocurra realmente contra tus sistemas. Y ahi es donde muchos programas de parcheo se equivocan de arriba a abajo.
Por que CVSS no basta: EPSS y el catalogo KEV
Priorizar únicamente por CVSS lleva a un error clasico: tratar todos los "9.8 criticos" como igual de urgentes y dejar en segundo plano vulnerabilidades de menor puntuacion que, sin embargo, se estan explotando activamente hoy mismo. Un CVSS 9.8 sin ninguna explotacion conocida ni exploit publico puede ser menos urgente que un CVSS 7.5 que los atacantes ya estan usando de forma masiva. La severidad no es lo mismo que el riesgo.
Para corregir esto, la priorizacion moderna incorpora dos senales adicionales. La primera es el EPSS (Exploit Prediction Scoring System), un modelo que estima la probabilidad de que un CVE sea explotado en los próximos 30 días, expresada como porcentaje. Un CVE con EPSS del 90% merece atencion inmediata aunque su CVSS sea medio; uno con EPSS por debajo del 1% puede esperar a la siguiente ventana aunque su CVSS sea alto.
La segunda —y la más contundente— es el catalogo KEV (Known Exploited Vulnerabilities) que mantiene la agencia estadounidense CISA. El KEV es una lista curada de vulnerabilidades para las que existe evidencia confirmada de explotacion real en el mundo. Si un CVE esta en el KEV, deja de ser una probabilidad: alguien ya lo esta usando contra organizaciones reales. La regla practica es simple y no admite discusion.
Regla de oro de la priorizacion:
Parchea primero todo lo que este en el catalogo KEV de CISA, independientemente de su CVSS. Después, ordena el resto combinando EPSS (probabilidad de explotacion), CVSS (impacto) y el contexto de exposicion de cada activo: no es lo mismo un servidor publico en internet que uno aislado en una red interna sin salida.
El contexto es la tercera pata imprescindible. La misma vulnerabilidad en un servidor web expuesto a internet no representa el mismo riesgo que en un sistema segmentado sin conectividad externa. Un buen programa de priorizacion cruza CVSS, EPSS y KEV con la exposicion real del activo, su criticidad para el negocio y las mitigaciones ya presentes (un WAF, segmentacion de red, controles de acceso). Puedes consultar el listado oficial en el catalogo KEV de CISA, actualizado de forma continua.
El ciclo de gestión de vulnerabilidades
La gestión de vulnerabilidades no es una tarea puntual, sino un ciclo continuo con cinco fases que se repiten indefinidamente. Saltarse cualquiera de ellas rompe la cadena entera:
- check_circle 1. Descubrir (inventario de activos): no puedes parchear lo que no sabes que tienes. El punto de partida es un inventario fiable y actualizado de servidores, servicios, versiones, dependencias y librerias. Los activos "olvidados" —un servidor de pruebas expuesto, una VM que nadie apago— son la via de entrada favorita de los atacantes.
- check_circle 2. Escanear: herramientas como Nessus, OpenVAS o Qualys comparan el software instalado con bases de datos de CVEs y detectan que vulnerabilidades afectan a cada activo. El escaneo debe ser regular (continuo o semanal para lo expuesto) y ejecutarse también tras cada cambio o despliegue.
- check_circle 3. Priorizar: aquí se cruza CVSS, EPSS, KEV y el contexto de exposicion para convertir cientos de hallazgos en una cola ordenada. Es la fase donde se decide que se toca hoy y que puede esperar.
- check_circle 4. Remediar: no siempre significa parchear. Hay tres respuestas validas: parchear (aplicar la actualizacion), mitigar (aplicar un control compensatorio —regla de firewall, WAF, desactivar la funcion vulnerable— cuando no hay parche o no se puede aplicar aun) o aceptar el riesgo de forma documentada cuando el impacto es asumible.
- check_circle 5. Verificar: un parche no cuenta como aplicado hasta que un nuevo escaneo confirma que la vulnerabilidad ha desaparecido. La verificacion cierra el ciclo y evita el falso sentido de seguridad de creer que algo esta resuelto cuando no lo esta.
Este ciclo se apoya en un equilibrio permanente entre disponibilidad y seguridad. Cada parche implica normalmente un reinicio o una ventana de mantenimiento, y aplicar actualizaciones sin control puede romper un servicio en produccion. Por eso las organizaciones definen ventanas de mantenimiento planificadas y clasifican los parches: los críticos y explotados justifican una ventana de emergencia; el resto se agrupa en ciclos regulares. El endurecimiento previo del sistema reduce la superficie que hay que parchear —revisa nuestra checklist de hardening de servidores Linux para minimizar el riesgo de base.
Zero-day frente a n-day: el enemigo suele ser viejo
Existe una fijacion mediatica con los zero-days: vulnerabilidades que se explotan antes de que exista un parche disponible. Son peligrosas, dificiles de anticipar y acaparan titulares. Pero son la excepcion, no la norma. La inmensa mayoria de las brechas reales no usan zero-days, sino n-days: vulnerabilidades que ya tienen parche publicado desde hace semanas, meses o incluso años y que la victima simplemente no habia aplicado.
Los casos celebres lo confirman. La brecha de Equifax en 2017, que expuso datos de casi 150 millones de personas, aprovecho CVE-2017-5638 en Apache Struts: un fallo con parche disponible dos meses antes del ataque. Log4Shell (CVE-2021-44228) se parcheo en días, pero siguio explotandose durante años en sistemas que nunca se actualizaron. La oleada de MOVEit (CVE-2023-34362) golpeo a cientos de organizaciones en cuanto el exploit se hizo publico. En todos los casos el patron es el mismo: el parche existia y no se habia aplicado a tiempo.
La leccion es liberadora: no puedes controlar los zero-days, pero los n-days —que son la mayoria— dependen enteramente de la disciplina de tu proceso de parcheo. Un programa de gestión de vulnerabilidades solido neutraliza el vector de ataque más comun sin necesidad de tecnologia magica, solo de constancia.
Automatización: escalar sin romper produccion
Con decenas o cientos de sistemas, el parcheo manual no escala. La automatización es imprescindible: herramientas de patch management como WSUS en entornos Windows, gestores de paquetes con despliegue centralizado, o plataformas de automatización como Ansible permiten aplicar actualizaciones de forma coordinada, repetible y auditable sobre parques enteros de servidores.
Ahora bien, automatizar no significa aplicar a ciegas. La regla es probar antes en staging: desplegar el parche en un entorno de pruebas que replique produccion, verificar que no rompe nada, y solo entonces promocionarlo a produccion en oleadas controladas —primero un grupo piloto, luego el resto— con capacidad de rollback si algo falla. Un parche que tumba un servicio critico puede causar más dano operativo que la propia vulnerabilidad que corrige.
Conviene recordar que el software de aplicación y el sistema operativo no son la única capa vulnerable. El firmware —esa parte que casi nadie actualiza— (BIOS/UEFI, BMC, controladoras, tarjetas de red) también acumula CVEs y debe entrar en el mismo ciclo de gestión, aunque su cadencia de actualizacion sea distinta y más delicada.
SLAs de parcheo por severidad
Un programa maduro no parchea "cuando se puede", sino contra plazos objetivo definidos por severidad y explotacion. Fijar SLAs de remediacion convierte la buena intencion en un compromiso medible y auditable. Una tabla de referencia habitual, ajustable según el apetito de riesgo de cada organizacion:
| Severidad / condicion | Plazo objetivo | Ejemplo |
|---|---|---|
| En catalogo KEV / explotada activamente | 24–48 horas | Log4Shell, MOVEit |
| Critica (CVSS 9.0–10) | 7 días | RCE sin autenticacion en servicio expuesto |
| Alta (CVSS 7.0–8.9) | 15–30 días | Escalada de privilegios local |
| Media (CVSS 4.0–6.9) | 30–90 días | Fuga de información limitada |
| Baja (CVSS 0.1–3.9) | Próxima ventana / 90+ días | Denegacion de servicio menor |
Lo importante de esta tabla no son las cifras exactas, sino el principio que representa: la presencia en el KEV manda sobre el CVSS. Una vulnerabilidad de severidad "solo alta" pero explotada activamente entra en el plazo de emergencia de 24–48 horas, mientras que una crítica sin exploit conocido puede seguir el ciclo normal. Medir el cumplimiento de estos SLAs —porcentaje de vulnerabilidades remediadas dentro de plazo, tiempo medio de remediacion— es lo que permite demostrar que el proceso funciona.
Cumplimiento (NIS2) y gestión de parches con EasyDataHost
La gestión de vulnerabilidades ha dejado de ser una buena practica opcional para convertirse en una exigencia regulatoria. La directiva europea NIS2, que amplia enormemente el número de entidades obligadas, requiere explicitamente medidas de gestión de riesgos que incluyen el tratamiento y la divulgacion de vulnerabilidades, la aplicación oportuna de parches y políticas de seguridad demostrables. Marcos como el ENS en España o ISO 27001 apuntan en la misma direccion: sin un proceso documentado de gestión de parches, no hay cumplimiento que sostenga una auditoria.
El problema es que ejecutar bien este ciclo —inventario, escaneo continuo, priorizacion con KEV y EPSS, pruebas en staging, ventanas de mantenimiento y verificacion— exige personal, herramientas y disciplina que muchas organizaciones no pueden dedicar en exclusiva. Por eso en EasyDataHost incluimos la gestión de parches dentro de nuestros servicios gestionados: nos encargamos del escaneo, la priorizacion basada en explotacion real, la aplicación de parches en ventanas coordinadas y la verificacion posterior, sobre infraestructura en datacenter propio en España con certificación ISO 27001 y conformidad ENS.
La gestión de parches es, ademas, una pieza de una estrategia de seguridad más amplia que combina hardening, segmentacion, backup offsite y monitorización. Ningun control aislado basta; es la suma coordinada la que reduce el riesgo real. Si quieres delegar este proceso o auditar el que ya tienes, habla con nuestro equipo.
Preguntas frecuentes
¿Debo parchear siempre primero las vulnerabilidades con mayor puntuacion CVSS?
No necesariamente. El CVSS mide la severidad teorica, no la urgencia real. Debes priorizar primero las vulnerabilidades del catalogo KEV de CISA (explotadas activamente) y las de EPSS alto, aunque su CVSS sea menor. Un CVSS 7.5 explotado activamente es más urgente que un CVSS 9.8 sin explotacion conocida.
¿Que diferencia hay entre un zero-day y un n-day?
Un zero-day se explota antes de que exista parche disponible. Un n-day ya tiene parche publicado pero la organizacion aun no lo ha aplicado. La gran mayoria de las brechas reales aprovechan n-days —CVEs conocidos y sin parchear—, no zero-days.
¿Con que frecuencia hay que escanear en busca de vulnerabilidades?
Para activos expuestos a internet, un escaneo continuo o al menos semanal, y siempre después de cualquier cambio o despliegue. El escaneo debe apoyarse en un inventario de activos actualizado: no se puede parchear lo que no se sabe que se tiene.
Conclusion
Ante decenas de miles de CVEs al año, el objetivo no es parchear todo —es imposible— sino parchear lo correcto primero y hacerlo de forma sistematica y verificable:
- arrow_right El CVSS mide severidad teorica, no urgencia. Prioriza con EPSS (probabilidad) y, sobre todo, con el catalogo KEV de CISA: lo explotado activamente va primero, pase lo que pase.
- arrow_right El ciclo de gestión —descubrir, escanear, priorizar, remediar y verificar— es continuo. Todo empieza por un inventario fiable: no puedes parchear lo que no sabes que tienes.
- arrow_right La mayoria de las brechas usan n-days, no zero-days: CVEs viejos con parche disponible y sin aplicar. La disciplina del proceso neutraliza el vector de ataque más comun.
- arrow_right Automatiza (WSUS, Ansible, patch management) pero prueba antes en staging, fija SLAs por severidad y cumple exigencias como NIS2. En EasyDataHost lo incluimos en los servicios gestionados.