¿Qué es el «backporting»? Proceso, consideraciones, consejos y mucho más

Principales conclusiones

• El «backporting» consiste en incorporar una corrección de una versión más reciente a la versión anterior que utilizas, sin necesidad de actualizar la versión original.
• Red Hat corrigió la vulnerabilidad Heartbleed en OpenSSL 1.0.1e sin modificar la versión original, por lo que los escáneres que solo comprueban la versión la detectan de todos modos.
• Comprueba si se trata de una adaptación hacia versiones anteriores consultando el aviso de la distribución y el registro de cambios del paquete, no el número de versión.
• Cuando finaliza el soporte estándar, las correcciones dependen del soporte ampliado, de una rama mantenida o de tu propio equipo.

Tu escáner indica que el servidor está ejecutando una versión vulnerable de OpenSSL. Tu administrador de sistemas dice que se parcheó el mes pasado. Ambos están analizando el mismo servidor y leyendo el mismo paquete, pero solo uno de ellos tiene razón respecto a la vulnerabilidad. Esa discrepancia se debe a un problema de retroportabilidad. Se aplicó una corrección de una versión más reciente a la versión que sigue en funcionamiento, y el número de versión original nunca cambió. En entornos de Linux empresarial , investigar ese tipo de falsas alarmas puede llevar más horas que algunas vulnerabilidades reales.

Este artículo explica qué es el «backporting», por qué el número de versión no cambia tras la incorporación de una corrección, por qué esto confunde a los escáneres basados en versiones, cómo verificar una corrección por uno mismo y quién se encarga de seguir realizando los «backports» una vez que una versión llega al final de su ciclo de vida.

¿Qué es el «backporting»?

El «backporting» consiste en extraer una corrección para una falla de seguridad de una versión más reciente de un paquete de software y aplicarla a una versión anterior que aún se encuentra en uso. De este modo, se soluciona la vulnerabilidad sin necesidad de pasar a una versión más reciente del desarrollador original y sin tener que incorporar todos los cambios no relacionados con ella.

Pero, ¿qué significa «backport» en la práctica? Aquí tienes un ejemplo concreto. Los responsables del mantenimiento de OpenSSL corrigieron la vulnerabilidad Heartbleed en la versión 1.0.1g. Los clientes de Red Hat utilizaban la versión 1.0.1e, y actualizarlos a la 1.0.1g habría supuesto incorporar todos los demás cambios realizados entre ambas versiones. Por lo tanto, Red Hat realizó un «backport» únicamente de la corrección de Heartbleed a su código base de la versión 1.0.1e y lanzó openssl-1.0.1e-16.el6_5.7 bajo el aviso RHSA-2014:0376. La misma base de características del desarrollador original, el mismo comportamiento fuera de la ruta de código parcheada y sin Heartbleed.

La retroaplicación de correcciones de seguridad de esta forma ha sido una práctica habitual en la mayoría de las distribuciones de Linux, incluidas RHEL, Ubuntu, Debian, SUSE y sus derivadas, desde hace dos décadas. Ejecuta dnf update en un servidor RHEL y verás que muchas de las correcciones que se instalan son retroportaciones.

¿Sabías que...? El campo «release» al final es lo que permite identificar una compilación retroportada. En openssl-1.0.1e-16.el6_5.7, 1.0.1e es la versión original, y en el caso de una actualización adaptada, se mantiene exactamente donde está. El parte 16.el6_5.7 es la versión del paquete de la distribución, y cambia cada vez que la distribución lanza una compilación revisada.

Cómo funciona el backporting

Un responsable del mantenimiento identifica la corrección en el código original, la aísla del resto de cambios, la adapta a un código base que ha evolucionado, comprueba que no haya regresiones y la distribuye a través del canal de actualización habitual, manteniendo intacto el número de versión del código original.

Mantener ese número de versión de origen es una decisión tan deliberada como la propia corrección. Indica que, en el fondo, el paquete sigue siendo la misma versión, conservando su API y su comportamiento general fuera de la ruta de código parcheada. Solo cambia el identificador de versión de la distribución.

1. Identificar la solución en la fase previa

Alguien informa de un fallo, los responsables del mantenimiento del proyecto original escriben una corrección y esta se incluye en una versión más reciente. El equipo de seguridad de la distribución tiene que identificar el cambio exacto —o el conjunto de cambios— que corrige el fallo, y no solo la versión que lo contiene.

