Dependabot : prioriser les alertes avec l’analyse d’atteignabilité

L’analyse d’atteignabilité Dependabot ajoute une question très concrète aux alertes de dépendances : votre code appelle-t-il réellement la fonction vulnérable ? Pour les dépôts JavaScript et TypeScript éligibles, GitHub affiche désormais ce signal dans les alertes. Il aide une équipe à organiser son travail de sécurité, sans transformer une absence de chemin détecté en feu vert automatique.

Un signal de priorisation, pas un verdict de sécurité

GitHub construit un graphe d’appels avec CodeQL à partir du dépôt et de ses dépendances, puis recherche un chemin vers les fonctions concernées par l’avis de sécurité. Une alerte peut être marquée atteignable, potentiellement atteignable, non atteignable ou indisponible. Une analyse potentiellement atteignable doit être traitée comme atteignable ; un résultat indisponible conserve votre processus de tri habituel.

Le résultat ne ferme ni ne rejette une alerte. Il complète la sévérité, l’exposition en production, l’EPSS et la connaissance fonctionnelle de votre équipe. Cela évite deux écueils : consacrer toute l’énergie à l’ordre de la liste, ou considérer une dépendance indirecte comme sans risque sans examiner le contexte de l’application.

Créer une file de remédiation réellement actionnable

Commencer par les chemins qui comptent

Dans un premier passage, filtrez les alertes atteignables et associez-les au service, au parcours utilisateur ou à l’API qu’elles peuvent toucher. Pour chacune, vérifiez la branche et le lockfile concernés, le correctif disponible et la capacité de retour arrière. Le but n’est pas de produire un score : c’est de transformer une alerte en décision de correction, de mitigation temporaire ou d’acceptation documentée.

Conserver une voie pour le reste

Les alertes non atteignables restent à surveiller : un nouveau parcours, une mise à jour de dépendance ou une analyse incomplète peut changer la situation. Planifiez une revue périodique plutôt que de les classer définitivement. Les signaux peuvent aussi être exploités dans vos outils via l’API Dependabot, mais la règle métier — qui priorise, qui valide et à quelle échéance — doit rester explicite.

Vérifier l’éligibilité avant de promettre un gain

La fonctionnalité est actuellement en préversion publique pour GitHub Enterprise Cloud, avec JavaScript ou TypeScript et un lockfile npm, Yarn ou pnpm. Elle utilise un workflow GitHub Actions géré par GitHub et ne prend pas en charge les runners auto-hébergés pendant la préversion. Certains monorepos ou dépôts à plusieurs manifests peuvent ne pas être pris en charge ; une analyse qui dépasse trois heures peut ne pas donner de verdict.

L’activation est désactivée par défaut et nécessite les alertes Dependabot. Testez-la donc sur un dépôt représentatif, mesurez le délai d’analyse et vérifiez la lisibilité des verdicts avec l’équipe qui corrigera réellement les dépendances. Pour réduire les secrets nécessaires aux mises à jour elles-mêmes, consultez aussi notre guide sur Dependabot et les registres privés.

Associer détection, décision et preuve

Une vulnérabilité réellement atteignable est un bon point de départ pour une correction prioritaire, mais le contrôle ne s’arrête pas à la mise à jour du package. Ajoutez un test de non-régression, une vérification de production et une trace de décision. L’analyse de dépendances complète ainsi les règles de CodeQL pour la sécurité applicative : l’une vous aide à situer le risque dans les dépendances, l’autre à examiner les chemins de code que vous maîtrisez.