Les dépendances de votre composant ne disparaissent pas simplement parce que PHP a pris sa retraite

Principaux enseignements

• PHP publie les dates de fin de vie plusieurs années à l'avance, tandis que les paquets Composer ne donnent aucune information lorsqu'un responsable de maintenance cesse de se manifester.
• C'est souvent une dépendance obsolète qui est à l'origine d'un blocage lors de la mise à jour de PHP, et non une conséquence de celle-ci.
• composer why-not vous indique rapidement ce qui empêche votre prochaine mise à niveau d'environnement d'exécution.
• Composer peut détecter les paquets abandonnés, mais aucun outil de la chaîne d'outils ne les corrigera à votre place.

Une équipe a mis quatre mois à passer de PHP 8.1 à 8.3. Tests, environnement de préproduction, migration pendant le week-end… tout le processus. Ça marche.

Ensuite composer audit signale un paquet gérant les webhooks de paiement comme abandonné. Quelqu’un ouvre le dépôt et constate qu’il n’y a plus eu de commits depuis 2021. Pas de politique de fin de vie, pas d’avis de dépréciation, juste un projet qui a discrètement cessé de susciter de l’intérêt, enfoui à quatre niveaux de profondeur dans un arbre de dépendances que personne n’a lu de bout en bout.

Le runtime a été mis à jour. Le risque lié à la fin de vie du logiciel n’a pas évolué.

C'est dans cet écart entre « nous utilisons une version de PHP prise en charge » et « notre application est prise en charge » que se cache une grande partie de la dette de sécurité PHP, et celle-ci est bien plus difficile à repérer qu'un numéro de version dans php -v.

Le calendrier de fin de vie de PHP que tout le monde suit

La politique de publication de PHP est vraiment excellente, et c'est précisément grâce à cette prévisibilité que la fin de vie (EOL) en environnement d'exécution constitue la partie la plus simple de ce problème. Chaque branche bénéficie de deux ans de support actif, puis de deux années supplémentaires consacrées exclusivement aux problèmes de sécurité critiques.

Une précision à connaître avant de consulter le tableau : cette période de quatre ans ne s'applique qu'à partir de PHP 8.1, car le cycle de publication a été prolongé en 2024. Les versions antérieures ont bénéficié d'une seule année de correctifs de sécurité au lieu de deux, ce qui explique pourquoi les versions 7.4 et 8.0 apparaissent comme plus courtes dans le tableau ci-dessous.

Voici où en sont les choses à l'heure actuelle, d'après les informations confirmées sur la page officielle des versions prises en charge par PHP.

PHP 8.1 et 8.2 sont les deux versions qui méritent votre attention aujourd'hui. PHP 8.1 a atteint sa fin de vie en décembre 2025 ; par conséquent, tout ce qui fonctionne encore sous cette version n'a plus bénéficié de correctifs de sécurité en amont depuis plusieurs mois. La fin de vie de PHP 8.2 est prévue pour fin décembre 2026, et bien que la version 8.2 soit encore officiellement prise en charge aujourd’hui, toute équipe prévoyant de continuer à l’utiliser au-delà de cette date doit mettre en place une solution avant cette échéance.

Les équipes qui ne parviennent pas à effectuer la migration à temps peuvent appliquer les correctifs fournis par le fournisseur directement sur l'environnement d'exécution et continuer à bénéficier des correctifs de sécurité jusqu'à la fin de la migration. C'est ce qu'offre couvre le service « Endless Lifecycle Support for PHP » de TuxCare de TuxCare dès qu’une version de PHP arrive en fin de vie, tant que cette version reste présente dans votre infrastructure.

Remarque : Se trouver dans la période de sécurité uniquement ne revient pas à bénéficier d'un support actif. Les corrections de bogues régulières ont cessé. Les travaux sur les performances ont cessé. Les travaux de compatibilité ont cessé. Il ne reste plus que les correctifs de sécurité critiques sur une branche que les responsables de la version ont déjà abandonnée.

