Comprobar el ciclo de vida de soporte de un sistema operativo antes de automatizar sobre él

Objetivo

Antes de que un agente automatice el parcheo, las actualizaciones o una comprobación de cumplimiento sobre un host, confirmar que la versión del sistema operativo del host sigue dentro de la ventana de soporte del fabricante, y marcarlo con claridad si no es así.

Requisitos previos

Capacidad para identificar el sistema operativo y la versión (véase el artículo complementario sobre la detección del sistema operativo desde un script) y acceso de red a la página de ciclo de vida publicada por el fabricante, o una copia local en caché de las fechas relevantes.

Pasos

1. Identificar primero la familia del sistema operativo y la versión/release exacta (nombre de la distribución, versión mayor y, para los que siguen releases puntuales, también la versión menor).
2. Consultar la propia declaración de ciclo de vida del fabricante, no la de un tercero, como fuente primaria:
   • RHEL: la página de política de soporte de actualizaciones de paquetes y erratas de Red Hat indica las fases de cada release mayor y su duración.
   • Ubuntu: la página del ciclo de releases de Ubuntu distingue los releases estándar (9 meses) de los LTS (5 años estándar, ampliables).
   • Debian: la página de releases estables indica cuál es el release actual y marca el punto en que un release deja de recibir actualizaciones; el proyecto Debian LTS, aparte, amplía el soporte de seguridad para algunas arquitecturas.
   • Windows / Windows Server: el sitio de Microsoft Lifecycle Policy da fechas de ciclo de vida fijo y moderno por producto y canal de mantenimiento.
   • AIX: las páginas de soporte de IBM publican las fechas de ciclo de vida de soporte por nivel de tecnología (TL) de AIX.
   • FreeBSD: la página Security Information indica qué ramas reciben actualmente parches de seguridad.
   • macOS: Apple no publica un calendario fijo de fin de vida; en la práctica, Apple normalmente distribuye actualizaciones de seguridad para el release actual y los dos anteriores — los dos más antiguos suelen recibir solo parte de las correcciones —, seguimiento que hacen agregadores de terceros como endoflife.date en lugar de un calendario oficial.
3. Comparar la versión del host con las fechas encontradas; tratar «no se pudo determinar, no se encontró fecha publicada» como equivalente a «marcar para revisión», no como «asumir que tiene soporte».
4. Registrar la fecha de la comprobación, la fuente consultada y el estado resultante (con soporte / próximo a fin de vida / fuera de soporte) junto con el registro de inventario del host.
5. Para un host fuera de soporte, evitar que los flujos automáticos de parcheo/cumplimiento informen un estado saludable para ese host; presentarlo en cambio como un hallazgo que requiere una decisión (actualizar, reemplazar o aceptar un riesgo documentado).

Resultado esperado

Todo host dentro del alcance tiene registrado un estado de ciclo de vida con fecha y fuente indicada; los hosts fuera de soporte quedan marcados con claridad en lugar de incluirse silenciosamente en resúmenes de «todo parcheado».

Límites y base de verificación

Las páginas de ciclo de vida de los fabricantes cambian; una fecha en caché debería reverificarse periódicamente en lugar de tratarse como permanente. La ausencia de una política de fin de vida publicada por Apple hace que el estado de macOS sea inherentemente una inferencia, no un hecho documentado, y debería etiquetarse como tal en cualquier informe. Esta metodología no determina si un host fuera de soporte está siendo explotado actualmente; solo que dejará de recibir correcciones, lo cual es una cuestión distinta y previa que la automatización no debería omitir.