Dependabot ajoute un champ de version : distinguer donnée enregistrée et déploiement
Le 20 octobre 2026, GitHub a ajouté dependency.version_requirement aux réponses REST des alertes Dependabot. Ce contexte facilite l’enquête, sans certifier la version actuellement installée en production. La fonction annoncée et les vérifications proposées doivent rester distinctes.
Séparer plage vulnérable et donnée du dépôt
vulnerable_version_range décrit les versions visées par l’avis. Le nouveau champ contient la version ou contrainte enregistrée en dernier pour l’alerte. Conserver paquet, écosystème et manifest_path avec ces deux valeurs. Une contrainte ne correspond pas à une version installée unique ; une étiquette explicite évite les classements trompeurs.
La détection détermine le sens
Un lockfile fournit la version résolue ; un manifeste sans lockfile, la version ou contrainte déclarée ; la dependency submission API, la version résolue envoyée par le build. Le champ figure dans les alertes individuelles, listes de dépôt, organisation et entreprise, ainsi que les webhooks dependabot_alert. Disponible sur github.com et Enterprise Cloud avec résidence des données, il est prévu pour Enterprise Server 3.24. Ne pas présumer sa présence sur un ancien serveur.
null et couverture partielle sont des cas normaux
Sans valeur disponible, le champ vaut null. Une alerte couvrant plusieurs versions peut n’en représenter qu’une ; une longue contrainte peut être tronquée. Nous proposons de conserver chaînes et null, de distinguer inconnu et sûr, et de signaler les anciens tickets incomplets. Un nombre d’alertes inchangé ne prouve pas l’exhaustivité des versions.
Vérifier l’intégration sur des alertes représentatives
Conserver réponse expurgée, heure de collecte, identifiant et chemin du manifeste. Suivre une version de lockfile, une contrainte et null jusqu’au ticket. Rapprocher webhook et interrogation des listes par dépôt et identifiant pour éviter les doublons. Vérifier les permissions de chaque endpoint. Ce sont des propositions d’exploitation, pas une nouvelle réparation automatique.
Pour connaître le déploiement courant, consulter les traces de build et de livraison. Après mise à jour, relancer les tests et relire l’état de l’alerte. Le champ peut réduire les recherches sans remplacer la validation d’une livraison. Le responsable doit pouvoir distinguer contrainte, inconnu et version représentative, puis identifier la preuve manquante.
Sources officielles
GitHub Changelog · Dependency versions
GitHub Docs · Dependabot alerts REST API
Vérifié le 21 octobre 2026. Comparer une réponse d’alerte à l’affichage de version de son ticket.