Dependabot attend désormais trois jours avant de mettre à jour vos dépendances

Le réflexe paraît sain : une nouvelle version sort, le bot ouvre une pull request, les tests passent, on fusionne. Depuis le 23 juillet 2026, GitHub considère pourtant que cette rapidité peut devenir un risque. Dependabot applique maintenant un délai de trois jours avant de proposer une mise à jour de version, même si aucun cooldown n’est déclaré dans le dépôt (annonce officielle).

L’idée n’est pas de ralentir les correctifs de sécurité. Elle consiste à éviter d’installer trop vite une version fraîchement publiée, avant que l’écosystème ait eu le temps de regarder ce qu’elle contient.

## La dernière version n’est pas toujours la plus sûre

Une attaque de supply chain peut passer par le compte compromis d’un mainteneur. L’attaquant publie alors une nouvelle version apparemment normale, mais contenant du code malveillant. Les outils automatisés la détectent immédiatement et commencent à la distribuer dans des pull requests.

GitHub cite un incident survenu en septembre 2025 : des versions piégées de chalk, debug et d’une douzaine d’autres paquets npm ont été publiées après le vol des identifiants d’un mainteneur. Ces dépendances cumulaient plus de deux milliards de téléchargements hebdomadaires. Les versions malveillantes, conçues pour remplacer des adresses de portefeuilles de cryptomonnaies dans le navigateur, sont restées disponibles environ deux heures (récapitulatif de GitHub).

Deux heures, c’est court pour une équipe humaine. Pour un bot qui vérifie le registre plusieurs fois par jour, c’est largement suffisant.

Le délai agit donc comme un filtre temporel. Si une version compromise est retirée quelques heures après sa publication, elle disparaît avant même que Dependabot ne la considère comme éligible.

## Trois jours, mais pas pour les failles connues

Dependabot gère deux flux différents :

les version updates, qui proposent les nouvelles versions disponibles ;
les security updates, qui remplacent une dépendance touchée par une vulnérabilité connue.

Le nouveau délai ne concerne que le premier flux. Une pull request corrigeant une vulnérabilité publique continue d’être ouverte immédiatement. Attendre trois jours dans ce cas augmenterait l’exposition au lieu de la réduire (documentation de l’option `cooldown`).

Cette distinction est importante. Un paquet ancien avec une CVE publique et un paquet publié il y a dix minutes ne présentent pas le même problème. Dans le premier cas, il faut avancer vers le correctif. Dans le second, attendre permet de voir si la release survit à ses premières heures.

## Ce que cela change dans un dépôt

Si votre fichier .github/dependabot.yml contient seulement une vérification quotidienne, aucune modification n’est nécessaire. Dependabot continuera d’interroger le registre selon le calendrier défini, mais ignorera les versions sorties depuis moins de trois jours. Le fichier doit toujours se trouver dans le dossier .github de la branche par défaut (documentation du fichier).

Le délai peut aussi être réglé selon le type de version :

yaml

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
      semver-patch-days: 3
      semver-minor-days: 7
      semver-major-days: 14

Ici, un patch attend trois jours, une version mineure sept jours et une majeure deux semaines. Ces paramètres sont disponibles pour de nombreux écosystèmes, dont npm, Docker, Cargo, Composer, Go Modules, Pip, Terraform et GitHub Actions (liste complète).

Pour un petit projet web, le défaut de trois jours me paraît raisonnable. Une dépendance publique n’a généralement pas besoin d’entrer en production le jour de sa sortie. Les exceptions existent, mais elles devraient rester explicites.

## Un délai ne remplace pas une vraie défense

GitHub indique que sa base d’avis de sécurité a recensé plus de 6 500 alertes liées à des paquets npm malveillants durant l’année terminée en mai 2026, contre environ 6 200 l’année précédente, soit près de 18 nouveaux paquets catalogués par jour (données publiées par GitHub). Le problème n’est donc pas théorique.

Mais le cooldown ne bloque que les attaques rapidement détectées. Il ne protège pas contre une porte dérobée discrète, un script dormant ou une infrastructure de build déjà compromise. Il faut toujours conserver les lockfiles, limiter les permissions des jetons de CI, désactiver les scripts d’installation lorsque c’est possible et relire les changements avant fusion.

Le vrai changement est surtout culturel : être à jour ne signifie pas forcément être le premier à mettre à jour. Pour les dépendances, quelques jours de recul peuvent être une mesure de sécurité, pas une dette technique.

## Pour aller plus loin

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.