Esto es más complicado de lo que parece. Los proyectos de origen no siempre publican una corrección de seguridad en forma de un único commit limpio e aislado. Puede estar repartida en tres commits, incluida en una refactorización más amplia o fusionada con un mensaje impreciso antes de que se haga público el CVE. Los equipos de seguridad supervisan continuamente los repositorios de origen, las listas de correo y los feeds de CVE para detectar estos casos.

El resultado de este paso es un parche, a veces creado a partir de varias confirmaciones, además de una comprensión clara de qué líneas concretas corrigen el fallo y por qué. Todo lo que viene después depende de que esto se haga bien: si se omite la mitad de la corrección, se distribuirá un paquete que, aunque se presente como parcheado, en realidad no lo está.

2. Aíslalo de los cambios que no estén relacionados

La corrección del desarrollador original llega mezclada con todo lo demás de esa versión: nuevas funciones, refactorizaciones, cambios en los valores predeterminados y actualizaciones de dependencias. El responsable del mantenimiento elimina todo eso.

Lo que quede debería ser el cambio mínimo necesario para solucionar el fallo, nada más. Esa es precisamente la ventaja principal del backporting. Obtienes la corrección de seguridad sin la nueva sintaxis de configuración que hace que tu rol de Ansible deje de funcionar.

Consejo de experto: Algunos registros de cambios de las distribuciones indican la versión o la confirmación del proyecto original de la que procede una corrección adaptada. Cuando lo hacen, esa referencia muestra el origen de la corrección, no lo que está instalado. Tu paquete se mantiene en su versión original del proyecto, y solo cambia el número de versión de la distribución. Los auditores suelen confundir ambos conceptos, así que señala la diferencia una sola vez en tu dossier de pruebas y no tendrás que explicarla cinco veces durante la revisión.

El aislamiento también requiere criterio. Decidir qué líneas pertenecen realmente a la corrección implica comprender la propia vulnerabilidad, lo cual supone un reto mayor que aplicar un parche que se haya escrito para el código que tienes delante.

3. Adaptarlo al código fuente anterior

Ahora hay que reescribir el parche para que se adapte. Las firmas de las funciones son diferentes, las estructuras de datos han cambiado de forma y es posible que las funciones auxiliares aún no existan en el árbol anterior. Una corrección que afecta a una función cuyo nombre se cambió hace dos versiones no se puede aplicar tal cual.

El responsable del mantenimiento vuelve a implementar la misma lógica defensiva utilizando lo que ofrece el código fuente anterior. Cuando los dos árboles no se han alejado mucho entre sí, puede ser un trabajo rápido. Cuando llevan años divergiendo, puede suponer una reimplementación considerable y, a veces, ni siquiera es posible llevarla a cabo, lo cual constituye una de las limitaciones reales que se tratan más adelante.

Un ejemplo práctico: una corrección autónoma que añade una comprobación de límites suele ser fácil de adaptar. Una corrección que resuelve una condición de carrera cambiando el modelo de bloqueo es mucho más difícil, ya que es posible que el código antiguo no cuente con las primitivas de bloqueo de las que depende la corrección. En ese caso, el responsable del mantenimiento tiene que resolver el mismo problema de seguridad de otra manera.

Por eso, «¿quién se encarga de tus versiones retrocompatibles?» es una pregunta real en materia de contratación y no un eslogan de marketing. La competencia del equipo que realiza este trabajo determina si tu sistema «actualizado» está realmente actualizado.

4. Comprueba que el comportamiento no cambie

El paquete parcheado se compila y se prueba según dos criterios: que el fallo se haya solucionado y que la corrección no haya provocado regresiones no deseadas.

La segunda mitad es la prueba más difícil. Aquí se ejecutan las suites de regresión, las comprobaciones de compatibilidad con ABI y las pruebas de integración, ya que el objetivo fundamental de un backport es que pueda seguir el ciclo habitual de parches en lugar de convertirse en un proyecto de migración. Si se incumple esa promesa una sola vez, los clientes dejarán de confiar en el canal de actualizaciones.

Las distribuciones empresariales dedican grandes esfuerzos a garantizar la compatibilidad ABI de los paquetes de bibliotecas, para que una adaptación a versiones anteriores no modifique de forma inadvertida un símbolo del que depende la aplicación compilada de un cliente. RHEL, por ejemplo, publica compromisos explícitos de compatibilidad de API y ABI para sus versiones. Esa disciplina es una de las principales razones por las que las versiones con soporte a largo plazo siguen siendo utilizables durante una década.

