Résumé

  • GitHub décrit l’écartement comme un état assorti d’un motif, et une alerte écartée mais non corrigée peut être rouverte.
  • Le signal du graphe de dépendances, le motif de triage et la preuve d’une remédiation sont trois registres différents.
  • Une conclusion sur la correction exige des liens vérifiables entre ces registres.

Le mot « écartée » allège une file d’alertes, mais il ne devrait pas transformer une décision de triage en résultat opérationnel. GitHub demande un motif pour écarter une alerte Dependabot ouverte : correctif commencé, signal inexact, code non utilisé, capacité de correction insuffisante ou risque jugé tolérable. Ces options ne racontent pas la même chose. Elles ne prouvent ni qu’une mise à niveau a été intégrée, ni qu’un verrou de dépendances a produit la version attendue, ni qu’un service déployé a cessé d’utiliser le composant concerné.

La documentation apporte elle-même la limite utile : une alerte écartée qui n’est pas corrigée peut être rouverte. Ce fait ne condamne pas l’écartement. Il empêche seulement de présenter cet état comme une fermeture définitive. « Correctif commencé » peut rester un chantier. « Non utilisé » peut être un jugement valable pour un chemin précis sans devenir une preuve universelle. « Risque tolérable » enregistre une appréciation, pas automatiquement l’autorité de la personne qui porte les conséquences d’un incident.

Le graphe sur lequel repose l’alerte est également borné. GitHub reconnaît des dépendances à partir de manifestes, de fichiers de verrouillage, de travaux de graphe ou de données soumises. L’analyse statique ne connaît pas l’environnement de build et ne résout pas toutes les variables. Un fichier de verrouillage peut préciser une résolution ; il ne prouve ni un build réussi, ni la sélection d’un artefact, ni son installation réelle.

Une proposition de mise à jour Dependabot constitue une autre étape, non le dénouement. Une pull request n’est pas une revue, une revue n’est pas un merge, un merge n’est pas un artefact validé, et un artefact n’est pas une observation de production. Daniel Kade recommande donc un reçu en six parties : identité et portée de l’alerte ; motif, commentaire et autorité de l’écartement ; source et résolution exactes ; changement revu ; preuve de build et de test ; observation limitée du déploiement. Les identifiants sensibles peuvent rester protégés ; les jointures doivent rester prouvées.

Sources

  1. GitHub Docs — Viewing and updating Dependabot alerts
  2. GitHub Docs — How the dependency graph recognizes dependencies
  3. GitHub Docs — Vulnerable dependency detection
  4. GitHub Docs — REST API endpoints for Dependabot alerts