Qu'est-ce que le « backporting » ? Processus, éléments à prendre en compte, conseils et plus encore

Principaux enseignements

• Le « backporting » consiste à intégrer un correctif issu d'une version plus récente dans la version plus ancienne que vous utilisez, sans passer par une mise à jour en amont.
• Red Hat a corrigé la faille Heartbleed dans OpenSSL 1.0.1e sans modifier la version en amont ; par conséquent, les outils de détection basés uniquement sur la version la signalent quand même.
• Vérifiez qu'il s'agit bien d'un backport en consultant l'avis de la distribution et le journal des modifications du paquet, et non en vous basant sur le numéro de version.
• À l'issue de la période de support standard, les correctifs dépendent du support étendu, d'une branche dérivée maintenue ou de votre propre équipe.

Votre scanner indique que le serveur utilise une version vulnérable d’OpenSSL. Votre administrateur système affirme qu'elle a été corrigée le mois dernier. Tous deux examinent le même hôte et analysent le même paquet, mais un seul d'entre eux a raison concernant la vulnérabilité. Ce désaccord est dû à un problème de rétroportage. Un correctif issu d'une version plus récente a été appliqué à la version encore en service, mais le numéro de version en amont n'a jamais changé. Sous environnements Linux d’entreprise , la recherche de ce genre de fausses alertes peut prendre plus de temps que certaines vulnérabilités réelles.

Cet article explique ce qu'est le « backporting », pourquoi le numéro de version reste inchangé après l'intégration d'un correctif, pourquoi cela pose problème aux outils de vérification basés sur les versions, comment vérifier soi-même un correctif, et qui assure la poursuite des backports une fois qu'une version arrive en fin de vie.

Qu'est-ce que le « backporting » ?

Le « backporting » consiste à extraire d'une version plus récente d'un logiciel un correctif destiné à corriger une faille de sécurité, puis à l'appliquer à une version plus ancienne qui est toujours en service. La vulnérabilité est ainsi corrigée sans qu'il soit nécessaire de passer à une version en amont plus récente et d'en intégrer toutes les modifications qui n'ont aucun rapport avec le problème.

Mais qu'est-ce que le « backport » signifie concrètement ? Voici un exemple concret. Les responsables d'OpenSSL ont corrigé la vulnérabilité Heartbleed dans la version 1.0.1g. Les clients de Red Hat utilisaient la version 1.0.1e, et les faire passer à la version 1.0.1g aurait entraîné l’application de toutes les autres modifications apportées entre ces deux versions. Red Hat a donc effectué un backport de la seule correction Heartbleed vers son code source 1.0.1e et a publié openssl-1.0.1e-16.el6_5.7 dans le cadre de l’avis RHSA-2014:0376. Même base de fonctionnalités en amont, même comportement en dehors du chemin d’exécution corrigé, et plus aucune vulnérabilité Heartbleed.

Depuis deux décennies, le portage en amont des correctifs de sécurité de cette manière est une pratique courante dans la plupart des distributions Linux, notamment RHEL, Ubuntu, Debian, SUSE et leurs dérivés. Exécutez « dnf update » sur un hôte RHEL et vous constaterez que bon nombre des correctifs installés sont des rétroportages.

Le saviez-vous ? C'est grâce au champ « release » à la fin que l'on reconnaît une version rétroportée. Dans openssl-1.0.1e-16.el6_5.7, 1.0.1e correspond à la version en amont, et dans le cas d'une mise à jour rétroportée, elle reste exactement à sa place. Le partie 16.el6_5.7 correspond à la version du paquet de la distribution, et elle change chaque fois que la distribution publie une version révisée.

Comment fonctionne le backporting ?

Un responsable de maintenance identifie le correctif en amont, l'isole de toutes les autres modifications, l'adapte à une base de code qui a évolué, vérifie l'absence de régressions, puis le diffuse via le canal de mise à jour habituel en conservant le numéro de version d'origine.

Le fait de conserver ce numéro de version en amont est tout aussi délibéré que le correctif lui-même. Cela indique que le paquet correspond toujours à la même version à la base, son API et son comportement général étant préservés en dehors du chemin d'exécution corrigé. Seul l'identifiant de version de la distribution change.

1. Identifier la solution en amont

Quelqu'un signale une faille, les responsables du projet en amont rédigent un correctif, et celui-ci est intégré à une nouvelle version. L'équipe de sécurité de la distribution doit identifier précisément la modification, ou l'ensemble des modifications, qui corrige la faille, et pas seulement la version qui la contient.

