El soporte extendido de Linux no parchea todo y los escáneres no lo entienden

Un escáner de vulnerabilidades devuelve 37 hallazgos sobre un servidor Linux con un sistema operativo que el fabricante sigue soportando. Seguridad dice que hay que parchear. El equipo de aplicaciones contesta que el sistema está soportado y que no va a tocar nada. La discusión se convierte en una reunión con infraestructura, riesgo y negocio sentados a la misma mesa. Los dos bandos tienen parte de razón, y ninguno está formulando la pregunta que importa.

"Soportado" no significa lo mismo para todo

Las distribuciones empresariales de Linux se organizan en fases: lanzamiento, soporte completo, mantenimiento, soporte extendido y fin de vida. Los nombres cambian según el proveedor. Red Hat tiene Extended Update Support, que entrega actualizaciones de seguridad y correcciones para determinadas versiones menores, y Ubuntu mantiene Extended Security Maintenance para sus LTS. El alcance exacto depende de la versión, del paquete concreto, de la arquitectura, del repositorio y del nivel de suscripción contratado.

Por eso, cuando alguien suelta "este servidor sigue soportado", la réplica correcta es: soportado para qué, exactamente.

La versión del paquete no es el estado de vulnerabilidad

Aquí está el malentendido que genera casi todos los tickets. El escáner compara la versión instalada con la versión upstream donde se publicó el arreglo y concluye que el sistema está expuesto. Pero las distribuciones empresariales hacen backporting: cogen el parche de una versión posterior y lo meten dentro de la versión antigua que mantienen. El paquete 3.0 del fabricante puede llevar ya el fix que upstream publicó en el 3.2, y seguir mostrando un número que parece de hace tres años. Red Hat documenta esa práctica de forma explícita.

El resultado es que comparar la versión instalada con la upstream produce falsos positivos, y en el otro extremo también puede ocultar cobertura que no existe.

Qué hacer con un crítico sobre soporte extendido

Lo primero es no saltar de "CVE detectado" a "hay que parchear". El recorrido sensato: identificar sistema y paquete, consultar el aviso de seguridad del fabricante, comprobar el estado del ciclo de vida y si ese paquete entra en la cobertura de soporte extendido, verificar si el fabricante ha publicado el arreglo o un backport, y solo entonces valorar exposición real, explotabilidad y criticidad del negocio. La decisión puede acabar en parchear, mitigar, aceptar el riesgo o planificar una migración. No siempre será la misma.

Hay un matiz que se pierde en las reuniones: el soporte extendido no promete que cualquier vulnerabilidad descubierta en el ecosistema vaya a corregirse para ese sistema. Depende de la gravedad, de la viabilidad técnica del arreglo y de la política comercial del proveedor. Sirve para alargar la vida útil de plataformas que no se pueden mover ya, no para convertir un sistema viejo en uno nuevo.

El problema de fondo no es técnico, es de información. Ningún escáner sabe si el fabricante metió el parche por detrás sin cambiar el número de versión, ni sabe qué paquetes cubre tu nivel de suscripción. Ese trabajo sigue siendo manual y caso por caso, y quien no lo haga acabará discutiendo sobre el resultado de una herramienta en lugar de sobre el riesgo real de un servidor en producción.