TechWatchAlert
Page pilier · Veille CVE

La veille CVE qui passe à l’action.

Surveiller les CVE ne suffit pas. Ce qui compte, c’est de savoir lesquelles vous concernent, dans quel ordre les traiter, et ce qui se passe après l’alerte.

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 chez nous suit aussitôt la lecture, sans traitement par lot. 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.

19 sources, recoupées

Aucune source n’est complète à elle seule. Depuis février 2024, l’enrichissement des CVE par le NVD avait fortement ralenti ; depuis avril 2026, le NIST n’enrichit plus la plupart des CVE, qui restent sans score ni référence de produit. Nous recoupons 19 sources, dont neuf flux de vulnérabilités : liste CVE, NVD, catalogue KEV, scores EPSS, preuves de concept publiées, avis GitHub, OSV, publications du CERT-FR et base européenne EUVD, 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à Tenable, Qualys, Action1, Intruder, Cyberwatch, OpenCVE ou CVEDetails. TechWatchAlert applique cette méthode jusqu’au correctif et à la preuve NIS2, en sept langues, hébergé en France, avec un plan gratuit et un outil sans compte pour la mettre à l’épreuve sur votre propre périmètre.

Questions fréquentes

Qu’est-ce que la veille CVE ?

La surveillance continue des vulnérabilités publiques qui touchent les logiciels et équipements que vous exploitez, pour les corriger avant qu’elles ne soient exploitées. Ce qui la distingue d’une simple lecture de flux, c’est le filtrage sur un périmètre déclaré.

Comment automatiser sa veille CVE ?

Déclarez votre stack (éditeurs, produits, versions), puis laissez l’outil filtrer le flux, prioriser par le KEV et l’EPSS et notifier sur votre canal. L’automatisation utile ne porte pas sur la collecte, qui est facile, mais sur le tri, qui est le vrai travail.

La veille CVE est-elle gratuite ?

Le plan gratuit de TechWatchAlert couvre jusqu’à 50 composants et 5 machines, sans carte bancaire. D’autres outils ont aussi des formules gratuites. Ce qui n’est jamais gratuit, c’est le temps passé à trier quand personne ne filtre à votre place.

Veille CVE ou scanner de vulnérabilités ?

Un scanner découvre ce qui tourne sur vos machines, via un agent ou un accès réseau. La veille part de votre inventaire (déclaré, importé ou remonté par un agent) et vous alerte sur les CVE correspondantes. Les deux se complètent : TechWatchAlert lit aussi les résultats de votre scanner par son API.

Combien de temps pour mettre en place une veille ?

Compter deux minutes pour déclarer une dizaine de composants, et une semaine d’observation pour régler le seuil de bruit. Le réglage du seuil compte davantage que la mise en place.

Commencer

La prochaine faille critique sort demain matin

Sachez avant midi si elle vous concerne, et qui s'en occupe.

Parler à l'équipe

Offre Free sans carte bancaire · hébergé en France

Créer un compte gratuit