Atención: Un backport que haya sido validado frente a la vulnerabilidad no tiene por qué haber sido validado frente a tu aplicación. Las pruebas de regresión del proveedor abarcan el propio paquete. Mantén tus propias pruebas de verificación en la ruta crítica.

5. Enviarlo sin modificar la versión de origen

El paquete se distribuye a través del repositorio habitual. La versión original permanece exactamente igual, y lo que cambia es el sufijo de la versión de la distribución.

openssl-1.0.1e-16.el6_5.4 se convierte en openssl-1.0.1e-16.el6_5.7. Para tu gestor de paquetes, se trata de una actualización rutinaria. Sin embargo, para un escáner basado en versiones que compare «1.0.1e» con una base de datos CVE de origen que indique «corregido en 1.0.1g», parecerá que no has hecho absolutamente nada.

Esa discrepancia es una decisión deliberada en materia de compatibilidad que conlleva un efecto secundario conocido en la generación de informes, y constituye una de las fuentes más habituales de falsos positivos en la detección de vulnerabilidades en entornos Linux.

Retrocompatibilidad frente a actualización

Ambas solucionan el problema. En casi todo lo demás son diferentes.

	Retrocompatibilidad	Actualización
Lo que obtienes	Correcciones específicas, sin pasar a una versión más reciente del proyecto original	Las correcciones, las nuevas funciones, los valores predeterminados modificados y las API alteradas
Repercusiones en la estabilidad	Diseñado para mantener el comportamiento actual	El comportamiento puede variar, por lo que es necesario realizar pruebas
Un esfuerzo por ti	Actualización rutinaria del paquete	Pruebas de compatibilidad, migración de la configuración, posibles cambios en el código
Riesgo de rotura	Menor que una actualización importante, pero no nula	De moderado a alto, dependiendo de la diferencia entre versiones
¿Quién realiza el trabajo?	Distribuidor o proveedor de asistencia técnica	Tu equipo
Cuánto tiempo dura	Hasta que quien se encargue de los backports deje de hacerlo	Hasta que la versión recién actualizada alcance su propio fin de vida útil

La actualización puede aportar un refuerzo de seguridad más amplio, configuraciones predeterminadas más seguras y mejoras arquitectónicas, además de la corrección concreta que necesitabas. El retroportado te permite obtener esa corrección específica con el menor número posible de cambios colaterales. Esa disyuntiva es una de las principales razones por las que las versiones con soporte a largo plazo prefieren un mantenimiento específico en lugar de rebasamientos frecuentes.

La balanza se inclina cuando la diferencia entre versiones se hace lo suficientemente grande. Una cadena de retroportabilidad que ha mantenido un paquete intacto durante ocho años acumula muchas divergencias, y llega un momento en que la migración puede ser la opción más práctica. La cuestión es si puedes elegir el momento adecuado, y nuestra comparación entre el «fin de vida útil» y el «fin del soporte técnico» aborda los factores que determinan esa decisión.

¿Por qué los escáneres señalan las correcciones retroaplicadas?

Algunos escáneres basados en versiones comparan la versión del paquete detectada con las versiones de corrección de CVE del desarrollador original. Tu paquete indica 1.0.1e. La base de datos indica que Heartbleed se corrigió en la versión 1.0.1g. El escáner te señala como vulnerable. Si ese veredicto se basa únicamente en la cadena de versión, se trata de un falso positivo, ya que el escáner nunca ha tenido en cuenta la corrección retroportada. La propia documentación de seguridad de Red Hat señala precisamente este comportamiento.

Aquí tienes el ejemplo resuelto, de principio a fin.

Lo que ve cada parte	Valor
Tu paquete instalado	openssl-1.0.1e-16.el6_5.7
Versión de corrección previa para CVE-2014-0160	1.0.1g
Veredicto del escáner «ingenuo»	Vulnerable
Situación actual	Corregido mediante RHSA-2014:0376

Compruébalo tú mismo, empezando por el registro de cambios. Comprueba si el paquete instalado contiene el CVE:

rpm -q –changelog openssl | grep CVE-2014-0160

Si aparece el CVE, es una prueba clara de que la corrección está incluida, y el aviso de seguridad de la distribución es donde puedes confirmarlo. La misma comprobación sirve para un archivo RPM que aún no se haya instalado:

rpm -qp kernel-3.10.0-862.11.6.el7.x86_64.rpm –changelog | grep CVE-2017-12190

En Debian y Ubuntu, el equivalente es el registro de cambios de Debian:

