Les bases de données de vulnérabilités : CVE, NVD, CVSS et CWE

Vous avez une carte : machines, ports, services, versions annoncées. La question devient : ces versions ont-elles des faiblesses connues ? Heureusement, la communauté de la sécurité tient des registres publics et standardisés des failles découvertes. Cette leçon vous apprend à les lire, car c'est la compétence la plus utilisée au quotidien par un testeur comme par un défenseur.

La reconnaissance a produit un inventaire. L'analyse de vulnérabilités consiste à confronter cet inventaire à la connaissance publique des failles, pour dresser une liste de pistes sérieuses. Elle se mène toujours dans le périmètre autorisé, et elle reste une analyse : repérer qu'une faille peut exister n'est pas encore démontrer qu'elle est exploitable. Ce sera l'objet du chapitre suivant, uniquement dans votre labo.

Pourquoi un système de référence ?

Imaginez que chaque éditeur, chaque chercheur et chaque journaliste nomme à sa façon une même faille : impossible de savoir si l'on parle de la même chose, ni si la correction publiée traite bien le même problème. Pour éviter ce désordre, des identifiants communs ont été créés. Voici les quatre que vous devez connaître.

CVE : un numéro pour chaque faille connue

Un CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une vulnérabilité publiquement connue. Son format est CVE-ANNÉE-NUMÉRO, par exemple CVE-2019-0000 (numéro fictif ici, par prudence). L'année correspond à celle de l'attribution de l'identifiant et non forcément à celle de la découverte ou de la correction.

Le programme CVE, dont le site est cve.org, est coordonné par des organismes à but non lucratif, avec un réseau d'autorités qui attribuent des identifiants (éditeurs, chercheurs, organismes). Une fiche CVE contient une courte description, des références vers les avis de l'éditeur et les correctifs, et le nom des produits concernés. Elle ne contient pas de mode d'emploi pour attaquer : c'est un identifiant et un résumé.

NVD : l'enrichissement des fiches

La NVD (National Vulnerability Database), hébergée par le NIST aux États-Unis (nvd.nist.gov), reprend les fiches CVE et les enrichit : score de gravité, liste précise des produits et versions concernés (selon une nomenclature standard), type de faiblesse, références utiles. C'est la base que l'on consulte pour savoir si la version de votre service est concernée.

Une consultation typique se fait ainsi : vous recherchez le nom du produit et sa version, vous lisez les fiches associées, et vous vérifiez que la version annoncée par la bannière figure bien dans la liste des versions concernées. Retenez qu'une recherche par mots-clés peut renvoyer beaucoup de résultats parasites ; la précision des critères (nom exact, version) évite de se noyer.

CVSS : mesurer la gravité

Le CVSS (Common Vulnerability Scoring System) est un système qui attribue à une vulnérabilité une note de 0 à 10 selon des critères standardisés : comment l'attaquer (réseau, local), la complexité, les privilèges requis, l'interaction d'un utilisateur, et l'impact sur la confidentialité, l'intégrité et la disponibilité. La note est associée à une catégorie qualitative :

Le CVSS mesure la gravité intrinsèque d'une faille, dans l'absolu. Il ne sait rien de votre contexte : une faille critique sur un serveur éteint et isolé est moins urgente qu'une faille moyenne sur un portail exposé contenant des données sensibles. Nous reviendrons sur cette nuance dans la dernière leçon du chapitre.

CWE : classer les types de faiblesses

Un CWE (Common Weakness Enumeration) ne décrit pas une faille précise dans un produit précis, mais un type de faiblesse : par exemple une validation insuffisante des entrées, une gestion fautive des droits, un mot de passe stocké sans protection. Une faille CVE est généralement rattachée à un ou plusieurs CWE. Ce classement aide à reconnaître les familles de problèmes et à orienter la prévention : c'est le lien avec les failles web que vous avez étudiées (injections, contrôle d'accès). Les projets OWASP (owasp.org) s'appuient sur ces familles dans leurs classements.

Lire une fiche de vulnérabilité

Voici comment décortiquer une fiche (exemple purement générique, sans identifiant réel) :

Identifiant      : CVE-AAAA-NNNN
Produit concerné : serveur web X, versions antérieures à la version corrigée
Type (CWE)       : validation insuffisante d'une entrée
Gravité (CVSS)   : 8,x (élevée)
Vecteur          : réseau, sans authentification, sans interaction utilisateur
Impact           : confidentialité, intégrité, disponibilité
Correctif        : mise à jour vers une version supérieure
Références       : avis de l'éditeur, notes de version

Posez-vous toujours ces questions : ma version est-elle bien concernée ? L'attaque nécessite-t-elle des conditions que mon contexte ne remplit pas ? Un correctif ou un contournement existe-t-il ? Quelle est la source de l'information ? Une fiche n'est pas une sentence : c'est un point de départ.

Les limites de ces bases

• Retard et incomplétude : une faille peut exister sans avoir de CVE, ou la fiche peut mettre du temps à être enrichie.
• Précision des versions : les distributions Linux appliquent souvent des correctifs sans changer le numéro de version majeur ; une version « concernée » sur le papier peut être corrigée dans la pratique.
• Faiblesses de configuration : un mot de passe par défaut ou un service mal configuré n'a pas toujours de CVE, et pourtant c'est une cause très fréquente d'incident.
• Failles propres à l'application : le code écrit sur mesure par une organisation n'a généralement pas de CVE.

Complément : le référentiel des comportements d'attaque

Pour relier ces failles à des comportements concrets d'attaquants, les défenseurs utilisent MITRE ATT&CK (attack.mitre.org), une base qui décrit les tactiques et techniques observées. Une CVE explique quelle faiblesse existe ; ATT&CK explique comment les attaquants s'en servent. Les deux se complètent dans un rapport : on y cite l'identifiant de la faille et la technique correspondante pour aider le client à améliorer sa détection.

À vous de jouer : documenter une piste

Choisissez dans votre carnet une ligne de la fiche de reconnaissance (par exemple « serveur web, version ancienne »). Consultez la NVD (en tant que source publique de documentation) et remplissez une fiche de piste : nom du produit et version annoncée, deux ou trois identifiants CVE qui semblent concerner cette version, leur gravité, leur vecteur, leurs conditions, et votre niveau de certitude (« annoncé », « déduit », « confirmé »). Ne cherchez pas de code d'attaque : seule la documentation vous intéresse à ce stade.

Consulter ces bases à la main est précieux, mais long. La leçon suivante présente les scanners automatisés qui font ce travail à grande échelle.