Vous lancez un scan de vulnérabilités sur un parc client et le résultat tombe : 250 CVE détectées, dont une vingtaine classées comme critiques. Impossible de tout corriger immédiatement. Alors, par où commencer ? Quelles vulnérabilités présentent réellement le plus de risques ?
C'est ici qu'interviennent les notions de CVE et de CVSS : la première permet d'identifier une vulnérabilité connue tandis que la seconde aide à mesurer son niveau de gravité. Les deux sont complémentaires mais ne répondent pas au même besoin dans une démarche de gestion des vulnérabilités.
Pour un MSP ou prestataires IT, comprendre la différence entre CVE et CVSS permet d'éviter de passer du temps sur des failles peu exposées ou, à l'inverse, sous-estimer une vulnérabilité qui présente un risque réel pour un client.
Une CVE est avant tout un identifiant. Elle ne précise pas le niveau de gravité d'une vulnérabilité, elle permet simplement de reconnaître qu’il s’agit bien d’une faille de sécurité.
Lorsqu'on effectue une évaluation, un scan des vulnérabilités applicatives et qu'une faille est découverte dans Windows, Chrome, Adobe Reader ou n'importe quel autre logiciel, elle reçoit généralement un identifiant unique.
Par exemple : CVE-2025-12345
Cet identifiant sert de référence commune. En effet, sans ce système, chaque éditeur de logiciels décrirait les vulnérabilités à sa manière et il serait alors plus compliqué de suivre les correctifs ou les alertes de sécurité.
Le programme CVE est piloté par l'organisation MITRE Corporation. Lorsqu'une vulnérabilité est découverte, elle est donc analysée puis reçoit un identifiant unique comme vu précédemment.
Celui-ci est ensuite référencé dans différentes bases de données, notamment le NVD (National Vulnerability Database).
La fiche associée évolue au fil du temps : de nouveaux détails techniques peuvent être ajoutés, des correctifs publiés ou des méthodes d'exploitation documentées. Cette base de connaissances est utilisée par de nombreuses organisations, éditeurs de logiciels et acteurs de la cybersécurité pour suivre l'évolution des vulnérabilités connues.
Les équipes IT utilisent les identifiants CVE au quotidien car ils fluidifient les échanges.
Exemple : lorsqu'un éditeur annonce qu'un correctif corrige la CVE-2025-12345, tout le monde sait exactement de quelle vulnérabilité il s'agit.
C'est également ce qui permet à la fonctionnalité de détection des vulnérabilités logicielles récemment intégrée dans RG System Suite d'associer automatiquement une faille connue à une version précise d'un logiciel installé sur un poste ou un serveur.
Cette approche facilite la gestion des vulnérabilités à grande échelle, notamment lorsqu'un MSP supervise plusieurs milliers d'équipements.
Si la CVE sert à identifier une vulnérabilité, le score CVSS sert à estimer son niveau de danger avec un système de notation. Il est donc important pour prioriser les actions à venir.
C'est lui que l'on retrouve le plus souvent dans les tableaux de bord de cybersécurité ou les rapports de vulnérabilités.
Le CVSS est donc un système de notation qui attribue une note comprise entre 0 et 10 à une vulnérabilité.
L'objectif est ainsi de fournir un indicateur standardisé permettant d'évaluer rapidement sa gravité. Plus le score est élevé, plus la vulnérabilité présente un potentiel d'impact important. En revanche, le CVSS ne mesure pas directement la probabilité qu'une vulnérabilité soit effectivement exploitée dans un environnement donné.
Le CVSS est aujourd'hui considéré comme l'une des principales métriques utilisées par les équipes cybersécurité pour comparer et prioriser les vulnérabilités.
Aujourd’hui, on retrouve surtout les versions CVSS v3.1 dans les bases de données et les rapports de vulnérabilités. La version CVSS v4.0, publiée plus récemment, apporte une lecture plus fine du contexte d’exploitation et de l’impact potentiel.
Pour un MSP, le réflexe reste le même : vérifier la version utilisée avant de comparer deux scores, puis croiser cette information avec le contexte réel du client.
Le calcul d'une notation CVSS prend en compte plusieurs critères techniques.
Par exemple :
Ces différentes mesures permettent d'obtenir une vision homogène du niveau de risque associé à une vulnérabilité.
Au-delà de la simple notation, ces mesures offrent un cadre commun pour comparer des vulnérabilités affectant des systèmes, des applications ou des environnements très différents.
Une faille exploitable depuis Internet sans authentification et permettant une prise de contrôle complète d'un serveur obtiendra généralement un score très élevé.
Dans la pratique, les scores sont souvent regroupés de la manière suivante :
Cette classification permet d'obtenir une première vision des menaces susceptibles d'affecter un système ou une application.
En revanche, elle ne suffit pas toujours à déterminer l'ordre dans lequel les vulnérabilités doivent être corrigées.
Comme nous venons de le voir, la différence est simple :
Dans les faits, les deux notions sont souvent affichées côte à côte dans les outils ou logiciel de cybersécurité, ce qui explique qu'elles soient régulièrement confondues.
Une CVE ressemble davantage à une fiche d'identité. Elle permet de référencer une faille précise, mais elle ne donne aucune indication sur son niveau de danger ou sur la gravité réelle de la menace.
Deux vulnérabilités différentes peuvent ainsi avoir des impacts totalement opposés tout en étant référencées selon le même format.
C'est un point souvent négligé. En effet, une vulnérabilité critique affectant un serveur exposé sur Internet ne présente pas le même niveau de risques que cette même vulnérabilité présente sur une machine isolée du réseau.
Le score CVSS fournit alors une base de comparaison commune, mais il ne connaît ni votre infrastructure ni les usages de vos clients.
C'est d'ailleurs l'une des raisons pour lesquelles deux vulnérabilités affichant des scores proches peuvent nécessiter des traitements très différents sur le terrain.
Non, il ne faut pas se baser uniquement sur le score CVSS pour agir face aux potentielles menaces et prioriser les actions de remédiation.
Exemple : un MSP supervise environ 3 000 postes et 120 serveurs répartis chez plusieurs clients. Lors d'un scan, deux vulnérabilités sont détectées : une élevée et une critique.
Si l'on regarde uniquement le score CVSS, la seconde vulnérabilité semble plus grave et donc la menace plus importante.
Pourtant, dans la réalité, le MSP commencera souvent par corriger la faille présente sur le serveur RDS. Si ce serveur est compromis, les conséquences pour le client peuvent être immédiates : interruption d'activité, accès non autorisé au système ou propagation de l'attaque à d'autres équipements.
Ce type de situation est fréquent lorsqu'un MSP gère plusieurs centaines ou milliers de postes.
Prenons un autre exemple : une même vulnérabilité détectée sur deux postes de travail. Dans les deux cas, il s'agit de la même CVE, du même logiciel et du même score CVSS. Pourtant, le niveau de priorité ne sera pas forcément identique. Si le premier poste appartient à un collaborateur qui utilise quotidiennement son navigateur pour accéder à des applications métiers, consulter des documents externes ou échanger avec des clients, le risque d'exposition est naturellement plus élevé, voire critique. À l'inverse, si la même vulnérabilité est détectée sur une machine qui a une fonction de test, rarement utilisée et n'hébergeant aucune donnée sensible, son traitement pourra parfois attendre quelques jours. La vulnérabilité est identique sur le papier, mais son contexte d'utilisation modifie complètement la façon dont un MSP va évaluer le risque et organiser ses actions de remédiation.
Ce type d'exemple montre bien que l'exploitation potentielle d'une vulnérabilité dépend également du contexte et non uniquement des scores affichés dans un outil de gestion des vulnérabilités.
Le score CVSS constitue donc un excellent indicateur mais il doit toujours être complété par une analyse du contexte réel, des données disponibles sur l'environnement concerné et par les bonnes pratiques de priorisation mises en place par le MSP ou l'équipe IT.
Pour aller plus loin que la simple notation, le MSP doit aussi évaluer l'exposition réelle de la machine concernée : serveur accessible depuis Internet, poste isolé, application métier sensible ou environnement peu utilisé.
Comprendre la différence entre une CVE et un score CVSS est une première étape pour mieux gérer les vulnérabilités d'un parc informatique. Dans la pratique, les MSP doivent également tenir compte du contexte, de l'exposition réelle des systèmes et des usages des utilisateurs afin de prioriser efficacement leurs actions de remédiation. C'est cette combinaison entre données techniques et connaissance du terrain qui permet de traiter les vulnérabilités les plus critiques au bon moment.
Pour aller plus loin, découvrez comment notre fonctionnalité de gestion des vulnérabilités aide les MSP à identifier les logiciels exposés et à prioriser leurs actions de remédiation.