zcat /usr/share/doc/openssl/changelog.Debian.gz | grep CVE-2014-0160

Swap in whatever package you’re checking. Most Debian and Ubuntu packages ship this file at /usr/share/doc/<package>/changelog.Debian.gz. Don’t confuse it with changelog.gz, which is normally the upstream changelog. Debian’s own package changes, backports included, are recorded in changelog.Debian.gz. Minimal and container images often strip /usr/share/doc entirely, and in that case apt changelog <package> fetches the changelog from the archive instead.

Consulta tres fuentes, ya que responden a preguntas diferentes. El aviso de seguridad de la distribución es la referencia para saber qué versión de un paquete corrige un CVE concreto, y tanto Red Hat como Canonical y Debian publican páginas específicas para cada CVE en las que se enumeran las versiones exactas de los paquetes corregidos. Los metadatos y el registro de cambios del paquete instalado te indican qué hay realmente en el servidor y, por lo general, mencionan los CVE que corrige esa versión, lo que los convierte en una primera comprobación rápida. Los feeds legibles por máquina están pensados para tus herramientas. Formatos como OVAL y, cuando el proveedor los publica, datos VEX o CSAF permiten a los escáneres utilizar la propia evaluación de la distribución en lugar de hacer conjeturas a partir de una cadena de versión. Si tu escáner los admite, actívalos.

La solución estructural consiste en utilizar herramientas que determinen el estado real del parche, en lugar de basarse únicamente en la coincidencia de versiones de origen.TuxCare Radar se ha diseñado para funcionar junto con tus escáneres actuales y cubrir esta carencia específica. Reconoce los backports de las distribuciones, los parches sin reinicio de KernelCare y las actualizaciones de ELS, de modo que un host parcheado se muestra como tal, y puede exportar la evidencia cuando alguien solicite una prueba.

Consejo profesional: Antes de rebatir un hallazgo ante un auditor, exporta la línea del registro de cambios y la URL del aviso de la distribución juntas. «El CVE aparece en el registro de cambios del paquete y el aviso del proveedor confirma esta versión» pone fin a la conversación. «Confía en mí, está retroportado» no lo hace.

¿Quién se encarga de aplicar las correcciones a versiones anteriores y durante cuánto tiempo?

Normalmente, hay tres grupos que se encargan de esta labor: los proyectos de origen con ramas estables que cuentan con soporte, los equipos de seguridad de las distribuciones y los proveedores de soporte ampliado. Es precisamente en los traspasos entre ellos donde los entornos quedan expuestos.

Los proyectos de origen suelen mantener un número reducido de ramas con soporte, que a veces incluyen una rama LTS de mayor duración, e incorporan correcciones de forma selectiva en ellas. Una vez que una rama queda fuera de ese periodo de soporte, dejan de hacerlo.

Los equipos de seguridad de las distribuciones incorporan estas actualizaciones en las versiones que distribuyen, durante el periodo de soporte. Las versiones principales actuales de RHEL cuentan con diez años de «Soporte completo» y «Soporte de mantenimiento», y Red Hat ofrece una cobertura ampliada más allá de ese plazo. RHEL 7 se encuentra en el complemento ELS más antiguo, mientras que RHEL 8.10 y versiones posteriores pasan a «Extended Life Cycle Premium». Ubuntu LTS cuenta con cinco años de mantenimiento de seguridad estándar, hasta diez con Ubuntu Pro y hasta 15 con el complemento de pago «Legacy» de Canonical.

Proveedores de soporte ampliado se hacen cargo a partir de ahí, y solo si lo compras. A veces se trata del propio programa de pago del proveedor original y, otras veces, de un tercero.

Las fechas son definitivas y, en el caso de muchos sistemas de producción, ya han vencido. La información está actualizada a septiembre de 2026:

Comunicado	Fin del soporte técnico estándar	Situación actual
Python 2.7	1 de enero de 2020	No hay correcciones de seguridad
Ubuntu 16.04	30 de abril de 2021 (el ESM finalizó en mayo de 2026)	Solo para el complemento de pago «Legacy», hasta mayo de 2031
CentOS Linux 8	31 de diciembre de 2021	No hay actualizaciones de origen
PHP 7.4	28 de noviembre de 2022	No hay correcciones de seguridad
Ubuntu 18.04	31 de mayo de 2023 (Ubuntu Pro ESM hasta mayo de 2028)	Solo ESM
PHP 8.0	26 de noviembre de 2023	No hay correcciones de seguridad
CentOS Linux 7	30 de junio de 2024	No hay actualizaciones de origen
RHEL 7	30 de junio de 2024 (Red Hat ELS hasta mayo de 2029)	Solo soporte técnico ampliado de pago
Ubuntu 20.04	31 de mayo de 2025 (Ubuntu Pro ESM hasta mayo de 2030)	Solo ESM
PostgreSQL 13	13 de noviembre de 2025	No hay correcciones de seguridad
PHP 8.1	31 de diciembre de 2025	No hay correcciones de seguridad