C'est plus difficile qu'il n'y paraît. Les projets en amont ne publient pas toujours un correctif de sécurité sous la forme d'un commit unique, propre et isolé. Celui-ci peut être réparti sur trois commits, intégré à une refactorisation plus vaste, ou fusionné avec un message vague avant que le CVE ne soit rendu public. Les équipes de sécurité surveillent en permanence les dépôts en amont, les listes de diffusion et les flux CVE afin de repérer ces éléments.

Cette étape aboutit à un correctif, parfois constitué de plusieurs commits, ainsi qu’à une compréhension claire des lignes qui corrigent précisément la faille et des raisons pour lesquelles elles le font. Tout ce qui suit dépend de la justesse de cette étape : si la moitié de la correction est omise, vous livrerez un paquet qui prétend être corrigé alors qu’il ne l’est pas.

2. L'isoler des modifications sans rapport avec celle-ci

Le correctif en amont arrive mêlé à tout le reste de cette version : nouvelles fonctionnalités, refactorisations, modifications des paramètres par défaut, mises à jour des dépendances. Le responsable du projet élimine tout cela.

Ce qui reste doit correspondre à la modification minimale nécessaire pour corriger la faille, rien de plus. C'est là tout l'intérêt du backport. Vous bénéficiez du correctif de sécurité sans la nouvelle syntaxe de configuration qui perturbe le fonctionnement de votre rôle Ansible.

Astuce d'initié : Certains journaux de modifications des distributions mentionnent la version en amont ou le commit d’où provient un correctif rétroporté. Dans ce cas, cette référence indique l’origine du correctif, et non ce qui est installé. Votre paquet conserve sa version en amont d’origine, seul le numéro de version de la distribution change. Les auditeurs confondent souvent les deux, alors précisez cette différence une seule fois dans votre dossier de preuves, et vous n’aurez pas à l’expliquer cinq fois lors de l’examen.

L'isolation nécessite également un certain discernement. Déterminer quelles lignes font réellement partie du correctif implique de bien comprendre la vulnérabilité elle-même, ce qui représente un défi plus important que appliquer un correctif conçu pour le code qui se trouve devant vous.

3. L'adapter à l'ancienne base de code

Le correctif doit désormais être réécrit pour s'adapter à ces changements. Les signatures des fonctions diffèrent, les structures de données ont changé de forme et certaines fonctions d'aide n'existent peut-être pas encore dans l'ancienne arborescence. Une correction qui concerne une fonction renommée il y a deux versions ne peut pas être appliquée telle quelle.

Le responsable de la maintenance réimplémente la même logique défensive en s'appuyant sur ce que fournit l'ancienne base de code. Lorsque les deux arborescences ne se sont pas trop éloignées l'une de l'autre, cela peut se faire rapidement. En revanche, lorsqu'elles ont divergé pendant des années, cela peut impliquer un travail de réimplémentation considérable, voire s'avérer impossible dans certains cas, ce qui constitue l'une des véritables limites abordées plus loin.

Exemple concret : un correctif autonome qui ajoute un contrôle des limites est généralement simple à porter. Un correctif qui résout une condition de concurrence en modifiant le modèle de verrouillage est beaucoup plus difficile à mettre en œuvre, car l'ancien code peut ne pas disposer des primitives de verrouillage dont dépend le correctif. Le responsable de la maintenance doit alors résoudre le même problème de sécurité d'une autre manière.

C'est pourquoi la question « qui gère vos backports ? » relève véritablement des achats et n'est pas un simple argument marketing. C'est le niveau de compétence de l'équipe chargée de cette tâche qui détermine si votre système « corrigé » l'est réellement.

4. Vérifier que le comportement ne change pas

Le paquet corrigé est compilé et testé selon deux critères : la faille est corrigée et la correction n'a entraîné aucune régression imprévue.

La seconde partie constitue le véritable défi. C'est là que s'exécutent les suites de régression, les vérifications de compatibilité ABI et les tests d'intégration, car l'intérêt d'un backport réside précisément dans le fait qu'il puisse s'inscrire dans votre cycle habituel de correctifs, sans se transformer en projet de migration. Si vous ne respectez pas cette promesse ne serait-ce qu'une seule fois, les clients cesseront de faire confiance au canal de mise à jour.

