Comprendre les CVE

CVE, NVD, KEV : comprendre les failles de sécurité

Chaque jour, de nouvelles failles de sécurité sont découvertes dans les logiciels que nous utilisons. CVE, NVD, KEV — ces acronymes structurent toute la gestion mondiale des vulnérabilités.

1. CVE, NVD, KEV : trois outils distincts, un même objectif

La CVE : un identifiant universel

Le programme CVE (Common Vulnerabilities and Exposures) existe depuis 1999. Son rôle est simple : attribuer un identifiant unique à chaque faille de sécurité découverte, pour que tous — chercheurs, éditeurs, administrateurs systèmes — parlent de la même chose.

Un identifiant CVE se présente toujours ainsi :

CVE-2024-12345 Année de publication + numéro séquentiel

La CVE identifie la faille. Elle ne l'évalue pas, ne propose pas de correctif : c'est une référence, rien de plus.

La NVD : l'enrichissement de la CVE

La NVD (National Vulnerability Database), gérée par le NIST américain, prend le relais. Pour chaque CVE publiée, la NVD ajoute :

• Un score de gravité (CVSS, de 0 à 10)

• Une description de l'impact potentiel

• Les versions logicielles affectées

• Les correctifs disponibles

C'est la source de référence pour évaluer concrètement une faille.

La KEV : la liste des failles actives

La KEV (Known Exploited Vulnerabilities), publiée par la CISA américaine, est d'une nature différente. Elle ne recense pas toutes les CVE — seulement celles activement exploitées par des attaquants en ce moment.

C'est la liste rouge. Une CVE présente dans la KEV n'est plus théorique : elle est utilisée dans des attaques réelles.

💡 En résumé : La CVE nomme la faille. La NVD l'évalue. La KEV signale celles qui sont exploitées activement.

2. En quoi cela vous concerne-t-il ?

Tout logiciel peut être vulnérable

Les CVE ne concernent pas que les grandes infrastructures ou les serveurs d'entreprise. Elles touchent les navigateurs web, les systèmes d'exploitation, les applications bureautiques, les plugins WordPress, les équipements réseau grand public.

Si vous utilisez un logiciel — et c'est le cas de tout le monde — vous êtes potentiellement concerné.

Les conséquences concrètes d'une faille exploitée

Une CVE non corrigée peut permettre à un attaquant de :

• Prendre le contrôle d'un système à distance

• Accéder à des données personnelles ou professionnelles

• Chiffrer vos fichiers contre rançon

• Utiliser votre machine pour attaquer d'autres cibles

Quelques chiffres

• 85% des cyberattaques réussies exploitent des failles pour lesquelles un correctif existait déjà (Verizon DBIR)

• Une CVE critique est exploitée en moyenne dans les 15 jours suivant sa publication

• 60% des PME victimes d'une cyberattaque significative cessent leur activité dans les 6 mois (NCSA)

Ces chiffres pointent tous vers la même réalité : le délai entre la publication d'une CVE et son exploitation est court. La réactivité est le facteur clé.

Un exemple pour ancrer le sujet : Log4Shell

En décembre 2021, une faille est découverte dans Log4j, une bibliothèque Java intégrée dans des millions d'applications et de serveurs. Score CVSS : 10.0. Exploitable à distance, sans authentification.

En quelques heures après sa publication, des scans automatisés cherchaient des systèmes vulnérables sur l'ensemble d'Internet. Apple, Amazon, Microsoft et des milliers d'autres organisations ont dû réagir en urgence.

Log4Shell est devenu le cas d'école de ce que peut produire une CVE critique dans un composant logiciel largement répandu et souvent oublié.

3. Comment lire une fiche CVE

Les éléments essentiels

Une fiche CVE sur nvd.nist.gov contient plusieurs sections. Voici celles qui comptent vraiment :

L'identifiant et la description La description indique quel logiciel est affecté, quelles versions, et ce qu'un attaquant peut faire. Elle est en anglais mais suit toujours la même structure. Cherchez le nom du logiciel concerné et les termes suivants, qui signalent les failles les plus sérieuses :

• Remote code execution → exécution de code à distance

• Privilege escalation → élévation de privilèges

• Unauthenticated → exploitable sans identifiants

Le score CVSS

Copier le tableau

Nuance importante : Le score CVSS évalue la gravité théorique dans le pire des cas. Une CVE à 9.8 dans un logiciel que vous n'utilisez pas ne vous concerne pas. Une CVE à 6.5 dans un service exposé sur Internet peut être une priorité réelle.

Le vecteur d'attaque Il indique comment un attaquant doit se positionner pour exploiter la faille :

• Network → exploitable depuis Internet, sans accès préalable. Scénario le plus critique.

• Adjacent → l'attaquant doit être sur le même réseau local

• Local → accès préalable à la machine requis

• Physical → accès physique à l'appareil requis

Les versions affectées C'est la section qui vous permet de savoir si votre version est concernée. Si vous êtes dans la fourchette indiquée, la mise à jour s'impose. Si votre version n'est pas listée, cette CVE ne vous affecte pas.

Les références En bas de chaque fiche : les bulletins officiels des éditeurs, les correctifs disponibles, les analyses complémentaires. C'est un bon point de départ.

L'essentiel en pratique

Pour évaluer rapidement une CVE, quatre questions suffisent :

1. Le logiciel, l'outil, concerné est-il dans mon environnement, dans ma stack technique ?

2. Ma version est-elle dans la liste des versions affectées ?

3. Quel est le score CVSS et le vecteur d'attaque ?

