Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

CPE (Common Platform Enumeration)

general

Définition

La CPE (Common Platform Enumeration) est un schéma de nommage standardisé pour identifier de manière unique et non ambiguë les plateformes logicielles et matérielles (systèmes d'exploitation, applications, équipements réseau). Maintenu par NIST et intégré dans le NVD, le CPE permet d'associer précisément les vulnérabilités CVE aux produits et versions spécifiques affectés. Le format CPE 2.3 suit la structure : cpe:2.3:type:fournisseur:produit:version:mise_à_jour:édition:langue:édition_sw:target_sw:target_hw:autres. Par exemple, cpe:2.3:o:microsoft:windows_server_2022:*:*:*:*:*:*:*:* identifie Microsoft Windows Server 2022 toutes versions. Les types incluent : a (application), o (operating system), h (hardware). L'utilisation principale du CPE est dans la gestion des vulnérabilités. Lorsqu'une CVE est publiée dans le NVD, elle inclut la liste des CPE affectés — permettant aux outils de vulnerability management (Qualys, Rapid7 InsightVM, Tenable.io, OpenVAS) de corréler automatiquement les vulnérabilités connues avec les actifs inventoriés dans le CMDB. Cette corrélation automatique est le moteur fondamental de tout programme de gestion des vulnérabilités à l'échelle. Le CPE complète le SCAP (Security Content Automation Protocol) avec CVE, CVSS, XCCDF (pour les politiques de configuration) et OVAL (pour les descriptions de tests). Ces standards interopérables permettent l'automatisation des évaluations de conformité et de sécurité à grande échelle. Pour les équipes d'opérations sécurité, la richesse du dictionnaire CPE du NVD (plusieurs millions d'entrées) permet une couverture quasi-exhaustive des produits commerciaux et open-source. La précision du nommage CPE est critique : une mauvaise identification d'un actif peut entraîner des faux négatifs dans la détection des vulnérabilités, laissant des systèmes vulnérables non détectés. Les inventaires d'actifs (CMDB, ITAM) qui intègrent le nommage CPE standardisé peuvent être directement consommés par les outils de vulnerability management, créant un flux continu de détection des expositions entre la découverte d'actifs et la publication de nouvelles CVE.

CPE et gestion des vulnérabilités automatisée

L'automatisation de la gestion des vulnérabilités repose entièrement sur la corrélation CPE-CVE. Lorsqu'un scanner de vulnérabilités identifie Apache HTTP Server 2.4.51 sur un serveur (CPE : cpe:2.3:a:apache:http_server:2.4.51:*:*:*:*:*:*:*), il interroge le NVD pour toutes les CVE affectant ce CPE et calcule l'exposition. La qualité de cette corrélation dépend de la précision de l'inventaire des actifs. Les organisations avec des CMDB fiables et des scans de découverte réguliers bénéficient pleinement de cette automatisation.

Limites du CPE et alternatives

Le CPE présente des limites pratiques : les fournisseurs ne soumettent pas toujours leurs produits au dictionnaire NVD, la granularité peut être insuffisante pour les composants open-source distribués comme bibliothèques, et le nommage non standardisé par les fournisseurs crée des ambiguïtés. Des approches complémentaires émergent : les SBOM (Software Bill of Materials) au format SPDX ou CycloneDX offrent une granularité plus fine jusqu'au niveau des bibliothèques tierces, et les Package URLs (PURL) standardisent l'identification des composants dans les écosystèmes de packaging (npm, PyPI, Maven, etc.).

CPE dans les audits de conformité

Dans les audits de conformité (ISO 27001, PCI-DSS, HIPAA), la capacité à identifier précisément les logiciels et matériels en production — via CPE ou équivalent — est une exigence fondamentale. Le contrôle 2 des CIS Controls (Inventory and Control of Software Assets) et le contrôle A.8.8 d'ISO 27001 (Management of technical vulnerabilities) imposent un inventaire précis des actifs logiciels. Les audits vérifient la cohérence entre l'inventaire déclaré, les scans de découverte, et les résultats du vulnerability management pour s'assurer qu'aucun actif non géré ne présente des vulnérabilités critiques.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis