Le Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) impose aux fabricants de trier les vulnérabilités, de les corriger à temps et de signaler l'exploitation active lorsqu'ils en prennent connaissance. L'obligation de signalement de l'Article 14 s'applique à partir du 11 septembre 2026 ; les obligations de gestion des vulnérabilités, de remédiation et de divulgation prévues à l'Article 13 et à l'Annexe I s'appliquent à partir du 11 décembre 2027. Le CRA ne cite ni CVSS, ni EPSS, ni KEV, ni aucun autre système de notation. Cette page explique ce que chaque signal mesure, comment les combiner dans une priorisation défendable, et comment la notation soutient le signalement des vulnérabilités et la divulgation coordonnée des vulnérabilités.
Synthèse
- Le CRA n'impose aucun système de notation. Il exige une remédiation en temps utile, mais laisse la mesure opérationnelle aux fabricants.
- CVSS mesure la gravité intrinsèque sur une échelle de 0 à 10 : caractéristiques de la vulnérabilité indépendantes de toute exploitation observée dans la nature.
- EPSS mesure la probabilité d'exploitation sur une échelle de 0 à 1 : probabilité d'une exploitation observée dans les 30 prochains jours, calculée par le groupe de travail EPSS SIG du FIRST.
- CISA KEV est un signal binaire d'exploitation active qui peut éclairer les décisions de signalement, même si le déclencheur CRA est plus large que la seule inclusion dans KEV.
- CVSS, EPSS et KEV combinés donnent une matrice de priorisation défendable ; aucun signal seul n'est suffisant.
- Les déclencheurs de signalement sont factuels, non pilotés par les scores. L'exploitation active et les incidents graves sont déterminés au regard des définitions légales, les scores servant de preuves à l'appui.
Les quatre signaux qui encadrent les décisions de gravité CRA : gravité intrinsèque, probabilité d'exploitation, horloge de signalement et la date à laquelle l'obligation de signalement s'applique.
Ce que dit le CRA sur la notation
Lisez le règlement directement et vous ne trouverez aucune mention de CVSS, EPSS ou de tout autre système de notation nommé. Les obligations opérationnelles sont plus simples : le fabricant doit disposer d'un processus de gestion des vulnérabilités efficace pendant toute la période d'assistance, corriger les vulnérabilités sans retard et publier une information claire sur la gravité lorsqu'un correctif est disponible.
- Remédiation. Traiter et corriger les vulnérabilités sans retard, notamment au moyen de mises à jour de sécurité.
- Information publique. Une fois une mise à jour de sécurité disponible, communiquer une description de la vulnérabilité corrigée, les produits concernés, l'impact probable, la gravité et des consignes de remédiation claires.
Ces formules fixent une norme, pas un nombre de jours fixe. Elles sont interprétées par les autorités de surveillance du marché et, en dernier ressort, par les juridictions nationales.
La notation est la manière dont les fabricants démontrent cette interprétation lors des audits et enquêtes. Un fabricant capable de présenter une politique de gravité documentée, un système de suivi qui enregistre CVSS et EPSS à l'entrée, un SLA lié aux niveaux de gravité, et des horodatages de remédiation respectant ces SLA dispose d'une position « sans retard » défendable. Un fabricant qui ne le peut pas n'en dispose pas.
Pour le régime général de gestion des vulnérabilités, voir la gestion des vulnérabilités. Pour les cadences de signalement au titre du régime de notification d'incidents, voir le signalement des vulnérabilités.
CVSS : gravité intrinsèque
Le Common Vulnerability Scoring System, maintenu par le CVSS SIG du FIRST, note une vulnérabilité sur une échelle de 0,0 à 10,0. Il constitue le score de gravité intrinsèque dominant dans le secteur et le score que la plupart des entrées CVE publient.
CVSS v3.1 comporte trois types de scores :
| Type de score | Ce qu'il mesure | Usage CRA |
|---|---|---|
| Score de base | Caractéristiques intrinsèques de la vulnérabilité : vecteur d'attaque, complexité, privilèges requis, interaction utilisateur, portée, et impact sur la confidentialité, l'intégrité et la disponibilité. | À utiliser comme base d'entrée, car c'est le score publié par la plupart des entrées CVE. |
| Score temporel | Contexte public variable dans le temps : maturité du code d'exploitation, niveau de remédiation et confiance dans le signalement. | À utiliser lorsqu'il existe, mais sans en dépendre, car les entrées CVE publiques le renseignent rarement. |
| Score environnemental | Votre contexte produit : criticité des actifs, contrôles compensatoires, chemins de code atteignables et impact réel du déploiement. | À utiliser pour documenter pourquoi le fabricant a relevé, abaissé ou différé une priorité de remédiation. |
CVSS v4.0 a été publié par FIRST le 1er novembre 2023. Il conserve les groupes Base et Environnemental, remplace le groupe Temporel de la v3.1 par un groupe Menace plus ciblé sur la maturité de l'exploitation, et ajoute un groupe Supplémentaire (incluant la sécurité, l'automatisabilité, la récupération et la densité de valeur) qui enregistre le contexte sans modifier le score final. L'adoption est progressive : de nombreux flux CVE publient encore v3.1, et le support des outils pour v4.0 reste inégal. Ingérez les deux lorsqu'ils sont disponibles et ne traitez pas la transition comme une remise à zéro du carnet de dette.
CVSS seul est insuffisant. Les travaux empiriques montrent de manière constante que la plupart des vulnérabilités notées « élevé » ou « critique » par CVSS ne sont jamais observées comme exploitées. Une file pilotée uniquement par CVSS consomme de la capacité d'ingénierie sur des risques théoriques pendant que de vraies exploitations passent inaperçues.
EPSS : probabilité d'exploitation
L'Exploit Prediction Scoring System, également maintenu par FIRST via son EPSS SIG, prédit la probabilité qu'une activité d'exploitation contre un CVE soit observée dans les 30 prochains jours. EPSS publie une probabilité entre 0 et 1 et un rang percentile par rapport à l'ensemble des CVE.
EPSS est calculé par un modèle d'apprentissage automatique qui ingère les attributs CVE (métriques CVSS, CWE, fournisseur et produit concerné, ancienneté) et des signaux publics (disponibilité de PoC, activité d'exploitation observée auprès des partenaires contributeurs, mentions dans les renseignements sur les menaces). Les scores sont actualisés quotidiennement. Un nouveau CVE sans PoC public score généralement en dessous de 0,05 ; un CVE avec un PoC armé peut augmenter sensiblement, selon les autres données d'entrée du modèle.
EPSS seul est également insuffisant. Un faible score EPSS aujourd'hui n'est pas une garantie pour demain : lorsqu'un chercheur publie un exploit fonctionnel, le score bouge. EPSS doit être réévalué en continu, pas seulement à l'entrée.
CISA KEV : exploitation confirmée
Le catalogue Known Exploited Vulnerabilities, maintenu par la US Cybersecurity and Infrastructure Security Agency, est une liste de vulnérabilités avec des preuves fiables d'exploitation active (vulnérabilités connues comme exploitées). Un CVE figure dans le catalogue ou il n'y figure pas. CISA ajoute un CVE lorsqu'elle dispose de preuves fiables que la vulnérabilité a été exploitée contre une cible réelle.
KEV est une source gouvernementale américaine. Les fabricants européens l'utilisent largement en raison de son large support outillage. Depuis le 13 mai 2025, l'ENISA opère également la Base de données européenne des vulnérabilités (EUVD), qui publie le statut d'exploitation et une vue dédiée aux vulnérabilités exploitées ; traitez-la comme un signal de priorisation européen complémentaire à KEV. Les deux sont distincts de la plateforme unique de signalement CRA (Article 16), et aucun des deux ne constitue en lui-même le déclencheur de signalement de l'Article 14.
Pour le déclencheur d'alerte précoce, l'inclusion dans KEV est un signal fort qu'une vulnérabilité peut être « activement exploitée » au sens du règlement. Ce n'est pas le seul signal : le déclencheur est plus large et couvre toute vulnérabilité activement exploitée, y compris celles détectées via des signalements clients, la télémétrie interne ou des renseignements sur les menaces qui n'ont pas encore atteint la CISA. Une vulnérabilité exploitée contre vos clients mais pas encore dans KEV peut tout de même déclencher l'obligation. La détermination est factuelle, non fondée sur des listes, et exige des preuves fiables d'une exploitation sans permission.
Combiner CVSS, EPSS et KEV dans une matrice de priorisation CRA
Aucun signal seul n'est suffisant. L'approche défendable consiste à combiner les trois et à lier les SLA de remédiation au niveau combiné. Le diagramme ci-dessous montre pourquoi : un CVSS 9,8 sans exploitation observée représente un risque réel moindre qu'un CVSS 7 avec EPSS 0,95 et une inscription dans KEV, même si le premier semble pire dans une file pilotée par CVSS seul.
| Niveau | Combinaison de signaux | SLA de remédiation | Implication CRA |
|---|---|---|---|
| Urgence | Inscrit KEV OU exploitation active confirmée OU (CVSS Critique 9,0+ ET EPSS > 0,5) | Jours, pas semaines | Revue urgente de signalement si l'exploitation peut viser votre produit |
| Élevé | CVSS Élevé (7,0-8,9) OU EPSS > 0,5 | 30 jours | La position « sans retard » est fragilisée au-delà de 30 jours |
| Moyen | CVSS Moyen (4,0-6,9), EPSS < 0,5, non inscrit dans KEV | 90 jours | Défendable avec documentation et horodatages |
| Faible | CVSS Faible (< 4,0) | Prochain cycle de mise à jour régulier | Documenter le report dans le registre de gestion des vulnérabilités |
La matrice est la politique du fabricant, non une exigence du CRA. La coucher par écrit donne à une autorité de surveillance du marché une base documentée et reproductible pour les décisions de remédiation qu'elle peut scrutiner après qu'une vulnérabilité grave devient publique. Une politique documentée qui classe chaque CVE à l'entrée, enregistre le niveau attribué à ce CVE, et montre qu'il a été traité dans les délais du SLA correspondant avec horodatages est bien plus facile à défendre que « nous avons corrigé quand nous avons pu ».
Notre analyse : une file pilotée uniquement par CVSS devient le signal d'alerte en audit
Les sections ci-dessus couvrent la mécanique opérationnelle. L'encadré ci-dessous reflète notre lecture en tant que praticiens, pas un conseil juridique.
Le règlement actuel ne cite aucun système de notation, et nous ne pensons pas qu'il le fera. Mais la direction est claire. Maintenant que l'EUVD de l'ENISA publie une vue des vulnérabilités exploitées aux côtés de CISA KEV, les preuves d'exploitation sont de plus en plus difficiles à ignorer pour les autorités : « nous avons priorisé par CVSS et manqué celle qui était exploitée » est une réponse qui se fragilise chaque trimestre. Nous nous attendons à ce que les autorités de surveillance du marché et les CSIRT lisent un processus tenant compte d'EPSS et de KEV comme le plancher d'un régime de gestion des vulnérabilités compétent, pas une option avancée. Construisez pour l'état d'application qui arrive, et vous noterez pour la probabilité d'exploitation, pas seulement pour la gravité.
Cartographie de la gravité sur les déclencheurs de signalement
Le signalement n'est pas piloté par les scores. Le régime de notification d'incidents se divise en deux flux avec les mêmes horloges de 24 heures et 72 heures, mais des délais de rapport final différents :
- Vulnérabilité activement exploitée. Alerte précoce de 24 heures, notification de vulnérabilité de 72 heures, rapport final de 14 jours à compter de la disponibilité d'une mesure corrective ou d'atténuation.
- Incident grave. Alerte précoce de 24 heures, notification d'incident de 72 heures, rapport final d'un mois à compter de la notification de 72 heures.
Aucun déclencheur n'est un seuil CVSS. « Activement exploité » est une détermination factuelle : il existe des preuves fiables qu'un acteur malveillant a exploité la vulnérabilité sans permission. Un incident grave est un incident susceptible de nuire à la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions importantes, ou susceptible de conduire à l'exécution de code malveillant dans le produit ou dans les réseaux et systèmes d'information d'un utilisateur.
CVSS et EPSS appuient la détermination. Une vulnérabilité critique CVSS avec EPSS > 0,9 et inscription KEV doit déclencher une revue urgente de signalement dès que vous disposez de preuves que l'exploitation peut viser votre produit. Ils ne remplacent pas la détermination. L'horloge de 24 heures se déclenche au moment où le fabricant prend conscience de l'exploitation active, non au moment où le score CVSS dépasse un quelconque seuil.
Pour la cadence complète de signalement, voir le signalement des vulnérabilités. Pour le canal d'entrée amont qui produit souvent le premier signal d'exploitation, voir la divulgation coordonnée des vulnérabilités.
Opérationnaliser la notation dans votre processus de gestion des vulnérabilités
Un processus de notation aligné sur le CRA comporte six composantes concrètes :
- Ingérer CVSS au moment du scan. Votre pipeline SBOM-vers-CVE doit attacher les scores de base CVSS à chaque constat dès la première détection. Voir le guide SBOM pour les mécanismes de cartographie sous-jacents.
- Actualiser EPSS quotidiennement. Une tâche nocturne qui recalcule les vulnérabilités ouvertes constitue le minimum.
- Surveiller CISA KEV. Abonnez-vous au flux KEV et remontez automatiquement toute vulnérabilité ouverte qui entre dans le catalogue.
- Définir des SLA par niveau dans votre système de suivi. Les niveaux et délais doivent être lisibles par machine afin que les éléments en retard remontent sans triage humain.
- Déclencher une escalade lors des franchissements de seuil. Lorsqu'EPSS dépasse 0,5 pour un constat ouvert, reclassez-le (Élevé, ou Urgence si CVSS est également à 9,0+). Lorsque KEV ajoute l'un de vos CVE, ou qu'un client signale une exploitation active, l'élément passe automatiquement en niveau Urgence.
- Automatiser la cartographie SBOM-composant-vers-CVE. La cartographie manuelle ne tient pas à l'échelle et constitue la source la plus courante de vulnérabilités manquées lors des audits.
L'intégration à la plateforme unique de signalement de l'ENISA est un chantier distinct mais connexe. Voir l'intégration à la SRP ENISA.
Erreurs courantes
- Chasser les CVSS-9 en ignorant les EPSS-0,95. Une vulnérabilité CVSS-7 avec EPSS 0,95 et un PoC public représente un risque réel plus élevé qu'un CVSS-9,8 avec EPSS 0,01.
- Supposer que KEV est exhaustif. KEV est le meilleur catalogue public, mais il est en retard. Une exploitation active contre vos clients peut précéder l'inscription KEV de plusieurs jours ou semaines.
- Traiter CVSS comme une échéance. Un CVSS Critique ne signifie pas « corriger en 24 heures ». Il signifie « regarder en premier ». L'échéance vient de votre SLA de politique, de l'EPSS, du statut KEV et, en dernier ressort, de la norme attendue de remédiation sans retard.
- Omettre d'actualiser les scores EPSS. Une vulnérabilité notée EPSS 0,02 à l'entrée et jamais recalculée stagnera dans votre file de faible priorité pendant que de vraies exploitations se développent en dehors de votre champ de vision.
- Ignorer les modificateurs environnementaux CVSS. Un score de base CVSS de 9,8 contre un composant que votre produit n'instancie jamais n'est pas un 9,8 dans votre environnement. Documentez le score environnemental et le raisonnement.
- Utiliser CVSS ou EPSS comme déclencheur de signalement. L'obligation de signalement repose sur une exploitation active factuelle. Un score est une preuve à l'appui, non la détermination.
Foire aux questions
Le CRA nous impose-t-il d'utiliser CVSS ?
Non. Le CRA ne cite ni CVSS ni aucun autre système de notation. L'obligation de divulgation impose de communiquer la « gravité » lors de la publication d'une vulnérabilité corrigée, mais ne précise pas l'échelle. CVSS est la valeur par défaut du secteur et l'échelle la plus facile à défendre en audit. Une échelle personnalisée ou alternative peut fonctionner si elle est documentée et appliquée de manière cohérente.
EPSS est-il obligatoire au titre du CRA ?
Non. EPSS n'est pas mentionné dans le règlement. Il aide à démontrer la norme « sans retard » car il montre que la priorisation a suivi la probabilité d'exploitation réelle, et pas seulement la gravité intrinsèque. Un fabricant qui ignore la probabilité d'exploitation et corrige uniquement par rang CVSS aura du mal à justifier une remédiation lente d'un constat EPSS élevé après coup.
Comment la notation affecte-t-elle l'horloge de 24 heures ?
Elle ne change pas le moment où l'horloge démarre. L'horloge démarre lorsque le fabricant prend conscience d'une vulnérabilité activement exploitée, quelle que soit la valeur CVSS. La notation aide à trier quels signaux entrants atteignent le seuil de prise de conscience, mais une fois l'exploitation établie de manière crédible, l'horloge tourne même si le score CVSS n'est pas encore finalisé.
Pouvons-nous utiliser un système de notation personnalisé ?
Oui, à condition de pouvoir le défendre en audit. Un schéma combinant le contexte du modèle de menace interne avec des signaux externes est acceptable s'il est documenté, appliqué de manière cohérente, et produit des résultats de remédiation alignés sur la norme « sans retard ». La valeur par défaut du secteur, CVSS plus EPSS plus KEV, est la voie de moindre résistance car elle est largement reconnue.
Le CRA sanctionne-t-il un score de gravité erroné ?
Pas directement. Le risque de sanction tient au non-respect des exigences de gestion des vulnérabilités ou au défaut de signalement d'une exploitation active. Un score individuel erroné ne constitue pas automatiquement une violation, mais un processus de notation absent ou incohérent peut devenir une preuve que la gestion des vulnérabilités n'était pas efficace.
Faut-il utiliser CVSS v3.1 ou v4.0 ?
Les deux, lorsqu'ils sont disponibles. CVSS v4.0 a été publié par FIRST le 1er novembre 2023. Il conserve Base et Environnemental, remplace le groupe Temporel par un groupe Menace plus ciblé sur la maturité de l'exploitation, et ajoute un groupe Supplémentaire (incluant la sécurité, l'automatisabilité, la récupération et la densité de valeur) qui enregistre le contexte sans modifier le score. L'adoption est progressive : de nombreux flux CVE publics publient encore v3.1. Ingérez les deux signaux lorsque la source les fournit, et ne traitez pas la transition de v3.1 à v4.0 comme une remise à zéro du carnet de dette.
À partir de quand ces obligations de signalement s'appliquent-elles ?
L'Article 14, qui contient les obligations de signalement décrites sur cette page, s'applique à partir du 11 septembre 2026. Les obligations de gestion des vulnérabilités, de remédiation et de divulgation du CRA prévues à l'Article 13 et à l'Annexe I s'appliquent à partir du 11 décembre 2027, date à laquelle l'essentiel du règlement entre en vigueur. Mettez en place le processus de notation et de préparation au signalement maintenant, afin qu'il soit opérationnel avant septembre 2026.
Qu'est-ce qui constitue le « moment où l'on prend connaissance » pour l'horloge de 24 heures ?
L'horloge d'alerte précoce de 24 heures démarre lorsque le fabricant prend connaissance d'une vulnérabilité activement exploitée. Cela signifie une connaissance crédible qu'un acteur malveillant a exploité la faille contre une cible réelle, pas un signalement de vulnérabilité privé ou une preuve de concept fonctionnelle à elle seule. Un score CVSS ou EPSS ne déclenche pas l'horloge ; c'est la détermination factuelle de l'exploitation active qui le fait.
Comment utiliser l'EUVD de l'ENISA aux côtés de CISA KEV ?
Depuis le 13 mai 2025, l'ENISA opère la Base de données européenne des vulnérabilités (EUVD), qui publie le statut d'exploitation et une vue dédiée aux vulnérabilités exploitées. Utilisez-la comme signal de priorisation aux côtés de CISA KEV. Aucun de ces catalogues n'est le déclencheur de signalement de l'Article 14, et les deux sont distincts de la plateforme unique de signalement CRA prévue à l'Article 16.
VEX modifie-t-il la gravité CRA ou le signalement ?
Non. Un document VEX (Vulnerability Exploitability eXchange) ne modifie pas le déclencheur de signalement ni la gravité intrinsèque d'une vulnérabilité. C'est une façon lisible par machine d'enregistrer si votre produit est réellement affecté par une vulnérabilité connue (affecté, non affecté, en cours d'investigation ou corrigé) aux côtés de votre SBOM. Cela en fait une preuve à l'appui solide pour un abaissement de score environnemental ou un report documenté.
Faut-il utiliser SSVC plutôt qu'une matrice CVSS ?
C'est possible. SSVC (Stakeholder-Specific Vulnerability Categorization), publié par la CISA avec le SEI de Carnegie Mellon, est une alternative sous forme d'arbre de décision qui aboutit à une décision de remédiation (Track, Track*, Attend, Act) à partir de données d'entrée telles que le statut d'exploitation, l'exposition et l'impact sur la mission. Le CRA ne l'exige pas. C'est un cadre reconnu et défendable si vous préférez un arbre de décision à la matrice CVSS + EPSS + KEV de cette page.