Composer 2.11 déploie une politique de refroidissement des dépendances, offrant aux développeurs PHP un moyen natif de retarder l’intégration des nouvelles versions de packages. Ce mécanisme vise à réduire l’exposition aux attaques de la chaîne d’approvisionnement en imposant un laps de temps entre la publication et l’éligibilité à l’installation.

L’annonce, issue de l’écosystème Packagist, confirme cette évolution, une réponse directe à la multiplication des compromissions de packages observées récemment dans le monde PHP. Auparavant, le système se basait sur un champ de date que l’attaquant pouvait manipuler, ce qui rendait toute mesure de sécurité basée sur le temps vulnérable. Pour pallier ce défaut, Packagist a intégré un champ de « published-time », enregistrant le moment où le registre rend une version accessible, comme l’indique github.com.

Ce nouveau timestamp est ce qui permet à Composer de mettre en œuvre le cooldown. La configuration permet de définir une période d’attente – qu’elle soit de quelques heures, un jour ou même une semaine – en utilisant le paramètre config.policy.cooldown. Cette fonctionnalité n’est pas activée par défaut, laissant aux équipes la main sur le rythme de leur cycle de mise à jour. Les développeurs peuvent configurer cette période, par exemple, pour retenir toutes les versions publiées au cours des dernières 24 heures.

Le temps nécessaire pour détecter une menace

L’idée derrière ce délai n’est pas de bloquer l’innovation, mais d’offrir une fenêtre de respiration. Historiquement, les mises à jour privilégiaient le « bleeding edge », mais la fréquence des compromissions a rendu cette pratique risquée. Les scanners automatiques de logiciels malveillants peuvent détecter des problèmes en quelques minutes ; un délai d’une heure permet à ces outils d’agir avant qu’une version ne devienne candidate à un composer update. Pour les rapports nécessitant une revue humaine, quelques heures ou une journée sont considérés comme un temps utile pour la détection.

Cependant, les mainteneurs ont pris soin de ne pas automatiser la gestion des correctifs de sécurité. Ils ont refusé une exemption automatique, craignant qu’un attaquant ayant accès au dépôt ne puisse publier lui-même un avis de sécurité pour contourner le cooldown. Si un développeur doit appliquer un correctif urgemment, il peut utiliser l’option --no-cooldown lors de l’appel à composer update.

Une convergence avec d’autres écosystèmes

Cette initiative fait écho à des tendances déjà bien établies chez d’autres gestionnaires de paquets. D’après Socket, des outils comme pnpm, Yarn ou Bundler ont déjà implémenté des mécanismes de « minimum release age », souvent avec un délai par défaut. L’adoption par Composer marque l’alignement du monde PHP sur cette pratique de sécurité de la chaîne d’approvisionnement, qui devient de plus en plus la norme.

Pour les projets critiques, la politique de refroidissement peut être affinée par la possibilité d’ignorer certaines dépendances de manière permanente, via le paramètre ignore dans la configuration. Néanmoins, le fait que Composer choisisse de rendre cette fonctionnalité optionnelle, plutôt que de l’imposer, témoigne d’une prudence dans la gestion des flux de travail existants des équipes. Il faudra surveiller comment cette adoption modifie les pratiques de déploiement des versions critiques dans les prochains mois.

Sources

• Add published-time to public package metadata by Seldaek · Pull Request #1765 · composer/packagist, github.com
• Composer 2.11, blog.packagist.com
• Composer 2.11 Adds Dependency Cooldowns, Socket, 3 novembre 2026