Pourquoi les dépendances Composer n'ont jamais de date de fin de vie

Presque personne ne publie de politique d'assistance pour un paquet qu'il a développé pendant un week-end en 2018.

C'est là que réside la véritable différence. PHP dispose d'un groupe de responsables des versions, d'une politique documentée et d'un calendrier sur lequel on peut s'appuyer pour planifier son travail. Un paquet Composer repose souvent sur une seule personne ou une petite équipe, et il arrive que ces personnes changent d'emploi, se désintéressent du projet ou soient accaparées par autre chose. Lorsque cela se produit, il n'y a pas d'annonce, car il n'y a jamais eu d'engagement à en faire une.

La perte de maintenance peut se manifester de plusieurs façons, dont une seule est facile à repérer. Un paquet signalé comme « abandonné » sur Packagist est le cas le plus simple, car Composer vous en avertit. Un dépôt archivé sur GitHub correspond à la même situation, mais sans aucun avertissement, et Composer ne dit rien à ce sujet.

Et puis il y a ce paquet dont la dernière version remonte à deux ou trois ans et dont les problèmes s'accumulent sans réponse, ce responsable qui est toujours présent mais qui a cessé de prendre en charge l'ancienne version majeure sur laquelle vous êtes coincé, ce paquet qui a été intégré à un autre projet sans redirection, et ce fork qui est discrètement devenu le véritable projet tandis que l'original a conservé son nom.

Un paquet qui, techniquement, est toujours présent, toujours installable, dont la résolution s'effectue toujours sans problème – et qui ne fait l'objet d'aucune attention en matière de sécurité – apparaît exactement comme un paquet en bon état depuis l'intérieur de votre composer.lock.

Comment savoir ce que vous utilisez réellement

Prévoyez quelques minutes par application. Le résultat n'est généralement pas très agréable à lire.

Commencez par ce que Composer connaît déjà.

audit des compositeurs

À partir de la version 2.4, Composer vérifie vos dépendances installées par rapport à l’API de notifications de Packagist, qui regroupe la base de données des avis de sécurité PHP et la base de données des avis de sécurité de GitHub. Ajoutez –locked si vous préférez vérifier le fichier composer.lock directement sans l’installer au préalable, ce qui est généralement le cas en CI. Les paquets abandonnés ont fait leur apparition dans Composer 2.6.3, et depuis la version 2.7, ils échouent par défaut à l’audit ; ainsi, une exécution propre sur un Composer moderne vous en apprend déjà davantage qu’auparavant.

Si vous souhaitez obtenir la liste des éléments abandonnés sans interrompre la compilation, la version 2.8 a introduit un indicateur prévu précisément à cet effet.

audit du compositeur – abandonné = rapport

Cela permet de faire passer les paquets abandonnés du statut « échec » à celui de « rapport », ce qui correspond généralement à ce que l'on souhaite en intégration continue (CI) pendant que la liste des tâches en attente est traitée.

Voyez maintenant à quel point vos dépendances directes sont réellement en retard.

composer show –outdated –direct

Le –direct joue un rôle important. Si vous ne l’utilisez pas, vous obtenez l’arborescence complète, où les informations utiles se noient dans le bruit. Les dépendances directes sont celles que vous avez choisies délibérément ; elles constituent donc le point de départ le plus pertinent pour agir. Ajoutez –sort-by-age et les versions les plus anciennes s’affichent en premier, ce qui permet de repérer plus rapidement celles qui sont véritablement obsolètes.

Si un paquet vous semble obsolète, vérifiez son état réel plutôt que de vous fier uniquement à son numéro de version.

composer show vendor/package

Cela permet d'extraire les métadonnées propres au paquet, notamment si Packagist l'a signalé comme abandonné et quelle solution de remplacement le responsable a proposée, s'il a pris la peine d'en suggérer une. Pour avoir une idée précise de l'activité de maintenance, des commits récents, des versions publiées, des tickets ouverts et savoir si les pull requests aboutissent à quelque chose, consultez directement le dépôt.