Les distributions d'entreprise consacrent des efforts considérables à la compatibilité ABI des paquets de bibliothèques, afin qu'un portage vers une version antérieure ne modifie pas subrepticement un symbole dont dépend l'application compilée d'un client. RHEL, par exemple, publie des engagements explicites en matière de compatibilité API et ABI pour ses versions. Cette rigueur explique en grande partie pourquoi les versions bénéficiant d'un support à long terme restent utilisables pendant une décennie.

Attention : Un backport qui a été validé pour cette faille n’a pas nécessairement été validé pour votre application. Les tests de régression effectués par le fournisseur portent sur le paquet lui-même. Continuez à effectuer vos propres tests de vérification sur le chemin critique.

5. Le publier sans modifier la version en amont

Le paquet est publié via le dépôt habituel. La version en amont reste exactement la même, et seul le suffixe de version de la distribution change.

openssl-1.0.1e-16.el6_5.4 devient openssl-1.0.1e-16.el6_5.7. Pour votre gestionnaire de paquets, il s’agit d’une mise à jour de routine. Pour un scanner basé sur les versions qui compare « 1.0.1e » à une base de données CVE en amont indiquant « corrigé dans la version 1.0.1g », c’est comme si vous n’aviez rien fait du tout.

Cette incompatibilité résulte d'un choix délibéré en matière de compatibilité, dont on connaît les effets secondaires sur la génération de rapports, et elle constitue l'une des sources les plus courantes de faux positifs dans les résultats de détection de vulnérabilités dans les environnements Linux.

Rétroportage ou mise à niveau ?

Les deux corrigent cette faille. Elles diffèrent sur presque tous les autres points.

	Portage vers les versions antérieures	Mise à niveau
Ce que vous obtenez	Corrections ciblées, sans passer à une version en amont plus récente	Les corrections, les nouvelles fonctionnalités, les modifications des paramètres par défaut et les changements apportés aux API
Impact sur la stabilité	Conçu pour préserver le comportement actuel	Le comportement pouvant évoluer, il est nécessaire de procéder à des tests.
Un effort pour toi	Mise à jour régulière des paquets	Tests de compatibilité, migration de la configuration, modifications éventuelles du code
Risque de casse	Moins importante qu'une mise à niveau majeure, mais pas nulle	Modéré à élevé, selon l'écart entre les versions
Qui effectue le travail ?	Distributeur ou prestataire de services d'assistance	Votre équipe
Combien de temps ça tient ?	Jusqu'à ce que la personne chargée de la maintenance des backports cesse ses activités	Jusqu'à ce que la nouvelle version mise à jour atteigne sa propre fin de vie (EOL)

Une mise à niveau peut apporter un renforcement général de la sécurité, des paramètres par défaut plus sûrs et des améliorations architecturales, en plus du correctif dont vous aviez besoin. Le « backport » vous permet d'obtenir le correctif spécifique avec le moins de changements collatéraux possible. Ce compromis explique en grande partie pourquoi les versions à support à long terme privilégient une maintenance ciblée plutôt que des rebasages fréquents.

La donne change lorsque l'écart entre les versions devient suffisamment important. Une chaîne de rétroportage qui a permis de maintenir un paquet à jour pendant huit ans accumule de nombreuses divergences, et à un certain moment, la migration peut s'avérer être l'option la plus pratique. La question est de savoir si vous pouvez choisir le moment opportun, et notre comparaison entre « fin de vie » et « fin de support » aborde les facteurs qui déterminent cette décision.

Pourquoi les scanners signalent-ils les correctifs rétroportés ?

Certains scanners basés sur les versions comparent la version du paquet détectée aux versions de correction CVE en amont. Votre paquet indique la version 1.0.1e. La base de données indique que la faille Heartbleed a été corrigée dans la version 1.0.1g. Le scanner signale alors que vous êtes vulnérable. Si ce verdict repose uniquement sur la chaîne de version, il s’agit d’un faux positif, car le scanner n’a jamais pris en compte la correction rétroportée. La documentation de sécurité de Red Hat elle-même met en évidence ce comportement précis.

Voici l'exemple détaillé, de A à Z.

Ce que voit chaque partie	Valeur
Votre paquet installé	openssl-1.0.1e-16.el6_5.7
Version de correction en amont pour la vulnérabilité CVE-2014-0160	1.0.1g
Verdict du scanner naïf	Vulnérable
Situation actuelle	Correctif appliqué via RHSA-2014:0376

Vérifiez-le vous-même, en commençant par le journal des modifications. Vérifiez si le paquet installé contient la vulnérabilité CVE :

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

Si le CVE apparaît, c'est un indice fort que le correctif est inclus, et c'est dans l'avis de sécurité de la distribution que vous pouvez le vérifier. La même vérification s'applique à un fichier RPM qui n'est pas encore installé :

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

Sous Debian et Ubuntu, l'équivalent est le journal des modifications 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.

Vérifiez trois sources, car elles répondent à des questions différentes. L’avis de sécurité de la distribution fait autorité quant au paquet dont la version corrige un CVE donné, et Red Hat, Canonical et Debian publient tous des pages dédiées à chaque CVE répertoriant les versions exactes des paquets corrigés. Les métadonnées et le journal des modifications du paquet installé vous indiquent ce qui se trouve réellement sur l’hôte et mentionnent généralement les CVE auxquels la version correspond, ce qui en fait une première vérification rapide. Les flux lisibles par machine sont destinés à vos outils. Des formats tels que OVAL et, lorsque le fournisseur les publie, les données VEX ou CSAF permettent aux scanners d’utiliser l’évaluation propre à la distribution plutôt que de se baser sur une chaîne de version. Si votre scanner les prend en charge, activez-les.

La solution structurelle consiste à mettre en place un outil permettant de déterminer l'état réel des correctifs, plutôt que de se fier uniquement à la correspondance des versions en amont.TuxCare Radar a été conçu pour fonctionner en complément de vos scanners existants afin de combler cette lacune spécifique. Il reconnaît les backports des distributions, les correctifs sans redémarrage de KernelCare et les mises à jour ELS ; ainsi, un hôte corrigé est signalé comme tel, et il est possible d’exporter les justificatifs lorsque quelqu’un en fait la demande.

Conseil de pro : Avant de contester une constatation auprès d'un auditeur, exportez à la fois la ligne du journal des modifications et l'URL de l'avis de distribution. « Le CVE figure dans le journal des modifications du paquet et l'avis du fournisseur confirme cette version » met fin à la discussion. « Faites-moi confiance, c'est rétroporté » n'y parvient pas.

Qui assure la rétroportabilité des correctifs, et pendant combien de temps ?

Trois types d'acteurs se chargent généralement de cette tâche : les projets en amont disposant de branches stables prises en charge, les équipes de sécurité des distributions et les fournisseurs proposant une assistance étendue. C'est lors des transferts entre ces différents acteurs que les parcs informatiques sont exposés à des risques.

Les projets en amont généralement, un petit nombre de branches prises en charge, comprenant parfois une branche LTS à durée de vie plus longue, et y intègrent des corrections de manière sélective. Dès qu’une branche sort de cette période de prise en charge, ces opérations cessent.

Les équipes de sécurité des distributions intègrent ces correctifs dans les versions qu’elles commercialisent, pendant toute la durée de la période de support. Les versions majeures actuelles de RHEL bénéficient de dix ans de support complet et de support de maintenance, et Red Hat propose une couverture étendue au-delà de cette période. RHEL 7 relève de l’ancienne option ELS, tandis que RHEL 8.10 et les versions ultérieures passent à l’option Extended Life Cycle Premium. Ubuntu LTS bénéficie de cinq ans de maintenance de sécurité standard, jusqu’à dix ans avec Ubuntu Pro, et jusqu’à 15 ans avec le module complémentaire payant « Legacy » de Canonical.

Fournisseurs proposant une assistance prolongée prennent le relais par la suite, mais uniquement si vous achetez ce service. Il s'agit parfois du programme payant proposé par le fournisseur d'origine, et parfois d'un service proposé par un tiers.

Les dates sont définitives et sont déjà dépassées pour de nombreux systèmes de production. Ces informations sont à jour en septembre 2026 :