4. Un correctif est-il disponible ?

4. Évaluer son exposition à une CVE

Connaître son parc logiciel

L'évaluation commence par un inventaire. Pour croiser une CVE avec votre environnement, vous devez connaître les logiciels déployés et leurs versions exactes — système d'exploitation, applications métier, bibliothèques, plugins, équipements réseau.

Dans un contexte professionnel, cet inventaire devrait exister sous forme de CMDB (Configuration Management Database) ou a minima d'un fichier tenu à jour. S'il n'existe pas, c'est le premier chantier à mener — indépendamment de toute CVE.

Croiser avec les sources de référence

Une fois l'inventaire disponible, trois sources permettent d'évaluer votre exposition :

NVD — nvd.nist.gov La recherche par nom de logiciel ou par identifiant CVE retourne les versions affectées, le score CVSS et les références vers les correctifs officiels. C'est le point de départ pour toute analyse.

KEV — cisa.gov/known-exploited-vulnerabilities Si un de vos logiciels figure dans cette liste, la faille est exploitée activement dans des attaques réelles. C'est une priorité de traitement immédiate, sans discussion.

endoflife.date Indique si une version logicielle est toujours maintenue par son éditeur. Un logiciel en fin de support ne recevra plus de correctifs — toute CVE le concernant restera ouverte indéfiniment.

CERT-FR — cert.ssi.gouv.fr L'agence française publie des avis et alertes contextualisés, en français, avec des recommandations opérationnelles. Une source incontournable pour les organisations françaises.

Contextualiser le risque

Le score CVSS donne une indication de gravité théorique, pas de risque réel. Deux facteurs font basculer l'analyse :

L'exposition du service. Une vulnérabilité avec un vecteur d'attaque Network sur un service exposé à Internet est à traiter en urgence. La même CVE sur un système isolé en réseau interne relève d'une autre échelle de priorité.

La disponibilité d'un exploit. Certaines CVE restent sans code d'exploitation publié pendant des semaines ou des mois. D'autres voient un exploit fonctionnel publié dans les heures suivant leur divulgation. La mention "exploit code maturity : functional" ou la présence de la CVE dans la KEV sont des signaux d'urgence concrets.

5. Réduire son exposition et organiser la réponse

La mise à jour : le seul remède pérenne

Corriger une CVE passe presque toujours par l'application d'un patch officiel. Les contournements temporaires peuvent réduire l'exposition, mais ne substituent pas à la correction.

Un processus de patch management structuré est la réponse organisationnelle à cette réalité :

• Définir une cadence de vérification adaptée à chaque type de système — plus fréquente pour les environnements exposés

• Tester les mises à jour critiques avant déploiement en production lorsque le contexte le permet

• Documenter les versions en production et les dates de dernière mise à jour

• Anticiper les fins de support pour éviter les migrations sous contrainte

Réduire la surface d'attaque

La mise à jour traite les vulnérabilités connues. La réduction de la surface d'attaque limite l'impact des vulnérabilités inconnues ou non encore corrigées.

Principe du moindre privilège. Chaque compte, chaque service, chaque application dispose uniquement des droits nécessaires à son fonctionnement. Une CVE exploitée dans un contexte de privilèges limités a un rayon d'action significativement réduit.

Exposition minimale. Tout service, interface d'administration ou port réseau non strictement nécessaire ne devrait pas être exposé — a fortiori sur Internet. La surface d'attaque se réduit en supprimant ce qui est inutile, pas seulement en le sécurisant.

Segmentation réseau. Cloisonner les systèmes critiques limite la propagation latérale en cas de compromission. Une faille exploitée dans un segment ne devrait pas ouvrir l'accès à l'ensemble de l'infrastructure.

Gérer une zero-day

Lorsqu'une CVE est publiée sans correctif disponible — une zero-day — l'éditeur ou le CERT-FR publie généralement des mesures de contournement : désactivation d'une fonctionnalité, restriction d'accès, règles de filtrage spécifiques.

Ces mesures ne corrigent pas la faille. Elles réduisent la fenêtre d'exposition dans l'attente du patch officiel. Les appliquer rapidement fait partie d'une gestion rigoureuse des vulnérabilités.

Organiser la veille

Une bonne gestion des CVE repose sur une information rapide. Quelques sources suffisent pour une veille efficace :

• Alertes CERT-FR — abonnement par email, filtrables par technologie

• Bulletins éditeurs — Microsoft Patch Tuesday, bulletins Adobe, Oracle, et tout éditeur présent dans votre parc

• Flux NVD — pour un suivi direct des publications

Pour les organisations avec un parc significatif, des outils comme Tenable, Qualys ou OpenVAS automatisent la corrélation entre les CVE publiées et les actifs réels. Ils ne remplacent pas le jugement humain sur la priorisation, mais réduisent considérablement le travail manuel.

Synthèse : adapter la réponse à son contexte

Il n'existe pas d'approche universelle. Le niveau de rigueur doit être proportionnel à l'exposition et aux enjeux.

Pour une organisation sans équipe technique dédiée, l'essentiel est d'avoir un inventaire logiciel à jour, d'activer les mises à jour automatiques là où c'est possible, et de suivre les alertes CERT-FR pour les logiciels critiques.

Pour une équipe technique, un processus de patch management formalisé, une veille structurée et des outils de gestion des vulnérabilités sont des attendus normaux — pas des options.

Dans tous les cas, la question n'est pas de savoir si une CVE vous concernera un jour, mais quand — et si votre organisation est en mesure d'y répondre dans un délai raisonnable.