Une dépendance vulnérable n’occupe pas toujours la même place dans une application. Elle peut se trouver sur un chemin utilisé quotidiennement ou dans une partie du code difficile à atteindre. GitHub cherche à rendre cette différence plus visible avec la reachability analysis de Dependabot, annoncée en préversion publique le 28 octobre. L’objectif est de mieux hiérarchiser le travail, sans transformer un indicateur en certificat de sécurité.
La nouveauté concerne d’abord un périmètre précis
L’annonce de GitHub vise JavaScript et TypeScript sur GitHub Enterprise Cloud, avec des fichiers de verrouillage npm, Yarn ou pnpm. L’analyse s’appuie sur CodeQL pour examiner les chemins conduisant aux fonctions vulnérables.
Les résultats distinguent plusieurs situations : fonction atteignable, potentiellement atteignable, non atteignable ou analyse indisponible. GitHub indique qu’un résultat potentiel doit être traité comme atteignable. Le système ne ferme pas automatiquement les alertes.
La préversion est désactivée par défaut, utilise des exécuteurs hébergés par GitHub et est présentée comme gratuite à ce stade, sans facturation de minutes pour cette analyse. Ce cadre ne permet pas de supposer une disponibilité identique pour tous les langages, toutes les offres ou tous les environnements d’exécution.
Prioriser n’est pas décider à la place de l’équipe
L’intérêt pratique apparaît lorsqu’une équipe reçoit plus d’alertes qu’elle ne peut en traiter immédiatement. Un classement supplémentaire peut aider à choisir le premier correctif, puis à expliquer pourquoi une autre tâche attendra un peu.
Il faut toutefois conserver la différence entre une décision de priorité et une décision d’acceptation. Dire qu’un point passe après un autre ne signifie pas qu’il a disparu. Une équipe doit encore savoir qui suit le dossier, dans quel délai elle le réexamine et quel élément pourrait modifier sa décision.
Sans ces repères, un indicateur moins alarmant peut devenir une manière commode d’oublier une dépendance. L’outil donne alors une impression d’ordre sans améliorer réellement le suivi.
Le contexte de l’application reste indispensable
Une analyse de code apporte une information sur un état donné. Le projet, lui, continue d’évoluer : une fonctionnalité est activée, un parcours change, une intégration apparaît. Il est donc raisonnable de réexaminer les décisions lorsqu’un changement important touche le périmètre concerné.
Ce raisonnement ne remet pas en cause l’intérêt d’une analyse automatisée. Il indique simplement où commence la responsabilité de l’équipe. La bonne question devient : quelles informations nous ont permis de choisir, et lesquelles devons-nous encore vérifier ?
Notre article sur le choix entre pentest et scan de vulnérabilités revient sur une difficulté proche : un contrôle n’a de sens que si son périmètre et ses limites sont compris.
Une couleur ou une étiquette ne résume pas toute une situation.
Ce qu’un essai interne devrait chercher à mesurer
Pour évaluer la nouveauté, une équipe peut partir d’un petit groupe d’alertes connues. L’exercice consiste à regarder si l’indication facilite effectivement la discussion : comprend-on mieux le chemin signalé ? Peut-on relier le résultat à la partie du produit concernée ? Le responsable du correctif dispose-t-il d’un élément exploitable ?
Il est utile de noter aussi les cas sans verdict. Un résultat indisponible ne devrait pas devenir silencieusement un résultat rassurant. Il demande de poursuivre le tri avec les informations habituelles et de documenter ce qui manque.
Le même souci de preuve apparaît dans notre dossier sur les questions à poser avant de connecter deux logiciels par API. Dans les deux cas, la démonstration doit aider à comprendre les limites, pas seulement présenter le meilleur scénario.
La valeur se verra dans les corrections effectivement livrées
Un tableau d’alertes mieux rangé peut faire gagner du temps. Ce gain ne devient utile que si les corrections prioritaires avancent et si les autres restent suivies. Avant d’activer un nouvel outil partout, on peut donc examiner le délai entre une alerte et une décision explicite, puis entre cette décision et sa vérification.
La reachability analysis apporte un nouvel élément au tri de Dependabot. Elle ne supprime ni le besoin de mettre à jour une dépendance ni celui de tester l’application après un changement. Son meilleur usage consiste à rendre les arbitrages plus justifiables : traiter plus vite ce qui semble directement exposé, garder une trace du reste et éviter de confondre absence de chemin identifié avec absence définitive de risque.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
