Normes et standards / Référentiels de vulnérabilités
CVE, CWE, CVSS : nommer, noter et prioriser une vulnérabilité
La détection et la correction de vulnérabilités dans un logiciel est un sujet complexe et stressant au quotidien.
Nous avons synthétisé le fonctionnement des standards de référence du domaine pour que vous puissiez avec une vue d'ensemble et une meilleure compréhension des enjeux.
5 référentiels complémentaires
Savoir de quoi on parle avant de prendre une décision
La sécurité est une source de stress permanente. Comprendre le système de publication de failles est essentiel pour s'organiser dans de bonnes conditions et éviter la panique inutile.
Comprendre la logique
De la faiblesse générique à la faille de votre application
Étape 1
La faiblesse générique : CWE
Une faiblesse est un défaut de conception ou d'implémentation qui peut exister dans n'importe quel logiciel : ne pas échapper une donnée avant de la passer à la base, faire confiance à un identifiant fourni par l'utilisateur, laisser une erreur révéler le chemin d'un fichier.
Le MITRE les recense dans une taxonomie hiérarchisée, la Common Weakness Enumeration. Chaque type porte un numéro stable : CWE-89 pour l'injection SQL, CWE-79 pour le XSS, CWE-22 pour la traversée de répertoire.
C'est le vocabulaire dans lequel parlent les outils. Un scanner remonte une faille qui est associée à une CWE.
Étape 2
La faille nommée : CVE
Une vulnérabilité est la présence d'une faiblesse dans un produit précis, à une version précise. Lorsqu'elle est constatée et remontée, elle reçoit alors un identifiant public et unique, une CVE, attribué par un réseau d'autorités de nommage.
Le lien entre les deux étages est explicite : un enregistrement CVE porte le CWE qui le classe. C'est ce qui permet de dire « cette faille de votre application est une injection SQL », et pas seulement « il y a un problème ».
Ce que la CVE ne dit pas : si votre application est concernée. Une faille peut viser une fonction que votre code n'appelle jamais.
Étape 3
La gravité théorique : CVSS
Le Common Vulnerability Scoring System, publié par le FIRST, note de 0 à 10 la gravité d'une vulnérabilité : difficulté d'exploitation, privilèges nécessaires, conséquences sur les données.
Le score que vous voyez dans un avis est le score de base, celui qui ignore délibérément votre contexte. Il décrit la faille, pas votre exposition à cette faille.
Étape 4
La réalité de l'attaque : EPSS et KEV
Deux sources répondent à la question que le CVSS laisse ouverte, celle de savoir si la faille va réellement servir.
L'EPSS publie chaque jour une probabilité d'exploitation dans les trente jours à venir. Le catalogue KEV de la CISA, lui, ne suppose rien : il n'inscrit une faille que sur preuve d'exploitation constatée, correctif disponible à l'appui.
Une note élevée sans exploitation observée et une note moyenne inscrite au KEV n'appellent pas la même urgence. C'est tout le sujet de la seconde moitié de cette page.
DU VICE TYPE AU CONSTAT DE DÉFAILLANCE
Comprendre les vulnérabilités grâce au bâtiment
Cinq référentiels, cinq dispositifs que le bâtiment connaît déjà. Et une sixième case, celle qu'aucun des cinq ne remplit : la décision.
CWE · La fiche pathologie
L'AQC publie ses fiches pathologies bâtiment : le catalogue des vices types, décrits une fois pour toutes, sans désigner ni immeuble ni entreprise. Une fiche « infiltration par seuil de porte-fenêtre » décrit une erreur de conception ou d'exécution récurrente, pas un chantier. Le CWE fait exactement cela pour l'injection SQL ou le débordement de mémoire.Vice type
CVE · Le rappel produit
Un lot de chevilles n'atteint pas la résistance déclarée dans son évaluation technique. Le fabricant émet un rappel : la référence est nommée, les lots concernés sont listés, et tout chantier qui en a posé est potentiellement touché. Une CVE est ce rappel, elle désigne un composant et des versions précises, pas encore un dégât.Produit + lots
CVSS · La note du laboratoire
Le laboratoire mesure la résistance à l'arrachement du lot et chiffre l'écart : 70 % sous la valeur déclarée, gravité 9 sur 10. Cette note vaut pour la cheville, pas pour votre immeuble. Elle ne dit ni si vous en avez posé, ni ce qu'elles retiennent : le même défaut ne pèse pas pareil sous un garde-corps de balcon et sous une étagère de cave.9 / 10 hors contexte
EPSS · L'observatoire de la sinistralité
Sycodés, l'observatoire de l'AQC, enregistre les désordres décennaux depuis 2000 et en mesure la fréquence et le coût par élément d'ouvrage. C'est une statistique sur le parc, pas un diagnostic de votre immeuble : elle ne dit pas que votre garde-corps va céder, elle dit à quelle vitesse le problème se matérialise ailleurs.Probabilité sur le parc
KEV · Le dispositif Alerte
L'AQC publie des alertes sur les produits et procédés dont les désordres sont constatés sur le terrain. Trois garde-corps posés avec ce lot ont cédé cette semaine : ce n'est plus une probabilité, c'est un fait. Le catalogue KEV fonctionne à l'identique, à trois conditions : le produit est nommé, une reprise existe, la défaillance a été observée.Exploitation constatée
La décision · La visite sur site
Aucun des cinq dispositifs précédents n'a mis les pieds chez vous. Le jour où il faut trancher, quelqu'un monte voir : ces chevilles ont-elles été posées ici, que retiennent-elles vraiment, le balcon est-il accessible au public, une reprise est-elle possible sans évacuer. Côté logiciel la question se pose dans les mêmes termes, ce chemin de code est-il seulement atteignable. C'est le seul travail que rien n'automatise.Ce que rien n'automatise
Chaque année, l'AQC publie le Flop 10 des désordres décennaux, établi sur les sinistres réellement déclarés. C'est l'exact équivalent de l'OWASP Top 10 : dans les deux cas, on classe les familles les plus fréquentes à partir de ce que l'on observe sur le terrain, et non de ce que l'on redoute.
Les trois scores
Ce que chacun mesure, et ce qu'il laisse de côté
Aucun des trois ne se suffit à lui-même, et ce n'est pas un défaut : ce qui les rend utiles, c'est justement qu'ils ne mesurent pas la même chose.
Les confondre produit les deux erreurs symétriques que nous voyons le plus souvent, courir pour une faille inatteignable et laisser dormir une faille exploitée.
CVSS : la gravité
Une note de 0 à 10, attachée à la faille elle-même. Ce qu'elle ne dit pas : si le code vulnérable est atteignable chez vous, ni si quelqu'un s'en sert.
EPSS : la probabilité
Une probabilité d'exploitation à trente jours, recalculée chaque jour. Ce qu'elle ne dit pas : une probabilité faible n'est pas une absolution, elle repousse le traitement dans un lot plus lointain.
KEV : le constat
L'exploitation observée, pas supposée. Ce qu'il ne dit pas : une faille absente du catalogue n'est pas inoffensive, elle n'a simplement pas encore été vue à l'oeuvre.
GOUVERNANCE DES SOURCES
D'où viennent ces identifiants, et qui les tient
Des engagements contractuels reposent sur ces catalogues, et la question de savoir qui les opère ne se pose presque jamais. Elle mérite pourtant de l'être une fois.
Nous n'en tirons aucune conclusion alarmiste : le programme fonctionne et rien ne s'est interrompu. Nous en tirons une pratique. Nos outils s'appuient sur plusieurs sources plutôt qu'une, et une grille de délais adossée à un seul catalogue serait un engagement bâti sur un point unique de défaillance.
Un programme financé par contrat
Le programme CVE est opéré par le MITRE, organisation américaine à but non lucratif, sous financement d'une agence fédérale. En avril 2025, le contrat qui le finance est passé à quelques heures de ne pas être renouvelé.
Un identifiant commun, donc un point de passage unique
composer audit, npm audit, osv-scanner, les avis GitHub, l'EPSS et le KEV s'accordent tous sur la CVE. C'est ce qui rend la chaîne outillée cohérente, et c'est aussi ce qui la rend dépendante d'un seul catalogue.
Trois organisations, aucune européenne
Le catalogue KEV est publié par la CISA, le CVSS et l'EPSS par le FIRST. L'épisode d'avril 2025 a fait naître une CVE Foundation et accéléré la mise en service de l'EUVD, la base de vulnérabilités de l'agence européenne de cybersécurité.
Ce que nous en faisons
Mettre à jour en continu, puis juger ce qui reste
Les deux mouvements sont complémentaires, et le second ne s'automatise pas.
C'est aussi ce qui rend un forfait de maintenance raisonnable : les outils absorbent le volume, le temps de cerveau se concentre là où il change quelque chose.
Tenir les dépendances à jour, en continu
- Le principe : Ne pas attendre qu'une faille impose un rattrapage. Sur un projet suivi, l'essentiel des vulnérabilités publiées disparaît avant qu'un délai ait eu à servir : la version corrigée est déjà en production.
- L'effet de bord, qui est le principal : Chaque saut de version reste petit, donc peu risqué. Une application suivie ne connaît pas de migration à hauts risques.
- Le geste, en détail : Nous l'avons décrit sur un projet réel dans notre article sur la mise à jour technique et le suivi des versions.
Qualifier ce que l'automatisation ne règle pas
- Ce qui reste : Un correctif qui casse un comportement, une faille sans correctif publié, une bibliothèque abandonnée, une montée de version majeure à arbitrer.
- La question qu'aucun outil ne tranche : Ce chemin de code est-il seulement atteignable, et le composant tourne-t-il en production ou seulement en développement. Y répondre demande de lire le projet.
- Le même partage ailleurs : Il vaut pour toute la sécurité applicative : notre page sur l'OWASP Top 10 dit risque par risque ce qui se vérifie, y compris quand la réponse est « aucun outil ».
Croiser les trois sources, jamais une seule
- Pourquoi : Une note de gravité seule fait courir pour une faille inatteignable. Une probabilité seule fait dormir sur une faille déjà exploitée.
- En pratique : Gravité, probabilité d'exploitation et exploitation constatée sont interrogées ensemble, et le délai se décide sur les trois.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Un CWE est un type de faiblesse, une CVE est une occurrence de ce type dans un produit précis. CWE-89 désigne l'injection SQL en général, partout où elle peut exister. Une CVE désigne une injection SQL particulière, dans telle bibliothèque, à telle version, corrigée à telle autre. Un enregistrement CVE porte d'ailleurs le CWE qui le classe : les deux se lisent ensemble.
Non, et c'est le contresens le plus répandu. La note de base décrit la gravité de la faille dans l'absolu, en ignorant votre contexte. Une note de 9,8 sur une bibliothèque que vous n'utilisez qu'en développement, ou sur une fonction que votre code n'appelle jamais, ne justifie aucune intervention en urgence. À l'inverse, une note de 6,5 inscrite au catalogue KEV, donc exploitée pour de vrai, en justifie une.
Parce qu'un correctif n'est pas neutre. Il faut le tester, vérifier qu'il ne casse rien, parfois monter une version majeure de la dépendance et adapter le code appelant. Sur une application métier en production, appliquer un correctif sans recette revient à échanger un risque de sécurité contre un risque d'indisponibilité. C'est aussi pour cela que la mise à jour continue est plus efficace qu'un rattrapage en urgence : elle rend chaque saut petit.
Le délai ne peut pas courir sur un correctif qui n'est pas publié. La question devient celle des mesures compensatoires : désactiver la fonction concernée, restreindre les accès qui y mènent, renforcer la surveillance, et informer. C'est la situation la moins confortable de la gestion des vulnérabilités, et la plus fréquente sur une dépendance dont le mainteneur a cessé son travail.
Non, et c'est important : les trois sont gratuits et automatisables. Le CVSS accompagne l'avis de sécurité, le KEV est une liste publique interrogeable, l'EPSS expose une interface de programmation ouverte. Personne ne calcule rien à la main. Ce qui n'est pas automatisable, c'est de savoir si la fonction vulnérable est réellement appelée par le code : ce jugement demande de lire le projet.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.