Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones:
- El software al final de su ciclo de vida es una realidad inevitable en los sistemas empresariales. Las plataformas críticas suelen sobrevivir a los componentes de código abierto de los que dependen, y esos componentes siguen acumulando vulnerabilidades mucho después de que finalice el soporte oficial.
- El uso seguro de software al final de su ciclo de vida (EOL) requiere un esfuerzo continuo y complejo. Es necesario realizar un seguimiento de las vulnerabilidades en bases de datos dispersas y gráficos de dependencias complejos, para luego aplicar parches, recompilar y probar los componentes que ha heredado su equipo, y todo ello de forma repetida, durante años.
- La fiabilidad a largo plazo del software de código abierto no se define por la ausencia de vulnerabilidades, sino por la madurez de los procesos que las gestionan. Los los flujos de trabajo de aplicación de parches y la experiencia institucional —como las que ofrece el servicio Endless Lifecycle Support de TuxCare— hacen posible una seguridad de código abierto consistente y fiable a lo largo del tiempo.
Es probable que el software que desarrolles hoy siga funcionando durante años, una década o incluso más. Los sistemas críticos no se sustituyen por capricho. Se les realiza mantenimiento, se les aplican parches y se mantienen en funcionamiento porque son demasiado esenciales, demasiado caros o están demasiado integrados como para ser sustituidos.
Pero hay algo en lo que la mayoría de los equipos no piensan durante el desarrollo: los componentes de código abierto de los que depende tu software no durarán necesariamente tanto como tu propio software. Las bibliotecas llegan al final de su vida útil. Los marcos dejan de recibir actualizaciones. Los entornos de ejecución de los lenguajes pasan a versiones más nuevas, algo muy similar a los retos a los que se enfrentó la transición al final de la vida útil de Node.js. Esta realidad también afecta a los marcos de frontend más populares, y los equipos suelen buscar formas de gestionar el ciclo de fin de vida útil (EOL) de Next.js sin alterar sus planes de producción. Y cuando eso ocurre, te quedas manteniendo sistemas de producción que dependen de software que ya nadie soporta oficialmente.
Las vulnerabilidades no desaparecen cuando finaliza el soporte oficial. Siguen apareciendo, año tras año, repartidas por complejos gráficos de dependencias.
Solucionarlas una o dos veces es algo factible. ¿Pero solucionarlas de forma fiable, repetida y correcta a lo largo de cinco o diez años? Bueno, eso requiere algo que la mayoría de las organizaciones subestiman: un proceso de aplicación de parches maduro y disciplinado que funcione siempre de la misma manera, independientemente de dónde aparezca la vulnerabilidad o cuándo se descubra.
Cómo las organizaciones acaban utilizando software obsoleto
Si tu software permanece en producción durante cinco, siete o diez años, los componentes de código abierto que contiene acabarán llegando al final de su ciclo de vida mucho antes que tu sistema. Sus responsables de mantenimiento dejan el proyecto, el soporte oficial se interrumpe y, de repente, te encuentras utilizando algo que ya no recibe actualizaciones de seguridad. No se trata de un error ni de una falta de planificación. Es lo que suele ocurrir en entornos empresariales, donde la estabilidad del sistema y la gestión controlada de los cambios son prioridades fundamentales.
Y ocurre con más frecuencia de lo que crees. Es posible que estés utilizando una versión estable que lleva años en producción y funciona a la perfección. Quizás hayas desarrollado integraciones basadas en ella que resultaría muy costoso rehacer. Puede que hayas pasado por un largo proceso de certificación de cumplimiento normativo que no estás dispuesto a repetir. O tal vez las versiones más recientes introduzcan cambios que afecten a la compatibilidad y que repercutirían en todo tu sistema.
Sin embargo, aunque sus sistemas estén diseñados para funcionar a largo plazo, el panorama de las vulnerabilidades sigue cambiando. Las dependencias de código abierto que antes eran seguras y se mantenían activamente empiezan a acumular vulnerabilidades que nadie va a corregir. Y muchos de esos problemas pasan totalmente desapercibidos. Quedan ocultos en las capas de dependencias que se encuentran debajo de los componentes con los que realmente interactúa.
Si quieres conocer con más detalle en qué se diferencian los plazos de soporte técnico de los fabricantes de la retirada definitiva de los productos, consulta nuestra guía sobre la diferencia entre «fin de vida útil» y «fin de soporte técnico».
El problema del gráfico de dependencias
La mayoría de los equipos consideran los componentes de código abierto de los que dependen como una simple lista en un archivo de manifiesto. Sin embargo, cada una de esas bibliotecas trae consigo sus propias dependencias, y esas dependencias, a su vez, traen las suyas.
Incluso una biblioteca ligera puede depender de unas pocas dependencias directas y de una larga lista de dependencias transitivas en las que nunca piensas. Y cuando surge una vulnerabilidad, puede estar en cualquier parte: en el componente de primer nivel que estás utilizando, en alguna biblioteca secundaria dos niveles más abajo, o en una dependencia profundamente anidada de la que ni siquiera has oído hablar.
Considera spring-boot-starter-web, una opción habitual para aplicaciones web en Java. Al añadir esta única dependencia a tu proyecto, se incorporan automáticamente más de 25 dependencias transitivas: toda la pila del marco Spring®, un servidor Tomcat integrado, Jackson para el procesamiento de JSON, múltiples bibliotecas de registro, bibliotecas de validación y mucho más.
Figura. Árbol de dependencias de Spring® Boot Starter Web.
Así pues, una vez que te comprometes a mantener un componente de código abierto, te haces responsable de todo su gráfico de dependencias. Cualquier vulnerabilidad que surja en cualquier punto de ese gráfico se convierte en un problema que te corresponde resolver. Y no existe un único canal estándar que puedas consultar de forma habitual para obtener información oportuna sobre las vulnerabilidades de todas esas numerosas dependencias.
Las vulnerabilidades CVE se publican en decenas de bases de datos de seguridad, listas de correo y repositorios de proyectos diferentes. Un problema crítico podría surgir en una dependencia transitiva poco conocida con la que nunca hayas interactuado directamente.
Es necesario realizar un seguimiento continuo de todo el gráfico, no solo de los componentes que utilizas directamente, sino también de todas las dependencias a varias niveles de profundidad, estar atento a las nuevas divulgaciones y determinar cuáles afectan realmente a tus versiones específicas en fase de fin de vida útil.
En qué consiste realmente la corrección de una vulnerabilidad
Cuando aparece una vulnerabilidad en cualquier punto de ese gráfico de dependencias, solucionarla nunca es tan sencillo como aplicar un parche. Es necesario actualizar y volver a compilar el propio componente vulnerable, volver a compilar todas las bibliotecas que dependen de él, ejecutar todo el conjunto de pruebas y confirmar que no se ha producido ningún cambio en la integración o en el empaquetado.
Aunque la corrección de seguridad sea mínima y esté diseñada para mantener el comportamiento, la recompilación es inevitable. Es la única forma de generar un artefacto en el que se pueda confiar para su implementación.
A veces, el parche se puede aplicar tal cual. Otras veces, el parche se ha escrito para una versión más reciente y hay que adaptarlo para que funcione con el código antiguo y las versiones de las dependencias de las que depende tu componente congelado. Si la adaptación no se realiza correctamente, o bien no se subsanará la vulnerabilidad de seguridad, o bien se romperá la compatibilidad con los sistemas que dependen de ese componente.
A lo largo de un periodo de soporte de cinco años tras el fin de vida útil (EOL), es posible que te encuentres con docenas de vulnerabilidades, cada una de las cuales requerirá trabajo en toda la cadena de dependencias de la biblioteca vulnerable. Y, dado que constantemente surgen nuevas vulnerabilidades, tendrás que repetir este proceso una y otra vez mientras sigas utilizando esa versión EOL. Cada vez que lo hagas, se requerirá el mismo flujo de trabajo: aplicar parches, recompilar, probar, validar e implementar. Y cada recompilación conlleva su propia complejidad.
Por qué «código congelado» no significa «compilaciones congeladas»
Podrías pensar que, si el código fuente está congelado y las dependencias están fijadas, al volver a compilar siempre debería generarse el mismo artefacto. Sin embargo, en la práctica, no es así como funciona.
Si vas a mantener una solución durante cinco o diez años, el entorno en el que la desarrollas tiene que evolucionar. Los sistemas operativos reciben parches. Las imágenes base se actualizan. Los compiladores cambian. Las cadenas de certificados se renuevan. Las herramientas de CI/CD se actualizan. Los entornos de ejecución de contenedores avanzan. Estas actualizaciones se producen por motivos justificados, como la seguridad, el cumplimiento normativo y las necesidades operativas, y se llevan a cabo independientemente de si tu software en fase de fin de vida útil (EOL) cambia o no.
Cada una de esas actualizaciones introduce pequeñas diferencias en el entorno de compilación, y estas diferencias pueden reflejarse en el artefacto final. Las herramientas de compilación evolucionan al igual que todo lo demás. Sus algoritmos de resolución de dependencias y de empaquetado de artefactos cambian. Como resultado, el formato de empaquetado puede variar ligeramente, o los metadatos pueden estructurarse de forma diferente. Nada de esto altera lo que el componente hace realmente, pero puede afectar a la forma en que otras bibliotecas se integran con él o a cómo lo cargan los entornos de ejecución.
El mundo sigue avanzando aunque tu componente en fase de fin de vida útil no lo haga, por lo que cada reconstrucción requiere el mismo nivel de validación que se le aplicaría a una versión totalmente nueva. Un proceso de aplicación de parches bien establecido debe tener esto en cuenta, así como la evolución del equipo encargado de mantener este software a lo largo del tiempo.
El problema de la pérdida de conocimientos
Cuando te encargas del mantenimiento de componentes de código abierto que han llegado al final de su ciclo de vida (EOL) durante un periodo de entre cinco y diez años, estás trabajando con software que tu equipo no ha escrito. Los mantenedores originales han dejado el proyecto. La comunidad del proyecto se ha dispersado. La documentación, si es que existe, puede estar incompleta, desactualizada o centrada en versiones más recientes, en lugar de en la versión EOL de la que te estás ocupando.
Tu equipo se encuentra con componentes que no ha creado, con decisiones arquitectónicas que no ha tomado y con elecciones de dependencias que no ha controlado. Saber cómo aplicar parches a estos componentes de forma segura implica familiarizarse con códigos y procesos de compilación desconocidos, diseñados hace años por personas a las que ya no es posible consultar.
Sin esos conocimientos básicos, cada ciclo de aplicación de parches se vuelve más difícil y conlleva un mayor riesgo. Los equipos dedican más tiempo a investigar que a solucionar problemas, y aumentan las posibilidades de introducir cambios sutiles que provoquen fallos. Por eso, los procesos de aplicación de parches bien establecidos deben tener en cuenta la pérdida de conocimientos mediante una documentación exhaustiva y procedimientos estandarizados que no dependan de que las personas recuerden cómo funcionan las cosas.
Cómo es realmente la madurez de los procesos
Un proceso de aplicación de parches maduro no consiste únicamente en corregir las vulnerabilidades con mayor rapidez o más minuciosamente. Se trata de crear sistemas y una disciplina que funcionen de forma fiable, independientemente de cuándo, dónde o con qué frecuencia aparezcan las vulnerabilidades. Esto es lo que distingue a las operaciones maduras de las reactivas:
- Supervisión exhaustiva de todo el gráfico.Los procesos maduros no esperan a que los clientes notifiquen las CVE. Supervisan activamente el panorama de vulnerabilidades en todas las capas de cada gráfico de dependencias que gestionan. Saben qué hay detrás de los componentes que mantienen y detectan los problemas de forma temprana.
- Procedimientos estandarizados de recompilación y validación. Cada parche activa el mismo flujo de trabajo: parchear, recompilar, probar, validar, empaquetar, publicar. El procedimiento no cambia independientemente de la gravedad del CVE o del componente afectado. Esta coherencia es lo que hace que el proceso sea fiable. Cuando haces algo de la misma manera cien veces, acabas haciéndolo bien. Cuando improvisas cada vez, se te escapan cosas.
- Pruebas de compatibilidad rigurosas. Los procesos maduros validan no solo que el componente parcheado funcione de forma aislada, sino que se integre correctamente con todas las demás bibliotecas que dependen de él. Tienen en cuenta las variaciones del entorno y realizan pruebas en las condiciones reales de funcionamiento de los clientes, no solo en la configuración ideal de laboratorio.
- Ritmo y comunicación predecibles. Los clientes que confían en el software EOL necesitan saber que los problemas de seguridad se abordarán de forma sistemática. Los procesos maduros establecen acuerdos de nivel de servicio (SLA) claros, mantienen una comunicación transparente sobre qué se ha parcheado y cuándo, y distribuyen las actualizaciones a través de canales fiables.
- Conocimiento institucional y documentación. Cuando se mantienen docenas de componentes EOL a lo largo de los años, no se puede depender de héroes individuales que casualmente saben cómo recompilar una biblioteca específica. Los procesos maduros lo documentan todo: procedimientos de compilación, requisitos de prueba, peculiaridades conocidas y dificultades de integración. Este conocimiento persiste incluso aunque cambien los miembros del equipo.
Por qué la perfección en los procesos es clave para la fiabilidad a largo plazo
Puedes escribir un parche perfecto —con cambios mínimos, que mantenga el comportamiento y haya sido probado a fondo— y, aun así, generar problemas si el proceso que lo rodea es descuidado. Podrías pasar por alto una dependencia transitiva que también necesitara actualizarse. Tu recompilación podría introducir un cambio en el empaquetado que rompa las integraciones posteriores. O podrías corregir un CVE, pero pasar por alto los otros dos que se incorporaron esa misma semana en diferentes partes del gráfico.
Lo difícil del soporte a largo plazo para el software de código abierto no es solo escribir buenos parches. Se trata de mantener la disciplina necesaria para implementarlos de forma fiable, repetida y correcta a lo largo de años de continuas revelaciones de vulnerabilidades. Durante cinco años de soporte tras el fin de la vida útil del producto, eso podría suponer cincuenta o más parches en un complejo grafo de dependencias. Las organizaciones que intentan gestionar esto de forma reactiva agotan a sus equipos y lanzan parches poco fiables. Las organizaciones que invierten en la madurez de los procesos ofrecen una seguridad constante sin caer en el caos.
Esa disciplina solo se consigue mediante procesos maduros: flujos de trabajo estandarizados, una supervisión exhaustiva, una validación rigurosa y un conocimiento institucional que perdura más allá de los colaboradores individuales. El soporte de ciclo de vida ilimitado de TuxCare se basa precisamente en estos pilares. Nuestro proceso de aplicación de parches, perfeccionado a lo largo de una década, gestiona toda la complejidad del mantenimiento a largo plazo tras el fin de vida útil (EOL), desde la supervisión de gráficos de dependencias complejos hasta la entrega de parches validados que preservan la compatibilidad durante todo el tiempo que sus sistemas los necesiten.
La perfección en los procesos significa que, cuando surge una vulnerabilidad (y surgirá, una y otra vez), se responde de la misma manera en todas las ocasiones. El parche se aplica correctamente. Eso es lo que define la verdadera fiabilidad del código abierto a largo plazo: no la ausencia de vulnerabilidades, sino la existencia de procesos lo suficientemente maduros como para gestionarlas, independientemente de cuántas aparezcan o dónde se escondan.
