CPE, vendors et produits : le chaînon manquant entre catalogue CVE et risque réel

Le catalogue CVE mondial est vaste. Il contient des vulnérabilités qui ne toucheront jamais votre organisation. La valeur opérationnelle apparaît lorsqu’on peut répondre : quelles CVE concernent mes produits, mes versions, mes périmètres ? C’est le rôle des CPE et du matching vendor/product.

Une CVE sans mapping actif est une information. Une CVE reliée à un CPE surveillé devient un finding. Cette distinction évite de transformer chaque ligne du catalogue en alerte.

Le problème du catalogue global

Un catalogue enrichi avec NVD, OpenCVE, KEV, GCVE, EPSS, CERT-FR, MSRC, GHSA, Exploit-DB, Nuclei et advisories fournisseurs est indispensable. Mais il représente le monde entier. Sans inventaire local, il ne sait pas ce qui vous concerne.

Le matching CPE permet de créer un pont entre :

• les vendors et produits connus ;
• les versions déclarées ou découvertes ;
• les CVE associées ;
• les périmètres métier ou techniques ;
• les propriétaires de remédiation.

Dans CVE Watch, ce pont sert à produire des findings plutôt qu’une liste infinie de CVE.

CPE et qualité d’inventaire

Le meilleur score CVE ne compense pas un inventaire faux. Si un produit est mal nommé, si la version est absente, ou si un asset n’a pas de propriétaire, la priorisation perd sa force. Les CPE obligent à structurer l’inventaire : vendor, product, version, périmètre, usage.

La qualité d’inventaire doit être mesurée. Combien de produits surveillés ont une version ? Combien sont rattachés à un propriétaire ? Combien ont un périmètre métier ? Ces questions sont aussi importantes que le nombre de CVE high.

Le matching n’est pas une preuve définitive

Un CPE indique une correspondance. Il ne prouve pas toujours l’exploitabilité. Une bibliothèque vulnérable peut être présente mais non appelée. Un service peut être désactivé. Une version peut être patchée par backport. À l’inverse, un composant exposé peut être vulnérable même si l’inventaire l’a mal classé.

La bonne pratique consiste donc à combiner matching CPE et contexte :

• exposition réseau ;
• criticité de l’actif ;
• statut patch ;
• KEV ou GCVE ;
• EPSS ;
• PoC public ;
• advisories éditeurs ;
• logs et signaux SOC.

OpenCVE vendor/product et recherche

OpenCVE aide à naviguer dans les vendors et produits. Un miroir vendor/product rend l’expérience plus fluide : recherche, suggestions, top products, exploration de surface. Cette donnée complète le NVD, qui reste le socle de description CVE.

Pour les équipes qui découvrent leurs périmètres, la recherche produit est souvent plus naturelle que la recherche CVE ID. On ne sait pas toujours quelle CVE chercher ; on sait qu’on utilise tel produit.

Liens avec la supply chain

Le matching produit ne concerne pas seulement les serveurs. Les dépendances applicatives, images container, packages open source et SBOM doivent rejoindre la même logique. Consultez SBOM Security et Supply Chain CVE Response pour étendre ce modèle aux dépendances logicielles.

Comment organiser les périmètres

Un périmètre utile doit refléter une responsabilité réelle. Il peut représenter une application, une ligne métier, un segment réseau, une équipe produit ou une famille d’actifs. L’objectif n’est pas seulement de classer les CPE, mais d’attribuer la remédiation. Si un finding apparaît, quelqu’un doit savoir s’il lui appartient.

Les périmètres trop larges deviennent difficiles à exploiter : tout le monde reçoit trop d’alertes. Les périmètres trop fins créent une charge administrative. Un bon équilibre consiste à regrouper les produits selon les équipes capables de patcher ou de décider une mitigation.

Déduplication et versions

Le matching CPE doit aussi gérer les doublons. Le même produit peut apparaître dans plusieurs formes : nom commercial, nom package, vendor historique, fork, appliance rebadgée. Sans normalisation, les équipes reçoivent plusieurs findings pour le même problème ou ratent une correspondance.

La version est un autre point critique. Certaines distributions appliquent des backports : le numéro de version amont semble vulnérable, mais le correctif est déjà porté. Dans ces cas, l’advisory fournisseur et les notes de distribution doivent compléter le matching CPE.

Mesurer la qualité du matching

Les métriques utiles incluent le nombre de CPE surveillés, le taux de CPE avec vendor/product/version, le nombre de findings par périmètre, le taux de findings sans propriétaire et le temps moyen de traitement. Ces indicateurs révèlent si le problème est la vulnérabilité elle-même ou l’inventaire.

Un programme mature révise aussi les périmètres après incident. Si une CVE exploitée n’a pas produit de finding alors qu’un actif était concerné, il faut corriger le mapping, pas seulement le patch.

Quand le CPE doit être complété par d’autres signaux

Le CPE est puissant, mais il ne couvre pas tout. Les services SaaS, composants serverless, bibliothèques embarquées et images containers ne sont pas toujours décrits proprement par un CPE unique. Dans ces cas, il faut rapprocher les données SBOM, les advisories packages, les scans d’image et les métadonnées cloud.

L’objectif reste le même : transformer un nom de technologie en responsabilité de remédiation. Le CPE est une colonne vertébrale utile, mais une plateforme moderne doit accepter plusieurs chemins de matching. Une dépendance GHSA, un package npm, une image container ou une appliance fournisseur peuvent tous mener au même résultat : un finding CVE assignable.

Conclusion

Les CPE transforment la connaissance CVE en risque organisationnel. Sans eux, le catalogue reste global ; avec eux, il devient local, filtrable et assignable. Le meilleur programme CVE n’est pas celui qui connaît le plus de vulnérabilités, mais celui qui sait lesquelles touchent réellement ses produits.