Triage des CVE
Un scanner vous remet quatre cents identifiants CVE et une colonne de gravité qui qualifie la plupart de critiques. Ce bureau classe la liste selon ce qui est réellement exploité : le catalogue KEV de la CISA pour l’exploitation connue, les scores EPSS de FIRST pour la probabilité d’exploitation et CVSS pour l’impact — chaque donnée imprimée à côté de la priorité qu’elle a produite, pour que l’ordre soit auditable et non un nombre magique.
Aucun identifiant CVE trouvé dans la saisie pour le moment.
Vous traitez une file de correctifs chaque semaine ? Surveillez vos sites gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Comment fonctionne le classement
Chaque identifiant est recherché dans trois sources et reçoit une bande de priorité selon la première règle qu’il satisfait. P1, c’est l’appartenance au catalogue des vulnérabilités exploitées connues (KEV) de la CISA : ce ne sont pas des prédictions — la CISA n’inscrit un CVE qu’avec des preuves d’exploitation active —, donc une entrée KEV prime sur tout, et le tableau affiche sa date d’échéance de correction et si la CISA signale un usage connu de rançongiciel. P2, c’est un score EPSS de 0,10 ou plus : EPSS, maintenu par FIRST, modélise la probabilité qu’un CVE soit exploité dans les 30 prochains jours, et 0,10 est élevé — la grande majorité des CVE notés se situent sous 0,01, c’est pourquoi la colonne de percentile est aussi affichée, pour garder le score brut honnête. P3, c’est un score de base CVSS de 7,0 ou plus (Élevé ou Critique) sans signal d’exploitation : grave s’il est utilisé, sans usage connu. P4, c’est tout le reste qui a des données. Dans une bande, les lignes se trient par EPSS, puis par CVSS — et chaque en-tête de colonne retrie le tableau, car votre file peut légitimement différer de l’ordre par défaut. Ce que la bande ne fait jamais, c’est cacher ses données : si vous contestez la priorité d’une ligne, les chiffres dont elle vient sont sur la même ligne.
D’où viennent les données, et leur fraîcheur
Le catalogue KEV et les scores EPSS sont mis en cache chaque jour sur le serveur de sysosx — les deux éditeurs publient un fichier de masse par jour, donc le bureau télécharge ces fichiers une fois par jour et votre recherche lit les copies locales. L’en-tête du résultat indique la date propre à chaque flux (la date de publication du catalogue, la date de notation EPSS) et quand il a été récupéré, pour que vous sachiez toujours quel jour de données a classé votre liste. CVSS est l’exception : ni KEV ni EPSS ne le portent, donc les scores viennent de la NVD — récupérés une fois, la première fois qu’un CVE est recherché, et mis en cache de façon permanente sur le serveur, car un score CVSS publié ne change pas. Un collage très frais peut donc afficher quelques scores comme en attente : cela signifie que le cache n’a pas encore atteint ces identifiants, pas qu’ils n’ont pas de score — relancez la liste peu après et ils se rempliront. Les recherches fraîches sont limitées par visiteur comme les autres vérifications côté serveur, et répéter le même collage est servi depuis un cache court. Sous le capot, la page appelle GET /api/check/cve-triage sur le serveur de sysosx avec les identifiants extraits.
Ce que ce bureau ne peut pas vous dire
Trois limites honnêtes. D’abord, « Absent des données en cache d’aujourd’hui » est une absence dans trois jeux de données, pas un verdict : il n’est pas exploité connu, il n’a pas de score EPSS, et la NVD n’a pas d’enregistrement — il peut toujours être nouveau, contesté ou noté sous un autre identifiant, et il mérite un examen manuel plutôt qu’un haussement d’épaules. Ensuite, les données d’exploitation concernent le CVE dans le monde, pas votre actif : un P4 sur un serveur exposé à internet peut primer sur un P1 sur une machine de test isolée, et vous seul savez lequel est lequel — triez d’abord le lot exposé à internet, ce qui explique aussi pourquoi le bureau prend 200 identifiants à la fois plutôt que de prétendre qu’un classement convient à tout un parc. Enfin, l’inscription au KEV suit l’exploitation avec retard et EPSS est un modèle, pas un oracle ; les deux sont des preuves bien meilleures que la gravité seule, et aucun ne remplace la lecture de l’avis du fournisseur pour les P1. Le raisonnement derrière le classement — et un exemple traité — se trouve dans trier les CVE par exploitation, pas seulement par gravité.
Outils liés : le scanner de ports pour savoir quels services un hôte expose réellement (la moitié actif de chaque décision CVE), le bilan de santé du site pour le certificat, l’expiration et les enregistrements du même hôte, et le noteur SSL quand le constat est une configuration TLS plutôt qu’un CVE.
Questions fréquentes
D’où viennent les données, et quelle est leur fraîcheur ?
Trois sources publiques, chacune étiquetée avec sa date dans le résultat. Le catalogue des vulnérabilités exploitées connues de la CISA et les scores EPSS quotidiens de FIRST sont téléchargés sur le serveur de sysosx une fois par jour et y sont mis en cache — votre recherche lit la copie locale, elle n’interroge ni la CISA ni FIRST en direct. Les scores CVSS viennent de la NVD : la première recherche d’un CVE le récupère une fois et le met en cache de façon permanente, car un score CVSS publié ne change pas. Si un score indique « en attente », le cache n’a pas encore atteint ce CVE — relancez la liste dans une minute et il se remplira.
Un CVE de mon scanner est absent ou affiche « absent des données en cache d’aujourd’hui ». Est-il sûr ?
Aucune conclusion de ce genre n’est disponible, et la page ne fera pas semblant du contraire. « Introuvable » signifie seulement que l’identifiant n’apparaît dans aucune des sources en cache d’aujourd’hui — il n’est pas dans le catalogue KEV, il n’a pas de score EPSS dans le fichier actuel, et la NVD n’a pas d’enregistrement CVSS pour lui. De nouveaux CVE apparaissent chaque jour, EPSS ne note que les CVE qu’il a modélisés, et un CVE peut être réel, grave et simplement trop récent pour chacune des trois. Traitez les lignes absentes comme « à trier à la main », pas comme « à ignorer ».
Pourquoi un CVSS 9,8 est-il classé sous un CVSS 7,5 ?
Parce que le classement se fait par exploitation, pas par impact. Le 7,5 est dans le catalogue KEV : on sait que des attaquants l’utilisent, donc c’est un P1. Le 9,8 a un score EPSS élevé ou aucun — grave s’il est exploité, mais sans preuve que quelqu’un l’exploite déjà. La gravité vous dit à quel point une brèche serait grave ; KEV et EPSS vous disent quelle est la probabilité d’une tentative. L’ordre de correction doit suivre d’abord la probabilité et utiliser la gravité comme départage, ce que codent les bandes P1–P4. L’article lié ci-dessous développe le raisonnement en entier.
Que signifient exactement les bandes de priorité ?
P1 : le CVE est dans le catalogue KEV de la CISA — exploité connu, corrigez maintenant, et notez la colonne de date d’échéance KEV. P2 : pas dans KEV, mais son score EPSS est de 0,10 ou plus — une probabilité modélisée de 10 % ou plus d’exploitation dans les 30 prochains jours, un air très raréfié (bien moins de 1 % des CVE notés). P3 : ni l’un ni l’autre, mais un score de base CVSS de 7,0 ou plus (Élevé ou Critique). P4 : il a des données mais n’atteint aucun des seuils — planifiez-le normalement. Chaque donnée derrière la bande est imprimée dans sa propre colonne ; la bande est un ordre de tri, pas un score à accepter sur parole.
Puis-je trier plus de 200 CVE ?
Le bureau accepte 200 identifiants par recherche — collez la liste en deux lots. Ce plafond empêche une requête de monopoliser le vérificateur, et en pratique un export de scanner est de toute façon plus utile divisé par groupe d’actifs : triez d’abord le lot exposé à internet, car le même CVE est une urgence différente sur un serveur public et sur un poste de travail isolé.