Résumé

  • Le rapport de MITRE publié en 2002 date le lancement public de CVE de septembre 1999 et compte 321 entrées initiales. Il décrit une passerelle logique entre bases et outils existants.
  • Dans leur article de conception de 1999, les auteurs expliquent que relier deux à deux N bases de vulnérabilités demande un effort de l'ordre de N² ; un répertoire commun réduit les raccordements à N. Ils laissent gravité, configuration locale et efficacité des outils hors du nom.

Le même défaut portait plusieurs étiquettes

Les éditeurs de scanners tenaient chacun leur base, avec leurs mots et leur découpage. Un administrateur pouvait recevoir un résultat de détection, consulter un bulletin et ne pas savoir si les deux textes parlaient de la même faille. L'article de MITRE de 1999 pose ce problème d'interopérabilité avant de proposer une solution : un identifiant unique et une description assez précise pour distinguer une vulnérabilité des autres.

Cette économie était calculée. Sans point commun, chaque produit doit traduire ses noms vers ceux de tous les autres. Avec CVE, il suffit de faire correspondre chaque catalogue au même répertoire. La comparaison N² contre N ne mesure pas le nombre de failles ; elle mesure le coût des rapprochements entre sources. CVE devenait une adresse de correspondance, non un instrument qui analyse lui-même toutes les machines.

Les auteurs ont résisté à la tentation d'imposer une grande classification universelle. Leur texte appelle CVE une concordance, un index. Chaque base gardait sa manière de classer le danger et de servir ses utilisateurs. Une liste légère avait plus de chances de circuler entre des produits rivaux qu'un nouveau schéma complet exigeant la capitulation de tous les anciens. Le compromis de conception tenait en peu de champs : nom, courte description et références.

Un numéro ne chiffrait pas le danger

Le préfixe et l'année donnent à un identifiant CVE une allure officielle. L'article de 1999 précise pourtant que le numéro ne représente ni l'ordre de découverte ni la gravité. Il ne dit pas non plus si une configuration donnée est exposée, ou si un scanner traite correctement le cas. Ces questions appartiennent aux outils, aux fournisseurs et aux responsables des systèmes.

L'attribution du nom demandait tout de même du jugement. Une proposition pouvait recevoir un nom provisoire CAN, puis être examinée par le comité éditorial. Le processus décrit par MITRE prévoyait rejet d'un doublon, modification, fusion de cas ou séparation d'un cas trop large. Derrière la simplicité du résultat, il fallait décider ce qui constituait un problème commun. Le comité validait l'entrée du répertoire ; il ne validait pas le correctif installé dans un centre de données.

Le bilan de 2002 revient au lancement de septembre 1999 : 321 entrées et une distribution publique. MITRE présentait la liste comme un pont logique, pas comme une base destinée à remplacer les produits commerciaux. Les fabricants pouvaient citer le même nom dans leurs bulletins et pages de mise à jour ; les scanners pouvaient s'y raccorder. Il restait à vérifier l'exposition réelle du système, trouver la correction appropriée et prouver que le service réparé fonctionnait.

Ce qui paraissait modeste était une infrastructure de coordination. Une faille pouvait garder plusieurs récits techniques, mais l'analyste disposait d'un point pour les joindre. Les 321 entrées représentaient la taille de la première liste publique, ni le nombre de toutes les vulnérabilités existantes ni celui des réparations effectuées. CVE désignait la fissure ; il fallait encore prendre les outils.