Communiqué	Fin du support standard	Situation actuelle
Python 2.7	1er janvier 2020	Aucune correction de sécurité
Ubuntu 16.04	30 avril 2021 (fin du MSE en mai 2026)	Uniquement avec l'extension payante Legacy, jusqu'en mai 2031
CentOS Linux 8	31 décembre 2021	Aucune mise à jour en amont
PHP 7.4	28 novembre 2022	Aucune correction de sécurité
Ubuntu 18.04	31 mai 2023 (ESM d'Ubuntu Pro jusqu'en mai 2028)	ESM uniquement
PHP 8.0	26 novembre 2023	Aucune correction de sécurité
CentOS Linux 7	30 juin 2024	Aucune mise à jour en amont
RHEL 7	30 juin 2024 (Red Hat ELS jusqu'en mai 2029)	Assistance étendue payante uniquement
Ubuntu 20.04	31 mai 2025 (ESM d'Ubuntu Pro jusqu'en mai 2030)	ESM uniquement
PostgreSQL 13	13 novembre 2025	Aucune correction de sécurité
PHP 8.1	31 décembre 2025	Aucune correction de sécurité

Dès qu'une version franchit cette étape, les correctifs ne sont plus diffusés via le canal de mise à jour standard. À partir de ce moment-là, la protection repose soit sur un programme de support étendu payant, proposé par le fournisseur d'origine ou par un tiers, soit sur une maintenance interne.

Le service « Endless Lifecycle Support » (ELS) de TuxCare couvre cette période. L'ELS continue de fournir des correctifs de sécurité rétroportés pour les systèmes d'exploitation, les environnements d'exécution, les écosystèmes de langages et les applications après la fin de leur support standard, via le même gestionnaire de paquets déjà utilisé.

Consultez la liste complète des technologies prises en charge. Pour en savoir plus sur le processus de mise à jour, ce livre blanc l'explique de manière plus détaillée.

Défis et limites du backporting

Les bases de code divergent. Au fil des années, l'arborescence la plus ancienne ressemble de moins en moins à la plus récente. Un correctif qui s'appliquait sans problème la deuxième année peut nécessiter une réimplémentation importante dès la septième année ; le travail devient donc plus difficile et plus lent à mesure que le code vieillit.

Les tests deviennent également plus lourds. Chaque nouveau backport doit être validé par rapport à une base de code qui peut déjà comporter des années de backports antérieurs et d’autres modifications en aval, et ces modifications peuvent interagir entre elles. Plus une branche accumule de modifications, plus il y a de tests de régression à effectuer.

Certaines corrections ne peuvent absolument pas être rétroportées directement. Lorsque le projet en amont corrige une faille en modifiant l’architecture — par exemple, avec un nouveau modèle de mémoire, un système d’autorisations repensé ou un analyseur syntaxique réécrit —, il se peut qu’il n’existe aucun correctif autonome à adapter. Le fournisseur a alors le choix entre une solution de contournement sur mesure, qui permet d’atteindre le même niveau de sécurité par d’autres moyens, ou une déclaration honnête indiquant que la faille ne peut pas être corrigée dans cette branche. Ces deux options sont légitimes. Le silence, en revanche, ne l’est pas.

Par définition, un backport a une portée limitée. Il corrige une faille spécifique. Il n’apporte pas le renforcement général de la sécurité, les paramètres par défaut plus sûrs ni la suppression des chemins de code hérités qu’une nouvelle version majeure pourrait inclure. Une version plus ancienne peut contenir un correctif pour chaque CVE traité par son responsable, tout en conservant du code hérité et des failles de sécurité que les versions plus récentes ont depuis supprimées ou repensées.

La qualité du portage vers les versions antérieures dépend entièrement de la personne chargée de la maintenance des correctifs. Il s’agit là d’un critère essentiel lors du choix d’une distribution ou d’un fournisseur proposant un support étendu ; renseignez-vous donc sur les délais de portage, les pratiques en matière de tests de régression et ce qui se passe lorsqu’un correctif ne peut pas être porté. Ces réponses sont plus importantes qu’une simple liste de fonctionnalités et ont une incidence directe sur la manière dont vous gérez les vulnérabilités et définissez votre politique de hiérarchisation de celles-ci.

Continuez à bénéficier de backports après la fin de vie (EOL) grâce à TuxCare

Le « backporting » ne vous protège que tant qu’il est encore pratiqué. Lorsque le support standard prend fin, les correctifs ne sont plus diffusés via le canal de mise à jour habituel, sauf si un support étendu est en place. Le système continue de fonctionner et les vulnérabilités (CVE) continuent d’apparaître : à partir de ce moment-là, la protection dépend soit d’une migration, soit d’un fournisseur de support étendu.

Le support à cycle de vie illimité de TuxCare assure la fourniture continue de correctifs de sécurité pour les systèmes d’exploitation, les environnements d’exécution, les écosystèmes de langages et les applications en fin de vie, bien après la fin du support standard assuré par les développeurs en amont ou les éditeurs.

Découvrez à quoi ressemble la couverture pour votre pile, ou posez-nous une question concernant une version spécifique en fin de vie.

FAQ