Vulnérabilités : de la CVE à l'application métier

Jeudi matin, le flux annonce trente nouvelles failles critiques. Le RSSI demande lesquelles nous concernent. L’équipe infrastructure ouvre un tableur, cherche les produits, les versions, les serveurs, se connecte à droite et à gauche pour vérifier. Le lendemain, personne n’est encore sûr d’avoir eu des informations complètes.

Le problème, c’est le chemin à parcourir entre une faille publiée et l’application métier qu’elle menace. Voici la méthode pour suivre cette trace, et comment KANAP la fait tenir dans un seul écran.

Quatre maillons pour répondre

Une faille vise un produit et des versions. Pour savoir si elle vous concerne, il faut relier quatre maillons :

1. La technologie : SQL Server, Tomcat, vCenter, ce que vos applications utilisent pour fonctionner.
2. Sa version : SQL Server 2019 n’a pas les mêmes failles que SQL Server 2022.
3. Le serveur qui l’héberge.
4. L’application métier qui en dépend, avec sa criticité et son responsable.

Dans KANAP, tous ces maillons existent : les applications et leurs serveurs dans la cartographie, les technologies et leurs versions entre les deux.

Deux sources officielles combinées

Toutes les 6 heures, KANAP lit la NVD, la base américaine des vulnérabilités, et compare chaque faille à vos technologies, version par version. La NVD est la référence, mais elle a un défaut : elle rattache les failles aux produits avec retard, et parfois jamais.

Un exemple sur une technologie que tout le monde utilise. En 2026, la fondation Apache a publié 60 failles d’Apache Tomcat. Le 23 octobre, la NVD en avait rattaché 40 au produit. Les 20 autres, publiées le 23 septembre et le 20 octobre, dont 6 critiques et 7 élevées, n’avaient encore aucun produit dans la NVD.

KANAP lit donc une deuxième source : les fiches que les éditeurs publient eux-mêmes sur CVE.org, avec leurs produits et leurs versions. Une ligne existe dès que l’une des deux sources rapproche la faille de votre technologie. Quand la NVD n’a pas encore noté une faille, KANAP affiche le score de l’éditeur.

Chaque ligne dit quelle source l’a trouvée : la NVD, l’éditeur, ou les deux. « Pourquoi cette ligne » donne le critère en clair, par exemple « Apache Tomcat : versions 9.0.0 à 9.0.98 concernées ». Et la page indique quand chaque source a été lue pour la dernière fois, avec un avertissement si une lecture a échoué.

Priorité aux vulnérabilités exploitées

Le score CVSS dit la gravité théorique d’une faille, pas le risque réel qu’elle fait courir. Une faille notée 9,8 que personne n’exploite pèse moins qu’une faille notée 7,5 activement utilisée. KANAP croise donc trois signaux d’exploitation :

• Les catalogues de failles exploitées de la CISA, l’agence américaine, et de l’Union européenne. Une faille qu’ils listent porte une icône d’alerte, dont l’infobulle nomme les catalogues et l’usage par des rançongiciels quand la CISA l’a constaté.
• L’EPSS, la probabilité qu’une faille soit exploitée dans les 30 jours, calculée chaque jour par le FIRST.
• La base européenne des vulnérabilités de l’ENISA, celle à laquelle NIS2 se réfère : chaque faille y renvoie quand elle y figure.

La liste s’ouvre sur les failles exploitées, puis sur les plus sévères. Le filtre « Exploitées seulement » ne garde qu’elles : c’est la vue la plus importante.

L’analyse d’impact

La même faille n’a pas le même poids sur le portail client que sur un serveur de test. C’est là que KANAP se distingue d’une simple liste de CVE : chaque ligne dit combien de serveurs et d’applications elle atteint, et les filtres permettent de partir d’un serveur ou d’une application pour voir ses failles.