Pourquoi la mise à jour de PHP ne résout pas ce problème

Maintenant, inversons l'hypothèse habituelle. La dépendance abandonnée est généralement la raison pour laquelle vous utilisez encore une ancienne version de PHP, et non un symptôme de cette situation.

An unmaintained package requiring php: >=8.1 <8.3 will refuse to install on 8.4, and with nobody maintaining it, that upper bound never gets loosened. The upgrade stalls on a library that stopped receiving maintenance years ago.

Composer vous indiquera précisément quels paquets l'empêchent de fonctionner.

composer why-not php 8.4

Exécutez cette commande avant d'envisager toute mise à niveau du moteur d'exécution. Elle transforme l'affirmation « la migration vers PHP 8.4 est une grande inconnue » en une liste précise et généralement plus courte que prévu, sur laquelle figurent souvent un ou deux noms qui font taire toute l'assemblée.

Voici, en gros, ce que l'on obtient :

Le paquet « php » n'a pas pu être trouvé avec la contrainte « 8.4 » ; les résultats ci-dessous seront très probablement incomplets.

acme/webhook-handler 2.0.0 requires php (>=8.1 <8.3)

Vous n'avez pas trouvé ce que vous cherchiez ? Essayez d'exécuter la commande `composer require “php:8.4” –dry-run` pour avoir un autre point de vue sur le problème.

composer why-not vous fournit la liste brute, indiquant quels paquets et quelles contraintes. Ce que vous faites avec chacun d'entre eux dépend d'une vérification rapide, composer show vendor/package , ainsi qu’un coup d’œil au dépôt. Quatre cas de figure couvrent la quasi-totalité des situations que vous rencontrerez.

Intégrer une bibliothèque abandonnée dans votre propre dépôt signifie que votre équipe devient désormais responsable de ses CVE, et la plupart des équipes qui choisissent cette voie ne prévoient pas de personnel dédié à cette tâche. Le code est copié, mais la responsabilité qui va avec n'est pas transférée.

La correction des paquets Composer après l'abandon du projet en amont est une discipline pointue, et c'est précisément le problème SecureChain pour PHP a été conçu pour résoudre ce problème, plutôt que d’être une fonctionnalité que la plupart des équipes d’ingénierie souhaitent développer et maintenir en interne.

Qu'advient-il des correctifs de sécurité lorsque le développeur en amont cesse de s'en occuper ?

En amont, il ne se passe rien. C'est ce qu'il faut souligner, car de nombreuses équipes partent discrètement du principe qu'il existe un filet de sécurité quelque part.

Packagist n'applique pas de correctifs aux paquets. Les bases de données d'alertes répertorient les vulnérabilités, ce qui est utile mais ne revient pas à les corriger. Une alerte concernant un paquet Composer abandonné peut rester sans suite indéfiniment, sans version officielle corrigée vers laquelle effectuer la mise à jour, à moins que la maintenance ne reprenne ou qu'un fork ne reprenne le correctif.

À partir de là, vos options sont limitées. Vous pouvez créer une branche et corriger le problème vous-même, remplacer la dépendance, accepter le risque en mettant en place un contrôle compensatoire documenté, ou faire appel à quelqu’un dont le métier consiste justement à réintégrer les correctifs dans le code en amont qui ont été laissés de côté.

Remarque : Si vous modifiez un fork, choisissez délibérément la stratégie Composer. Pour une application, la procédure recommandée consiste à utiliser un dépôt VCS pointant vers votre fork, à conserver le nom d’origine du paquet et à définir la contrainte ciblant votre branche « dev » . Si vous publiez le fork sous votre propre nom, vous devrez remplacer, afin que tout ce qui nécessite l’original puisse toujours être résolu. Les alias en ligne constituent un piège. Il s’agit d’une fonctionnalité réservée au répertoire racine, ce qui signifie que le côté gauche de l’ « as » est ignoré pour tous ceux qui dépendent de votre paquet, et le problème apparaît généralement des mois plus tard dans l’environnement de CI de quelqu’un d’autre.