Una vez que una versión supera ese límite, dejan de llegar correcciones a través del canal de actualización estándar. A partir de ese momento, la protección depende de un programa de soporte ampliado de pago, ya sea del proveedor original o de un tercero, o bien del mantenimiento interno.

El servicio «Endless Lifecycle Support» (ELS) de TuxCare cubre ese periodo. El ELS sigue proporcionando correcciones de seguridad retrocompatibles para sistemas operativos, entornos de ejecución, ecosistemas de lenguajes y aplicaciones una vez finalizado su soporte estándar, a través del mismo gestor de paquetes que ya se utiliza.

Consulta la lista completa de tecnologías compatibles. Para conocer con más detalle el proceso de aplicación de parches, este documento técnico lo explica con más detalle.

Retos y límites del backporting

Los códigos fuente se van distanciando. Con cada año que pasa, el árbol más antiguo se parece cada vez menos al más reciente. Un parche que se aplicó sin problemas en el segundo año puede requerir una reimplementación considerable para el séptimo año, por lo que el trabajo se vuelve más difícil y lento a medida que el código envejece.

Las pruebas también se vuelven más complejas. Cada nueva adaptación tiene que validarse con respecto a un código base que puede contener ya años de adaptaciones anteriores y otros cambios de versiones posteriores, y esos cambios pueden interactuar entre sí. Cuantas más modificaciones acumula una rama, más hay que comprobar en las pruebas de regresión.

Hay correcciones que no se pueden retroaplicar directamente en absoluto. Cuando el proyecto original corrige una vulnerabilidad cambiando la arquitectura —por ejemplo, con un nuevo modelo de memoria, un sistema de permisos rediseñado o un analizador sintáctico reescrito—, puede que no exista un parche independiente que permita adaptarla. Las opciones del proveedor son aplicar una medida de mitigación personalizada que logre el mismo resultado de seguridad por otros medios, o declarar con franqueza que la vulnerabilidad no se puede corregir en esa rama. Ambas opciones son legítimas. El silencio, no.

Y, por definición, una adaptación a versiones anteriores tiene un alcance limitado. Soluciona el fallo específico, pero no aporta el refuerzo general de la seguridad, los valores predeterminados más seguros ni la eliminación de las rutas de código heredadas que podría incluir una nueva versión principal. Una versión anterior puede incluir una corrección para cada CVE que haya abordado su responsable de mantenimiento y, aun así, conservar código heredado y limitaciones de seguridad que las versiones más recientes hayan eliminado o rediseñado desde entonces.

La calidad de la adaptación a versiones anteriores depende totalmente de quién se encargue del mantenimiento de los parches. Ese es un criterio fundamental a la hora de elegir una distribución o un proveedor de soporte ampliado, así que pregunta por los plazos de adaptación, las prácticas de pruebas de regresión y qué ocurre cuando no es posible adaptar una corrección. Esas respuestas son más importantes que una lista de características y influyen directamente en cómo gestionas las vulnerabilidades y estableces la política de priorización de las mismas.

Sigue disfrutando de las adaptaciones tras el fin de vida útil con TuxCare

El backporting solo te protege mientras alguien siga realizándolo. Cuando finaliza el soporte estándar, dejan de llegar correcciones a través del canal de actualización habitual, a menos que se haya contratado un soporte ampliado. El sistema sigue funcionando y siguen apareciendo vulnerabilidades (CVE); a partir de ese momento, la protección depende de la migración o de un proveedor de soporte ampliado.

El soporte de ciclo de vida ilimitado de TuxCare garantiza el suministro continuo de parches de seguridad para sistemas operativos, entornos de ejecución, ecosistemas de lenguajes y aplicaciones que han llegado al final de su vida útil (EOL), mucho después de que haya finalizado el soporte estándar del desarrollador original o del proveedor.

Descubre cómo es la cobertura para tu pila, o haznos una pregunta sobre una versión concreta que va a dejar de estar disponible.

Preguntas frecuentes