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.

4.20 Liste CWE en vigueur 944 types de faiblesse recensés et hiérarchisés, mis à jour en continu par le MITRE.
4.0 Version du CVSS Publiée par le FIRST, c'est la notation que portent les avis de sécurité.
3 Entrées dans le KEV Trois conditions cumulatives pour y figurer : un identifiant CVE, un correctif disponible, une preuve d'exploitation.

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.

Schéma de la chaîne : le CWE nomme le type de défaut, la CVE nomme la faille dans un produit et une version et porte le CWE qui la classe, puis le CVSS la note, l'EPSS en estime la probabilité d'exploitation et le KEV constate son exploitation réelle

Comprendre la logique

De la faiblesse générique à la faille de votre application

1

É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.

Écran d'application annoté : CWE-311 sur l'adresse en clair, CWE-89 sur un paramètre d'URL, CWE-287 et CWE-306 sur le formulaire de connexion
2

É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.

Fiche NVD de CVE-2026-45077 : description de la faille Symfony, versions corrigées, références vers les correctifs et tableau des CWE associées
La fiche de CVE-2026-45077, une faille de Symfony publiée en juillet 2026. Elle nomme le produit, liste les versions qui la corrigent, et porte deux CWE en classification : CWE-502, désérialisation de données non fiables, et CWE-668.
3

É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.

Panneau des métriques CVSS 4.0 de la même CVE : score de base 8.3 HIGH attribué par le CNA, avec la chaîne de vecteur
Le même enregistrement, panneau des métriques : 8,3 sur 10, sévérité élevée. La chaîne de vecteur détaille comment la note est obtenue, et le NVD signale qu'il n'a pas encore fait sa propre évaluation : la note affichée est celle de l'autorité de nommage.
4

É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.

Réponse JSON de l'API EPSS du FIRST pour CVE-2026-45077 : epss 0.00666, percentile 0.49723, date 2026-09-09
La même faille interrogée sur l'API du FIRST : 0,67 % de probabilité d'exploitation dans les trente jours, au 49e centile. Gravité élevée, exploitation improbable. C'est tout l'écart entre les deux mesures.
Catalogue KEV de la CISA : fiche de CVE-2024-4577, injection de commande dans PHP-CGI, usage constaté dans des campagnes de rançongiciel, date d'ajout et échéance de correction
Une autre faille, CVE-2024-4577 sur PHP-CGI, inscrite au catalogue KEV. Exploitation constatée, usage avéré dans des campagnes de rançongiciel, et une échéance de correction fixée trois semaines après l'inscription. Ici, ce n'est plus une probabilité.

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.

Coupe technique d'un seuil de porte-fenêtre montrant le cheminement d'une infiltration d'eau

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

Boîte de chevilles de fixation métalliques posée sur un plan de travail d'atelier

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

Banc d'essai mesurant la résistance à l'arrachement d'une cheville scellée dans du béton

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

Dossier d'assurance ouvert sur un graphique de sinistralité examiné à la loupe

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

Garde-corps de balcon effondré au pied d'un immeuble, périmètre de sécurité en place

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

Professionnel du bâtiment accroupi sur un balcon, examinant la platine de fixation d'un garde-corps

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

L'analogie tient un cran plus loin

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.

1

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é.

2

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.

3

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.