Décider de la marche à suivre pour chaque dépendance abandonnée

Il faut mettre en balance l'ampleur de l'impact et la gravité de la vulnérabilité. Une vulnérabilité touchant l'authentification, les paiements, le téléchargement de fichiers ou la désérialisation mérite une attention particulière, même s'il s'agit d'une vulnérabilité modérée. Cela vaut toutefois dans les deux sens. Une vulnérabilité critique et facilement exploitable dans un domaine moins médiatisé ne doit pas être négligée simplement parce que son ampleur semble plus restreinte.

Ensuite, passez la liste en revue. S’il existe une branche maintenue et que l’API est compatible, effectuez la migration, testez, puis passez à autre chose. Cela couvre davantage de cas que ce à quoi les équipes s’attendent parfois, même si l’effort nécessaire dépend de l’ampleur de l’évolution de l’API et de la couverture de test sur laquelle vous pouvez vous appuyer. Si le paquet est petit et que vous le comprenez réellement, intégrez-le et prenez en charge sa maintenance, mais précisez clairement qui en est responsable, car c’est précisément à cause d’un code intégré sans propriétaire que ce problème resurgit au bout de trois ans.

Si le paquet est volumineux, sensible sur le plan de la sécurité et que personne ne s'en occupe, réfléchissez-y à deux fois avant de l'intégrer à votre liste de fournisseurs. Il s'agit d'une obligation de correction à long terme pour laquelle votre équipe devra affecter du personnel, et une bibliothèque liée à la sécurité sans responsable est pire qu'une dépendance externe évidente.

Si une dépendance obsolète bloque une mise à niveau de PHP que vous avez déjà décidée, corrigez d'abord cette dépendance et considérez la mise à niveau en production comme la deuxième étape. Tenter de résoudre les deux problèmes en même temps transforme une migration en production ciblée en un projet de correction des dépendances bien plus vaste.

Et si des contraintes réglementaires ou contractuelles vous empêchent de suivre le calendrier imposé par l'amont, les correctifs fournis par les éditeurs, tant pour l'environnement d'exécution que pour les paquets concernés, constituent une autre solution. Cela permet de continuer à bénéficier des correctifs de sécurité tout en effectuant la migration selon un calendrier que l'entreprise est réellement en mesure de financer.

La complexité de l'opération variera considérablement en fonction de l'âge de l'application et du framework utilisé. Une application Laravel relativement récente, dont les dépendances sont activement maintenues, nécessite généralement une mise à niveau assez simple. En revanche, une application vieille de dix ans, reposant sur un framework maison et comportant quarante dépendances directes, représente un tout autre défi, et quiconque proposerait le même délai pour les deux cas n'a jamais utilisé « composer why-not » .

Vous pouvez également en savoir plus sur les bonnes pratiques en matière de sécurité avec Laravel et sur les mesures de prévention des menaces liées au framework dans notre guide dédié.

Sécurisation de la chaîne d'approvisionnement PHP

Les calendriers de fin de vie de PHP sont publiés plusieurs années à l'avance, et toute équipe disposant d'un agenda peut s'organiser en conséquence. Le plus gros problème réside dans votre fichier composer.lock en ce moment même : inopiné, imprévu et hors du contrôle de quiconque dès qu’un responsable de maintenance se retire.

Les outils fournis par Composer vous indiqueront les éléments obsolètes. Ils ne les corrigeront toutefois pas. C'est là que réside la lacune SecureChain pour PHP comble cette lacune : les paquets sont recompilés à partir du code source et filtrés avant d’intégrer votre environnement de compilation, puis surveillés et corrigés à mesure que des vulnérabilités apparaissent. Lorsque la maintenance des paquets en amont prend fin, TuxCare ELS prolonge la couverture des correctifs, et en va de même pour les versions d’exécution de PHP ayant atteint leur fin de vie.

