La veille CVE qui passe à l’action.

Mis à jour le 16 septembre 2026

Une CVE (Common Vulnerabilities and Exposures) est l’identifiant public d’une vulnérabilité. Plus de 40 000 ont été publiées en 2024 et la courbe n’a pas fléchi depuis 2016 (chiffres du programme CVE). Une équipe qui en exploite une trentaine de composants en verra passer quelques dizaines qui la concernent vraiment sur l’année. Tout le problème tient dans ce rapport.

Le coût réel du bruit

Lire chaque CVE publiée représenterait plus de deux heures par jour ouvré, pour un taux de pertinence inférieur à un pour cent. Personne ne tient ce rythme. Ce qui se passe en pratique est pire que l’abandon : l’équipe lit pendant deux semaines, puis survole, puis filtre par « critique », puis n’ouvre plus. Le jour où une faille la concerne réellement, la notification arrive dans un canal que plus personne ne regarde.

Le décrochage est donc le vrai risque, pas le volume. Un dispositif de veille se juge sur une seule question : sera-t-il encore lu dans six mois ?

Construire un périmètre, et le tenir

Un périmètre de veille, c’est la liste de ce que vous exploitez, avec les versions. Trois façons de la constituer : la saisir à la main, importer un SBOM (Software Bill of Materials, la nomenclature produite par votre chaîne de construction logicielle), ou laisser détecter les technologies d’une URL publique. Comptez deux minutes pour une dizaine de composants.

La difficulté n’est pas de le créer, c’est de le tenir. Une version montée, une bibliothèque ajoutée, un serveur repris à un client : chaque changement non reporté est un angle mort. L’import de SBOM à chaque livraison est le seul mécanisme qui résiste au temps, parce qu’il ne dépend pas de la mémoire de quelqu’un.

Trois signaux pour prioriser, et quand chacun se trompe

Une fois la liste réduite, il reste à choisir l’ordre. Trois référentiels publics y répondent, et il faut les lire dans cet ordre précis.

Le KEV d’abord : le catalogue des vulnérabilités activement exploitées, publié par l’agence américaine de cybersécurité. Ce n’est pas une prévision, c’est un constat : la liste des incendies déjà déclarés. Une CVE présente au KEV et présente chez vous se traite sans discussion. Sa limite : il ne recense que ce qui a été observé et signalé, donc il arrive parfois après l’exploitation. Comment se lit le catalogue KEV.

L’EPSS ensuite : une probabilité d’exploitation observée dans les trente jours, recalculée chaque matin. C’est la météo : on ne discute pas avec une probabilité de pluie, on prend un parapluie. Sa limite : elle décrit le monde, pas vous. Une faille à forte probabilité sur un service que vous n’exposez pas ne vous concerne guère. Ce que l’EPSS prédit, et ce qu’il ne prédit pas.

Le CVSS en dernier : la gravité intrinsèque, de 0 à 10. C’est la magnitude d’un séisme : la puissance du phénomène, indépendamment du fait qu’il y ait une ville au-dessus. Sa limite est la plus importante à connaître : la majorité des CVE notées critiques ne sont jamais exploitées. Comment se lit un vecteur CVSS, et le calculateur pour en composer un.

Règle utilisable telle quelle : ce qui est au KEV et présent chez vous se traite sous 48 heures ; ensuite ce qui dépasse 0,1 d’EPSS ; le CVSS ne sert qu’à départager deux candidats à égalité.

Ce qui se passe après l’alerte

Une alerte qui n’aboutit à rien est un coût sans contrepartie. Le trajet complet compte quatre états : reçue, analysée, en cours de correction, résolue. Chaque alerte a un responsable nommé ; le passage d’un état à l’autre laisse une trace datée, qui sert autant à l’équipe qu’à un auditeur six mois plus tard.

Deux délais à ne pas confondre, parce qu’on les mélange partout. La synchronisation : à quelle fréquence les flux sont relus. Le traitement : le temps entre la lecture d’une CVE et la notification, qui tient sous 30 secondes chez nous. Aucun outil ne peut être plus rapide que sa fréquence de synchronisation, et tout éditeur qui n’annonce qu’un seul chiffre en cache un autre.

La fin de support, l’angle mort

Une version en fin de vie ne recevra plus jamais de correctif. Ce n’est pas une vulnérabilité de plus : c’est la garantie que toutes les suivantes resteront ouvertes. Une veille sérieuse suit donc les dates de fin de support autant que les CVE, avec un préavis suffisant pour planifier une migration, pas pour la découvrir le jour même.

Sept flux, recoupés

Aucune source n’est complète à elle seule. Depuis février 2024, l’enrichissement des CVE par le NVD a fortement ralenti : quantité de vulnérabilités sont restées des mois sans score ni référence de produit. Nous recoupons sept flux : liste CVE, NVD, catalogue KEV, scores EPSS, preuves de concept publiées, avis GitHub et OSV, pour rester utilisable quand l’un d’eux prend du retard. Le détail des sources et de leurs licences.

Et concrètement, lundi matin

Quatre gestes, dans cet ordre, pour une équipe qui part de rien.

1. Déclarez vingt composants, versions comprises. Pas cent : ceux qui sont exposés sur Internet et ceux qui portent des données.
2. Réglez le seuil. Tout ce qui est au KEV, quel que soit le score, plus ce qui dépasse 7 en CVSS. Vous passez ainsi de plusieurs milliers de CVE par mois à quelques alertes.
3. Séparez les canaux. Le critique sur Slack ou Teams, le reste dans un résumé quotidien. Tout envoyer sur Slack revient à couper Slack.
4. Relisez le volume au bout d’une semaine. Plus de dix alertes ? Remontez le seuil. Zéro ? Votre périmètre est probablement incomplet.

Quel outil pour tenir tout cela

La méthode ci-dessus ne dépend d’aucun produit. Pour choisir celui qui la porte, deux pages : le classement des six outils de veille CVE en 2026 si vous partez de zéro, et les comparatifs face à face si vous utilisez déjà OpenCVE, Cyberwatch ou CVEDetails. TechWatchAlert applique cette méthode, en français, hébergé en France, avec un plan gratuit pour la mettre à l’épreuve sur votre propre périmètre.