D'après i-programmer.info, GitHub revoit sa copie face à la réalité crue des supply chain attacks: on ne peut plus faire confiance aveuglément à un tag tout neuf publié sur npm — ni, par extension, sur Packagist. (Eh oui, nos bons vieux composer.json sont dans la boucle, Dependabot couvre aussi PHP.)
Pourquoi ce cooldown change la donne (sans tomber dans le hype)
L'idée est simple: Dependabot distingue deux métiers depuis longtemps. D'un côté, les mises à jour de sécurité, qui s'ouvrent toujours en urgence dès qu'une advisory tombe. De l'autre, les version updates classiques, qui suivaient jusqu'ici les releases à la seconde près. GitHub injecte maintenant un délai par défaut de 72 heures entre la publication d'une nouvelle version et l'ouverture de la PR de bump.
Carlin Cherry, Product Manager chez GitHub Advanced Security, donne l'exemple qui fait froid dans le dos: en septembre 2025, un attaquant a phishé les credentials d'un mainteneur npm et publié des versions piégées de chalk, debug et une douzaine d'autres packages — plus de 2 milliards de téléchargements par semaine. Le code malveillant réécrivait les adresses de portefeuilles crypto dans les apps qui le chargeaient. Deux heures en ligne avant que la communauté ne tire la prise. Deux heures, c'est largement suffisant pour qu'un robot comme Dependabot propage la version vérolée dans des milliers de pipelines.
Morality? Le « dernier commit, dernière version », c'est fini. On assume enfin qu'un release tout frais peut être une backdoor. (Bienvenue dans l'ère post-naïve, les amis.)
Ce qu'on peut configurer (et ce qu'on ne peut pas)
Bonne nouvelle: le cooldown n'est pas gravé dans le marbre. Tout passe par votre dependabot.yml avec un paramètre dédié pour ajuster le délai selon votre projet. Besoin d'un délai plus long sur des libs critiques? Possible. Vous voulez zapper complètement le cooldown sur des dépendances de dev jetables? Aussi. (Avis aux mainteneurs de packages internes: on respire, vous gardez la main.)
Trois jours, c'est un choix délibéré. GitHub s'est appuyé sur une revue de 21 incidents de supply chain largement documentés entre 2018 et 2026: dans la majorité des cas, les versions malveillantes sont retirées quelques heures après publication. Trois jours vous sortent de cette fenêtre de tir sans bloquer indéfiniment vos dépendances.
Mais nuance importante, et c'est là qu'on évite le réflexe « silver bullet »: un cooldown ne protège que contre les attaques rapides. Les backdoors dormantes plantées dans une release propre, le sabotage par un mainteneur compromis, ou un système de build infiltré — tout ça passe tranquillement à travers le délai de trois jours. Ce n'est pas une solution miracle, c'est une couche de défense supplémentaire. (On rappelle au passage qu'aucun outil ne remplace un audit sérieux et un composer.lock bien verrouillé.)
Et pour nos stacks PHP, concrètement?
Si vous tournez sur Composer avec des packages depuis Packagist: oui, Dependabot vous concerne, le cooldown s'appliquera à vos version updates. Les alertes de sécurité continueront d'arriver en temps réel, donc pas de panique sur les CVE critiques. Vous verrez juste un décalage de quelques jours sur les bumps classiques — ce qui est souvent un soulagement pour les équipes qui se prenaient des PR Dependabot en plein vendredi après-midi (oui, le bot a toujours eu un talent pour les timings catastrophiques).
Le vrai sujet de débat dans la communauté: est-ce qu'on ne devrait pas standardiser cette pratique côté Composer aussi? Un délai de grâce configurable avant qu'un composer update automatisé ne tire une version toute fraîche? À débattre dans vos channels communautaires favoris, et on vous lit avec plaisir!