Dependabot impose un délai de 3 jours avant chaque mise à jour de paquet

Depuis le 14 juillet 2026, Dependabot ne se précipite plus. GitHub vient de rendre par défaut, sans aucune configuration à ajouter, un délai de trois jours entre la publication d'une nouvelle version de paquet sur son registre et l'ouverture d'une pull request de mise à jour par Dependabot. Le fonctionnement était déjà proposé en option depuis quelques mois : il devient désormais le comportement standard sur tous les dépôts github.com.

Une décision qui peut sembler anodine côté changelog, mais qui a une conséquence très concrète pour tous les projets qui laissent un bot ouvrir automatiquement des pull requests de montée de version : vos dépendances arrivent désormais avec quelques jours de recul, et ce recul est précisément ce qui manque le plus souvent pour repérer un paquet piégé avant qu'il n'entre dans votre pipeline.

Dependabot en deux mots, pour ceux qui découvrent

Dependabot est le bot de gestion de dépendances intégré nativement à GitHub. Il surveille vos manifestes (package.json, requirements.txt, go.mod, et bien d'autres) sur l'ensemble des écosystèmes supportés, et ouvre deux types de pull requests bien distincts : les version updates, des montées de version planifiées et routinières, et les security updates, déclenchées dès qu'une alerte de sécurité (GitHub Security Advisory) touche l'une de vos dépendances.

C'est cette distinction qui est au cœur du changement annoncé cette semaine par GitHub.

Pourquoi un simple délai protège contre les attaques supply chain

Le scénario que ce cooldown vise à limiter est bien connu des équipes sécurité : un paquet légitime, avec un historique propre et des milliers de téléchargements, se fait compromettre (compte mainteneur piraté, jeton npm volé, dépendance transitive infectée) et publie une version malveillante. Si un bot d'automatisation ouvre une pull request de mise à jour dans les minutes qui suivent, et qu'un développeur pressé merge sans trop regarder, le code compromis atterrit directement dans votre build.

GitHub le formule ainsi dans son changelog : les nouvelles releases sont un point d'entrée fréquent pour les attaques de la chaîne d'approvisionnement, où une version compromise ou cassée peut atteindre vos mises à jour de dépendances avant même que les mainteneurs ou la communauté ne l'aient repérée. Un court délai laisse le temps à ce signal de remonter : scanners automatisés des registres, retours de la communauté, dépréciation ou retrait de la version par les mainteneurs eux-mêmes. Trois jours ne garantissent rien à cent pour cent, mais c'est largement suffisant pour qu'un incident majeur fasse déjà parler de lui.

Ce qui change concrètement, et ce qui ne bouge pas

• Le délai ne s'applique qu'aux version updates. Les montées de version planifiées (hebdomadaires, mensuelles, selon votre configuration) attendent désormais que la release ait au moins trois jours d'existence sur son registre.
• Les security updates restent immédiates. Si une alerte de sécurité touche une de vos dépendances, Dependabot ouvre la pull request de correctif sans délai. Aucun correctif critique n'est retardé par ce changement.
• Le changement est actif sur tous les écosystèmes supportés sur github.com (npm, pip, Go, Maven, RubyGems, et les autres gestionnaires pris en charge par Dependabot), sans action de votre part.
• GitHub Enterprise Server recevra ce comportement par défaut avec la version 3.23.

Garder la main : ajuster ou désactiver le cooldown

GitHub est clair sur ce point : vous restez décisionnaire. L'option cooldown de votre fichier .github/dependabot.yml permet de redéfinir la fenêtre, de la moduler selon le type de montée de version, ou de la désactiver complètement pour un ou plusieurs paquets.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
      exclude:
        - "eslint*"

Vous pouvez aussi affiner la durée selon la nature du changement, avec des clés distinctes pour les montées majeures, mineures et les correctifs. Utile si votre équipe veut, par exemple, laisser mûrir plus longtemps les montées de version majeures (souvent porteuses de plus de changements, donc de plus de surface de risque) tout en gardant les correctifs mineurs réactifs.

Ce que ça change pour votre équipe ou votre PME

Si vous gérez une stack Node, Python, Go ou autre avec Dependabot activé, vous n'avez strictement rien à faire pour bénéficier de ce garde-fou : il est actif dès aujourd'hui. Trois cas concrets où ça change vraiment la donne :

• Les projets sans revue de dépendances dédiée. Beaucoup de petites équipes mergent les pull requests Dependabot presque automatiquement, dès que la CI passe au vert. Le cooldown ajoute une marge de sécurité gratuite là où il n'y avait auparavant aucun filtre humain.
• Les écosystèmes à forte cadence de publication. npm en tête, où des dizaines de versions peuvent sortir en une journée sur des paquets très utilisés. C'est justement l'écosystème où les attaques par compromission de compte mainteneur ont été les plus documentées ces dernières années.
• Les audits de conformité. Pouvoir démontrer qu'un délai d'observation est appliqué avant toute intégration de nouvelle dépendance est un argument concret dans une démarche de conformité ou face à un client qui audite votre chaîne d'approvisionnement logicielle.

Notre lecture chez CZSyn

Ce cooldown n'est pas un événement isolé. Le changelog sécurité de GitHub de ces dernières semaines aligne plusieurs mesures qui vont dans le même sens : durcissement des accès aux caches d'Actions pour les triggers non fiables, protection préventive des comptes npm à fort impact, mise en conformité progressive de la rétention des données sur les alertes de sécurité fermées. Le message de fond est cohérent : l'automatisation de la gestion de dépendances ne doit plus reposer sur une confiance aveugle accordée à un registre public.

Pour les PME et les équipes de développement avec lesquelles nous travaillons, ce changement est une bonne nouvelle à coût nul. La plupart des structures que nous accompagnons n'ont pas d'équipe sécurité dédiée pour auditer chaque pull request de dépendance, et ce type de garde-fou activé par défaut comble exactement ce vide sans nécessiter d'expertise particulière. Notre seul conseil : ne vous arrêtez pas au confort du défaut. Si vous gérez des paquets critiques (authentification, paiement, chiffrement), pensez à allonger volontairement la fenêtre de cooldown sur ces dépendances précises via l'exclusion ou des délais différenciés par type de montée de version. Trois jours protègent contre l'urgence irréfléchie, mais rien ne remplace une vigilance ciblée sur les briques qui comptent vraiment pour votre sécurité.

Sources primaires

• GitHub Changelog, « Dependabot version updates introduce default package cooldown », 14 juillet 2026.
• Documentation officielle GitHub, « Dependabot ».