Votre vulnérabilité CVE est accessible. Mais est-elle exploitable ?

De nos jours, tout outil d’ SCA e digne de ce nom intègre une fonctionnalité de « analyse d’accessibilité ». Lorsqu’une dépendance présente une vulnérabilité connue, ces outils peuvent vous indiquer si votre code appelle la fonction concernée. C’est une fonctionnalité pratiquement incontournable, car elle permet aux équipes de concentrer leurs efforts de sécurité plutôt que de passer leur temps à faire le tri parmi une multitude d’informations superflues. Toutes les autres étapes de hiérarchisation des CVE liés aux dépendances s’appuient sur celle-ci.

Mais ce n'est pas parce qu'une fonction vulnérable est accessible qu'elle est pour autant exploitable. L'accessibilité signifie que votre code peut exécuter la fonction vulnérable, tandis que l'exploitabilité signifie qu'un attaquant peut remplir les conditions nécessaires pour que le bug cause des dommages.

Ainsi, les équipes d'ingénieurs qui ne disposent que d'analyse d’accessibilité s doivent encore soit identifier manuellement les CVE qui posent réellement problème, soit déterminer quelles vulnérabilités sont les plus urgentes. De nombreuses équipes renoncent purement et simplement au triage manuel et appliquent des correctifs à toutes les vulnérabilités dépassant un certain seuil CVSS, ce qui est à l'origine du bruit et du gaspillage d'efforts.

Voyons en quoi « analyse de l’exploitabilité » va plus loin que « analyse d’accessibilité ».

Qu'est-ce que « analyse d’accessibilité » ?

La plupart des équipes classent les CVE en fonction de leur niveau de gravité CVSS, souvent à l'aide des étiquettes par défaut affichées par leurs outils de sécurité, et certaines y ajoutent les scores EPSS et KEV (voir le glossaire en bas de page pour la signification des acronymes). Ces indicateurs décrivent le CVE de manière générale et attribuent le même score à toutes les applications qui utilisent le paquet ; ils ne fournissent donc aucune information sur son comportement au sein de votre code.