Sur la fiche d’une application, la section Vulnérabilités résume ses failles technologie par technologie, avec le nombre de critiques, d’élevées et de moyennes. Un badge dans l’en-tête signale les failles graves. Le responsable de l’application voit son exposition sans ouvrir la page des vulnérabilités.

Sur le tableau de bord, la tuile « Vulnérabilités du parc » pose les questions dans l’ordre d’un DSI : combien d’applications de la criticité la plus haute ont une faille critique ou élevée, combien de failles critiques ont été publiées ces 7 et 30 derniers jours, combien sont exploitées, combien de serveurs ont une faille grave. Chaque ligne ouvre la liste correspondante. La criticité vient de la classification de vos applications, présentée dans l’article Classer ses applications.

Vous choisissez ce qui déclenche une alerte

Toutes les technologies ne méritent pas la même vigilance. Sur chaque technologie, un interrupteur l’inclut dans les alertes ou l’en sort, et chaque version peut avoir le sien.

Deux familles commencent sans alertes par défaut ; libre à vous de les activer. Les systèmes d’exploitation, d’abord : KANAP ne connaît pas le niveau de correctifs d’un serveur, et un système complet remonterait des centaines de failles déjà corrigées. Les services en ligne, ensuite : le fournisseur corrige lui-même un service qu’il fait tourner. Si vous voulez suivre une version précise, par exemple celle de vos serveurs les plus exposés, il suffit d’activer son interrupteur.

Rien n’est caché pour autant. Une version hors des alertes reste rapprochée des failles et visible sous le filtre « Alertes » : elle est seulement mise de côté dans les comptes, les tuiles et les e-mails.

Tracer le traitement des alertes

Une faille n’est jamais « vue » : elle est traitée, écartée avec une raison, ou encore à traiter. Chaque ligne porte l’un de ces trois états (à traiter, traitée, non concernée) et une note : « corrigé le 12 mars, changement CHG-123 ». Le journal d’audit garde qui a changé quel état, et quand.

Le traitement en masse évite le travail ligne à ligne. Par exemple, pour écarter les failles de PostgreSQL sur des installations dont la version n’est pas renseignée : un filtre sur la technologie et la version, une case à cocher, l’état « non concernée » et la raison dans la note. Avant de confirmer, KANAP dit combien de lignes et de failles le changement touche.

Le reste suit naturellement. L’export CSV reprend les filtres affichés, pour le comité sécurité ou l’auditeur. Les responsables IT d’une technologie reçoivent un e-mail pour ses nouvelles failles critiques, élevées ou exploitées, une seule fois par faille. Et Plaid, l’assistant intégré à KANAP, répond aux questions sur les vulnérabilités, dans la limite des droits de chacun.

C’est ce qu’attend un audit NIS2 : non pas une liste de failles, mais la trace de ce que l’équipe en a fait.

KANAP n’est pas un scanner, il le complète

Un scanner de vulnérabilités voit les hôtes, les paquets installés, les correctifs passés. KANAP voit autre chose : les applications métier, leur criticité, leurs responsables et les technologies dont elles dépendent. Il ne dit pas si un correctif est posé sur tel serveur ; il dit quelles applications une faille peut toucher, et qui doit regarder.

Par où commencer

1. Créez vos technologies depuis le catalogue : 192 produits, avec leurs versions, leurs dates de support et leurs identifiants de vulnérabilité sont déjà renseignés et peuvent être utilisés directement.
2. Saisissez les versions sur vos serveurs et vos applications, ou importez les liens par fichier CSV.
3. Nommez les responsables IT de chaque technologie : ce sont eux qui recevront les alertes.
4. Ouvrez la page Vulnérabilités sur « Exploitées seulement ».

Si vous hébergez KANAP, activez d’abord les vulnérabilités et posez une clé NVD, comme l’explique le guide de configuration.

Pour voir tout cela en live, un essai gratuit de 14 jours de notre version hébergée donne accès aux données d’exemple du groupe fictif Fromage & Co, chargées en une minute. KANAP est entièrement open source : il s’installe aussi gratuitement sur vos propres serveurs.