Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Un paquet abandonné reste installable via Packagist, malgré les vulnérabilités CVE ouvertes et tout le reste, car la correction des paquets n'a jamais relevé de la responsabilité de Packagist.
- SecureChain recompile et vérifie les paquets PHP avant leur installation, puis continue à les mettre à jour à mesure que la maintenance en amont ralentit puis cesse.
- Vous pouvez faire passer l'ensemble de votre configuration Composer par SecureChain, ou n'y envoyer que les paquets qui en ont besoin.
- Private Packagist héberge et met en miroir vos paquets, tandis que SecureChain applique les correctifs à ceux dont personne ne assure la maintenance.
Un paquet Composer abandonné présentant une vulnérabilité CVE non corrigée vous met dans une situation délicate. Il est peu probable qu’un correctif soit fourni par l’auteur d’origine ; vos options se limitent alors à créer vous-même un fork, à remplacer le paquet ou à documenter une mesure de contrôle compensatoire en espérant qu’un auditeur l’accepte. Une alternative à Packagist qui s’appuie sur des correctifs adaptés à ce problème. SecureChain recompile et filtre les paquets PHP avant qu’ils n’atteignent votre environnement de compilation, puis continue de fournir des correctifs dans le cadre d’un SLA bien après que le responsable de maintenance d’origine se soit fait discret, soit à la place de Packagist, soit en complément de celui-ci.
Voici ce que cette couverture comprend concrètement, et comment elle s'intègre au workflow Composer que vous utilisez déjà.
Pourquoi les équipes recherchent-elles une alternative à Packagist ?
Packagist remplit la fonction pour laquelle il a été conçu. Il indexe les référentiels de paquets et indique à Composer où récupérer le code, et il s'acquitte très bien de cette tâche. Ce pour quoi il n'a jamais été conçu, c'est de corriger quoi que ce soit. Lorsqu'un responsable de maintenance cesse de publier des mises à jour, Composer continue sans problème à résoudre une version vulnérable existante grâce aux métadonnées de Packagist, aux CVE et tout le reste.
La situation a évolué cette année. Composer 2.10, sorti fin mai, bloque les versions signalées comme malveillantes lors de la résolution des dépendances, puis à nouveau lors de l’installation à partir d’un fichier de verrouillage existant, et regroupe les avis de sécurité, les paquets abandonnés et les logiciels malveillants au sein d’une seule politique de dépendances. Packagist a emboîté le pas en juillet en rendant immuables les versions stables publiées ; ainsi, une version réétiquetée ne peut plus remplacer discrètement celle que vous avez déjà verrouillée. Ces deux changements constituent de réelles améliorations, et aucun des deux ne génère de correctif. Le blocage d’une version malveillante ne vous empêche toutefois pas de vous retrouver avec un paquet abandonné présentant une vulnérabilité CVE non corrigée et sans contributeur en amont pour y remédier.
C’est généralement à ce moment-là qu’une équipe commence à chercher une alternative à Packagist plutôt qu’une solution de contournement ponctuelle. La distinction est importante. Une solution de contournement ne résout qu’un seul problème relevé lors d’un audit. Une alternative fondée sur l’application de correctifs part du principe que ce problème va se reproduire, et pas seulement pour le paquet abandonné qui se trouve actuellement sur votre bureau. Pour en savoir plus sur les raisons pour lesquelles les dépendances Composer n’ont jamais de date de fin de vie, contrairement à PHP, consultez l’article « Vos dépendances Composer ne prennent pas leur retraite simplement parce que PHP l’a fait », qui examine en détail ce que cela signifie pour les paquets qui fonctionnent encore dans votre application.
PHP n'est pas non plus un cas isolé. Les incidents liés à la chaîne d'approvisionnement survenus en 2026 dans plusieurs écosystèmes open source ont incité les équipes à repenser la question de la fiabilité des registres, et ce phénomène ne s'est pas limité à un seul langage.
Comment SecureChain continue à proposer des correctifs après le retrait d'Upstream
SecureChain considère cela comme un problème lié au cycle de vie plutôt que comme une solution ponctuelle. Chaque paquet PHP qu’il met à disposition est recompilé à partir du code source dans un environnement isolé avant d’être proposé à l’installation ; ainsi, ce qui se retrouve dans votre compilation est vérifié de bout en bout, au lieu d’être directement extrait d’un artefact en amont que personne n’a recompilé ni vérifié. Les paquets font également l’objet d’un filtrage visant à détecter les logiciels malveillants connus et les modèles de code suspects, et tout élément qui échoue à cette inspection est bloqué avant même de vous parvenir, plutôt que d’être signalé a posteriori.
Le travail ne s'arrête pas une fois qu'un paquet a passé ce premier contrôle. Tant que le développeur en amont continue de publier des versions, les composants actifs sont surveillés et corrigés dans le cadre du SLA à mesure que de nouvelles vulnérabilités (CVE) apparaissent, comme on peut l'attendre d'un responsable de maintenance qui reste vigilant. Une fois que le développeur en amont cesse toute activité, TuxCare continue d’assurer directement la maintenance du paquet, et environ six mois après la dernière version publiée en amont, le service « Endless Lifecycle Support » prend le relais et continue de fournir des correctifs tant que vous utilisez le paquet, que le responsable de maintenance d’origine revienne ou non.
C'est justement dans cet écart, entre le signalement d'un problème et sa résolution effective, que bon nombre d'outils de chaîne d'approvisionnement échouent. Pour les équipes qui doivent rendre compte de leur travail, SecureChain génère également une traçabilité de niveau 3 selon la norme SLSA, une liste des composants logiciels (SBOM) et des données VEX. Ainsi, l'affirmation « ce problème a été corrigé » s'appuie sur des preuves tangibles, et non sur une simple déclaration qu'il faudrait prendre pour argent comptant.
Comment SecureChain s'intègre à Packagist
Tout cela ne nécessite pas de bouleverser la façon dont votre équipe utilise déjà Composer. SecureChain est un référentiel compatible avec Composer que vous pouvez utiliser à la place du référentiel public Packagist ou en parallèle de celui-ci ; c'est à vous de décider quelle part de votre trafic y transitera.
Certaines équipes font passer l'intégralité de leur configuration Composer par SecureChain, de sorte que tous les paquets qu'elles récupèrent sont recompilés et filtrés avant l'installation, et pas seulement les paquets abandonnés. D'autres adoptent une approche plus restrictive et n'envoient que les paquets dont elles savent qu'ils sont abandonnés ou à haut risque, tandis que tous les autres sont récupérés depuis Packagist exactement comme c'est le cas aujourd'hui. Tout élément ne figurant pas encore dans le catalogue peut être ajouté sur demande. Dans tous les cas, les développeurs continuent d'utiliser le même composer install et composer update des commandes qu'ils connaissent déjà, et une fois le référentiel configuré, le déroulement quotidien des tâches reste inchangé.
Ce qui change, c’est ce qui se passe en arrière-plan de ces commandes pour tout ce qui transite par SecureChain. Au lieu que Composer télécharge depuis l’endroit indiqué par les métadonnées de Packagist – un dépôt source ou une archive de distribution –, il se procure le paquet depuis un dépôt où celui-ci a déjà été recompilé, contrôlé et corrigé. Votre fichier de verrouillage continue d’enregistrer les versions et les références résolues par Composer. Ce qui change, c’est leur provenance : il s’agit d’un paquet recompilé et maintenu, fourni depuis le dépôt de TuxCare, plutôt que de ce que vous aurait fourni la chaîne de distribution en amont classique.
Intégrer SecureChain à votre pile Composer
Si votre dernier audit a mis en évidence deux ou trois paquets abandonnés faisant l’objet d’avis de sécurité ouverts, il s’agit là d’un point de départ précis et bien délimité, et non d’une raison de repenser entièrement l’architecture de votre configuration de dépendances. Si la liste des paquets abandonnés est plus longue, la première question à se poser est de savoir lesquels de ces paquets peuvent réellement être corrigés, car cela détermine dans quelle mesure il est judicieux, dès le départ, de faire passer une partie de votre configuration Composer par SecureChain.
SecureChain ne remplace pas Private Packagist, et il est utile de bien distinguer les deux. Private Packagist, développé par Packagist Conductors (la société à l’origine de Composer et de Packagist.org), gère l’hébergement privé de paquets, la mise en miroir et les contrôles de distribution ; au cours de l’année écoulée, il a d’ailleurs ajouté un nombre considérable d’outils propres à la sécurité de la chaîne d’approvisionnement. En revanche, elle ne procède pas au portage de correctifs vers une dépendance dont le responsable a cessé de répondre il y a des années. Une équipe dont le besoin principal est l’hébergement privé trouvera mieux son compte avec cette solution, et l’utilisation conjointe des deux services est tout à fait raisonnable, puisque chacun remplit des fonctions distinctes.
Si les paquets PHP constituent la couche pour laquelle votre couverture est insuffisante, découvrez SecureChain pour PHP afin d’en savoir plus sur son fonctionnement, ou demandez un devis pour obtenir une présentation détaillée de ce que cette solution couvrirait dans votre environnement spécifique.
FAQ
Qu'est-ce qu'une alternative à Packagist ?
Une alternative à Packagist est un référentiel compatible avec Composer utilisé à la place ou en complément du référentiel public Packagist. Les équipes y ont recours lorsqu’elles ont besoin de fonctionnalités que le référentiel public Packagist ne propose pas, telles qu’un hébergement privé, une distribution contrôlée, des contrôles de sécurité plus stricts ou la mise à jour continue de paquets dont la maintenance a cessé.
Quels sont les correctifs apportés par SecureChain ?
SecureChain corrige les vulnérabilités tout au long du cycle de vie d'un paquet PHP. Les paquets actifs sont corrigés dans le cadre d'un contrat de niveau de service (SLA) ; TuxCare assure leur maintenance directement dès que l'activité en amont cesse, et le service « Endless Lifecycle Support » offre ensuite une couverture à long terme tant que vous utilisez le paquet.
Dois-je remplacer complètement Packagist pour utiliser SecureChain ?
Non. Vous pouvez faire passer l'intégralité de votre environnement Composer par SecureChain, ou bien n'y faire passer que certains paquets, tandis que tous les autres continueront d'être récupérés depuis Packagist comme d'habitude.
Est-ce que cela remplace Private Packagist ?
Non, ils répondent à des besoins différents. Private Packagist propose des services d'hébergement privé de paquets, de mise en miroir et de contrôle de la distribution, tandis que SecureChain corrige les paquets dont le responsable en amont a cessé de corriger les vulnérabilités.
Les développeurs devront-ils modifier leur façon d'utiliser Composer ?
Non. Une fois le référentiel configuré, les commandes et les workflows de Composer restent les mêmes. Ce qui change, c'est ce qui se cache derrière les paquets installés.