analyse d’accessibilité vérifie si votre code peut exécuter la fonction vulnérable d'une dépendance, généralement en représentant sous forme de graphe d'appels la manière dont votre code appelle ses dépendances. Si la fonction vulnérable n'est jamais appelée, il n'y a pratiquement aucun risque (à moins que l'application ne change). 

Avant analyse d’accessibilité, les outils SCA signalaient chaque vulnérabilité CVE dans chaque dépendance, y compris les paquets transitifs que votre code n’appelait même pas. Les équipes devaient soit appliquer des correctifs à tout ce qui dépassait un seuil CVSS, soit effectuer un tri manuel. Reachability a changé la donne en associant chaque résultat à votre code réel, permettant ainsi aux ingénieurs de consacrer leur temps aux résultats qui comptent réellement en production. Cela a transformé la file d’attente des alertes de dépendances en une liste qu’ils pouvaient réellement traiter.

L'accessibilité s'articule autour de deux niveaux. 

• La vérification de l'accessibilité au niveau des dépendances permet de déterminer si votre code importe ou utilise réellement le paquet vulnérable. Cela permet d'écarter les paquets qui ne figurent dans votre fichier de verrouillage qu'en tant que dépendances transitives inutilisées. 
• L'analyse de l'accessibilité au niveau des fonctions va plus loin et vérifie si votre code appelle la fonction spécifique contenant le bogue ; ainsi, une application qui utilise uniquement une bibliothèque XML pour générer des documents est déclarée conforme en cas de CVE affectant l'analyseur syntaxique de cette bibliothèque.

Pourquoi un code accessible peut tout de même être sûr

Cependant, un code accessible n’est pas nécessairement exploitable. Un code accessible peut tout de même être sûr si un attaquant ne parvient pas à remplir les conditions nécessaires au déclenchement du bug. La plupart des vulnérabilités ne se contentent pas de l’exécution de la fonction. Elles nécessitent une entrée contrôlée par l’attaquant pour être exploitées sous une forme spécifique, l’activation d’une certaine configuration ou fonctionnalité, un niveau de privilège particulier, ou encore un déploiement dans lequel le résultat peut réellement vous causer du tort.

La liste des justifications de statut VEX (Vulnerability Exploitability eXchange) de la CISA cite « code vulnérable ne se trouvant pas sur le chemin d'exécution » et « code vulnérable ne pouvant pas être contrôlé par un attaquant » comme raisons distinctes pour lesquelles un produit n'est pas concerné. La première correspond à un verdict d'accessibilité et la seconde à un verdict d'exploitabilité.

Qu'est-ce qui rend une vulnérabilité CVE exploitable dans une application ?

Un exploit repose généralement sur la conjonction de plusieurs facteurs ; ainsi, si l'un d'entre eux fait défaut dans votre application, les attaques échoueront. Le CVSS prend en compte certaines de ces conditions dans ses indicateurs d'exploitabilité, tels que les privilèges requis et l'interaction de l'utilisateur. Le niveau réel d'exposition de votre application peut être bien supérieur ou bien inférieur au score publié.

Accessibilité vs exploitabilité dans un CVE de Lodash

CVE-2021-23337 Il s'agit d'une injection de commande dans la bibliothèque d'utilitaires JavaScript Lodash. La vulnérabilité se trouve dans le fichier lodash's _.template concernant les versions antérieures à la 4.17.21. lodash insère une valeur dans le code source de la fonction sans la valider ; ainsi, un attaquant qui contrôle cette option peut transmettre du code à la place d'un nom de variable et l'exécuter lors de la compilation du modèle.

Ce CVE présente un score CVSS de 7,2 et, en octobre 2026, un score EPSS d'environ 21 %, ce qui le place au-dessus de 97 % des CVE notés. Il ne figure pas dans la base KEV. Ces chiffres peuvent paraître inquiétants, mais ces informations sont, bien sûr, totalement indépendantes du contexte de votre application. 

Examinons trois applications qui dépendent toutes d'une version vulnérable de lodash, mais dont la portée et l'exploitabilité varient.

• L'application A n'appelle jamais _.template et utilise uniquement des outils de collecte tels que carte et filtre. analyse d’accessibilité peut écarter cette conclusion, car la fonction vulnérable ne s’exécute jamais.
• L'application B appelle _.template pour générer un e-mail, avec la chaîne de caractères du modèle et les options codées en dur par le développeur. Reachability signale ce problème, car la fonction s'exécute à chaque requête. Un attaquant ne peut toutefois pas modifier la variable « option » ; « analyse de l’exploitabilité » peut donc reclassifier la vulnérabilité en indiquant une justification écrite.
• L'application C diffuse les données de la requête dans les options du modèle. La fonction est accessible et les données fournies par l'attaquant parviennent à la variable « option » ; la gravité de la faille reste donc élevée. Une analyse de la vulnérabilité ( analyse de l’exploitabilité ) permettrait d'élever le niveau de gravité ou la priorité du problème.

Une même vulnérabilité CVE peut nécessiter des mesures différentes selon l'application concernée. 

La vulnérabilité peut évoluer à mesure que votre code change

Si un outil d'analyse de l’exploitabilité e indique que votre code n'est « pas exploitable », cela ne reflète que l'état actuel de votre code et de votre déploiement. Un nouvel emplacement d'appel, un nouveau chemin d'entrée, une modification de la configuration ou une mise à jour de l'image de base peuvent renverser ce verdict.

La correction apportée par Lodash en 2021 a ajouté une validation pour l'option « variable », mais a omis options.imports les noms de clés, qui alimentent le même Function() constructor. Ce deuxième chemin a donné lieu à la vulnérabilité CVE-2026-4800, corrigée dans la version 4.18.0 de lodash.

Ainsi, dans l'exemple précédent, une « pollution de prototype » survenant ailleurs dans l'application pourrait modifier la vulnérabilité de l'application B. La « pollution de prototype » permet à un attaquant d'ajouter des propriétés à Object.prototype (qui, si vous n'êtes pas développeur JS, est la classe dont héritent pratiquement tous les objets JavaScript). _.template copie les propriétés héritées dans les importations ; ainsi, un bug de « pollution de prototype » n'importe où ailleurs dans l'application B pourrait permettre à un attaquant d'accéder à ce chemin sans aucune modification de l'application B. _.template code.

Comment « Aikido » vérifie si les vulnérabilités CVE sont exploitables

AikidoLa fonctionnalité CVE d’ analyse de l’exploitabilité analyse le code du référentiel ainsi que le contexte du conteneur associé, notamment le fichier Dockerfile, l’image de base, la distribution et le mode d’exécution du conteneur. Elle utilise l’agent d’Aikido , qui analyse la manière dont le paquet vulnérable est utilisé dans votre code ou votre image de conteneur et détermine si la vulnérabilité est exploitable dans votre environnement. L’agent effectue ensuite les actions de triage que vous autorisez, à savoir « ignorer », « mettre en attente », « revenir à une version antérieure » ou « mettre à jour ». Chaque décision s’accompagne d’une justification écrite par l’agent, que le réviseur peut consulter avant de donner son accord.

Avant de classer un CVE accessible, il faut déterminer si les données saisies par un attaquant peuvent atteindre le paramètre vulnérable, ainsi que la configuration et le déploiement requis pour que la faille se déclenche. L'analyse de l’exploitabilité , qui gère les CVE, effectue cette vérification pour chaque CVE concerné et consigne le raisonnement à l'origine de chaque verdict.

Vous pouvez activer l'analyse de l’exploitabilité des vulnérabilités CVE pour vos dépôts et vos conteneurs associés depuis les paramètres de triage de Aikido. Le guide de configuration vous explique comment choisir une portée et définir les actions que l'agent peut effectuer.

FAQ

Qu'est-ce qu'un CVE ?

Un CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une faille de sécurité rendue publique, comme par exemple CVE-2021-23337. Le programme CVE est géré par MITRE, et ce sont des organismes agréés, appelés « autorités de numérotation CVE », qui attribuent ces identifiants, afin que tous les outils et avis puissent désigner la même faille sous le même nom.

Qu'est-ce que le CVSS ?

Le CVSS (Common Vulnerability Scoring System) évalue la gravité d'une vulnérabilité sur une échelle de 0 à 10, en fonction de la faille elle-même. FIRST gère cette norme, qui en est actuellement à la version 4.0, et les scores correspondent à des niveaux de gravité allant de « faible » à « critique ». Un score CVSS décrit la vulnérabilité de manière générale ; il ne peut donc pas tenir compte de la manière dont votre application utilise le code concerné.

Qu'est-ce que l'EPSS ?

L'EPSS (Exploit Prediction Scoring System) estime la probabilité qu'une vulnérabilité CVE soit exploitée quelque part dans la nature au cours des 30 prochains jours. FIRST publie un score compris entre 0 et 1 pour chaque vulnérabilité CVE publiée et le met à jour quotidiennement. Un score EPSS élevé indique un intérêt de la part des pirates sur Internet, mais il ne permet pas de savoir si votre propre application est exposée.

Qu'est-ce que le KEV ?

Le KEV est le catalogue des vulnérabilités connues pour avoir été exploitées (Known Exploited Vulnerabilities) de la CISA, une liste de CVE dont l'exploitation a été confirmée dans la nature. Les agences fédérales américaines sont tenues de corriger les CVE répertoriées dans le KEV dans les délais fixés par la directive opérationnelle contraignante 22-01, et la CISA recommande à toutes les organisations d'utiliser ce catalogue pour hiérarchiser l'application des correctifs. En octobre 2026, il répertoriait environ 1 700 CVE.