Au lieu de créer une branche des bibliothèques dans votre propre dépôt et d'en hériter discrètement les CVE, vous bénéficiez d'une alternative à Packagist, vérifiée et recompilée à partir du code source, qui s'intègre parfaitement au flux de travail Composer. Ainsi, le risque lié aux bibliothèques « abandonnées » ne pèse plus uniquement sur votre équipe.

FAQ

Quand PHP 8.1 arrivera-t-il en fin de vie ?

PHP 8.1 a déjà atteint sa fin de vie le 31 décembre 2025 ; par conséquent, tout système fonctionnant encore sous cette version ne bénéficie plus de correctifs de sécurité en amont depuis cette date, à moins qu'un accord de correctifs avec un tiers ne comble cette lacune.

Quelles versions de PHP sont encore prises en charge ?

PHP 8.2, 8.3, 8.4 et 8.5. Parmi celles-ci, les versions 8.2 et 8.3 ne bénéficient plus que d'un support de sécurité, et la version 8.2 perdra même ce support le 31 décembre 2026. Consultez la page officielle de PHP consacrée aux versions prises en charge pour connaître l'état actuel. 

Comment puis-je repérer les paquets Composer abandonnés dans mon projet ?

Lancer composer audit, qui échoue par défaut sur les paquets abandonnés dans Composer 2.7 et versions ultérieures, ou composer audit –abandoned=report si vous préférez afficher la liste sans interrompre la compilation. Exécutez ensuite composer show –outdated –direct pour identifier les dépendances directes pour lesquelles des versions plus récentes sont disponibles, puis ajoutez –sort-by-age pour afficher les plus anciennes en premier. Les indicateurs « abandonné » de Packagist ne sont pas exhaustifs ; vérifiez donc l’activité du dépôt pour tout élément qui semble obsolète.

Qu'advient-il d'un paquet Composer présentant une vulnérabilité CVE et n'ayant pas de responsable de maintenance ?

L'avis est publié, mais un projet abandonné ne proposera peut-être jamais de version corrigée. Vous avez alors plusieurs options : créer une branche dérivée et corriger le problème vous-même, remplacer la dépendance, documenter une mesure de compensation ou faire appel à un fournisseur qui applique les correctifs aux paquets abandonnés.

La mise à jour de PHP permet-elle de corriger les dépendances Composer obsolètes ?

Non, et en général, c'est plutôt l'inverse qui se produit. Un paquet abandonné soumis à une contrainte stricte de version de PHP est souvent précisément ce qui empêche la mise à niveau du moteur d'exécution, c'est pourquoi « composer why-not php 8.4 » doit figurer au début de toute discussion sur la portée d'une mise à niveau, plutôt qu'à la fin.

L'utilisation d'une version de PHP arrivée en fin de vie (EOL) pose-t-elle un problème de conformité ?

C'est possible. Lorsqu'un cadre réglementaire exige la correction rapide des vulnérabilités ou l'utilisation de logiciels bénéficiant du support du fournisseur, un environnement d'exécution en fin de vie (EOL) est difficilement compatible avec ces exigences, car une fois que les correctifs en amont cessent d'être fournis, les équipes doivent trouver un autre moyen de démontrer que les vulnérabilités récemment révélées continuent d'être corrigées. La poursuite de la mise à jour des correctifs de sécurité, comme le support TuxCare , peut aider à préserver ces preuves pendant une migration, même si ce qui satisfait un auditeur dépend du cadre spécifique et de la manière dont il est mis en œuvre.

Résumé

Nom de l'article

La fin de vie de PHP et les dépendances Composer dont personne ne s'occupe

Description

Il est facile de suivre les dates de fin de vie des versions de PHP. Ce n'est pas le cas des paquets Composer obsolètes présents dans votre application, et ce sont généralement eux qui constituent le véritable obstacle à la mise à jour.

Auteur

Tim Walker

Nom de l'éditeur

de TuxCare

Logo de l'éditeur