Prioriser les vulnérabilités : classer par exploitabilité, pas par CVSS
Trier au seul CVSS fait remonter le mauvais travail en premier. Classez le backlog de remédiation par exploitation avérée, usage par les ransomwares, accessibilité réelle de la machine et impact métier.
La priorisation des vulnérabilités sert à une seule chose : décider ce que l'équipe traite lundi matin. La réponse habituelle — on trie par CVSS et on déroule la liste en partant des critiques — fait remonter le mauvais travail, parce que le score décrit la faille et pas votre parc. Posez plutôt quatre questions, dans cet ordre. Cette faille est-elle activement exploitée en ce moment ? Sert-elle à des opérations de ransomware ? La machine concernée est-elle réellement joignable ? Et qu'est-ce qui tourne dessus ? La gravité départage les ex aequo, elle n'est pas le critère de tri.
Ce n'est pas un ajustement de scoring. C'est ce qui sépare un backlog de remédiation que l'équipe infra traite de celui qu'elle finit par ne plus ouvrir.
Pourquoi prioriser les vulnérabilités au seul CVSS donne le mauvais ordre
Le CVSS mesure bien la gravité et priorise mal. Le FIRST, qui publie la norme, l'écrit dans la spécification elle-même : le score de base décrit des caractéristiques intrinsèques, stables dans le temps et d'un environnement à l'autre, et il est censé être pondéré par les métriques temporelles et environnementales avant que quiconque agisse dessus. Presque personne ne le pondère. Ce qui arrive dans la file, c'est le score de base brut, appliqué à l'identique à une machine exposée sur internet et à une VM qui n'a jamais quitté un lab.
Deux conséquences en découlent, connues l'une comme l'autre.
D'abord, la bande « critique » ne trie plus rien. Quand une grande partie du registre tombe dans la même fourchette étroite, « traiter les critiques d'abord » n'est pas un ordre de traitement : c'est un tas, et l'ordre à l'intérieur dépend de celui qui a trié le tableur.
Ensuite, le registre perd sa crédibilité auprès de ceux qui doivent agir. Un admin système à qui l'on demande trois fois une fenêtre de maintenance en urgence pour une faille qui se révèle injoignable traitera la quatrième demande comme du bruit. Relever le seuil ne ramène pas cette confiance.
Les quatre questions qui ordonnent réellement la file
On répond à chacune à partir de données que vous détenez déjà ou que vous pouvez obtenir gratuitement, et chacune fait passer des constats devant un score brut.
| Question | D'où vient la réponse | Pourquoi elle prime sur le score |
|---|---|---|
| Est-elle exploitée en ce moment ? | Le catalogue Known Exploited Vulnerabilities de la CISA, qui recense les failles pour lesquelles l'exploitation active est avérée | Quelqu'un a déjà fait le plus dur. Une exploitation constatée l'emporte sur une difficulté théorique. |
| Sert-elle aux ransomwares ? | Le même catalogue porte un champ qui signale les failles utilisées dans des campagnes de ransomware | Le pire scénario passe d'une fuite de données à un arrêt de tout le parc, et ce n'est plus la même personne qui signe le changement. |
| Est-elle joignable ? | Votre inventaire d'actifs : exposition, position réseau, et le fait que le service vulnérable écoute vraiment | Une faille injoignable suppose d'abord un pied dans le réseau. C'est un autre événement, pas celui-ci. |
| Qu'est-ce qui tourne sur la machine ? | Le responsable de l'actif, et l'impact métier d'une indisponibilité | À score égal, un contrôleur de domaine et un serveur d'impression ne posent pas le même problème. |
Les deux premières disent si l'extérieur a rendu la chose urgente, les deux dernières, si c'est votre parc. Il faut les deux moitiés pour qu'un constat passe en tête : tout le modèle tient là.
Un score élevé sur une machine que personne ne peut atteindre n'est pas votre urgence
Prenez une faille, un score, deux hôtes. Sur le reverse proxy en frontal de votre trafic public, le service vulnérable écoute, le catalogue la donne pour exploitée, et l'exploit sert à des opérateurs de ransomware. Sur la VM de lab, derrière deux firewalls et sans route entrante, la même faille porte le même score et n'est atteignable que par quelqu'un qui a déjà un pied dans le réseau.
Une file triée par score met ces deux-là côte à côte. Une file triée par exploitabilité traite la première aujourd'hui et met la seconde au planning. La gravité n'a pas bougé. L'urgence n'a jamais été dans la gravité.
Le classement se justifie aussi dans l'autre sens. Une faille au score moyen, sur une machine exposée sur internet et signalée comme activement exploitée, passe devant la moitié de votre bande critique. Rien, dans une liste triée par CVSS, ne la fera jamais remonter.
Un classement ne vaut rien si le constat n'est pas qualifié et la couverture pas affichée
Deux conditions avant qu'un ordre de traitement veuille dire quelque chose.
Le constat doit être réel. Deux scanners qui remontent la même faiblesse sur le même hôte, c'est une corroboration, pas un doublon à supprimer. L'accord entre un scanner à agent et un scanner sans agent reste le signal le plus solide qu'on obtienne à peu de frais pour établir qu'un constat n'est pas un faux positif produit par la manière dont un seul outil regarde. Seculogik recoupe d'abord et classe ensuite, parce que discuter du rang d'un constat qui n'existe peut-être pas est la réunion la plus chère qui soit.
La couverture doit être affichée. « Aucune critique » sur dix hôtes parmi quatre cents n'est pas une bonne nouvelle, et rien ne doit lui permettre d'y ressembler. Chaque vue du registre indique quelle part du parc a été examinée avant d'annoncer le moindre chiffre. C'est la règle que le reste de la plateforme s'applique à elle-même — un zéro doit être explicable, parce qu'un dashboard propre mais aveugle est pire que pas de dashboard du tout.
Deux horloges : une remédiation se compte en jours, un incident en minutes
L'erreur la plus fréquente, après celle du classement, consiste à faire passer les vulnérabilités par la file des incidents. Elles n'ont pas la même forme.
Un incident se compte en minutes jusqu'à la prise en compte. Il appartient au SOC, un analyste N1 en fait le premier tri sur une seule vacation, et il se termine par un verdict.
Une remédiation se compte en jours jusqu'au correctif. Elle est portée pendant des semaines par quelqu'un hors du SOC, elle demande une fenêtre de maintenance, et elle se termine par un correctif, une acceptation formelle ou le silence.
Reprenez les échéances d'incident pour les vulnérabilités et chaque constat est en dépassement dès sa création, ce qui apprend à tout le monde à ignorer le compteur. Dans Seculogik, les deux tournent donc sur des horloges distinctes, reliées en lecture seule dans les deux sens : l'analyste qui traite un dossier voit les vulnérabilités connues sur cet hôte, et l'admin système voit le dossier. Ni l'un ni l'autre ne modifie ce que voit l'autre, et une faiblesse présente pendant un incident n'est jamais prise pour la preuve qu'elle a servi de porte d'entrée.
Un risque accepté qui n'expire jamais n'est pas une décision
Tôt ou tard, la réponse est « nous ne corrigerons pas ». C'est une issue légitime, et c'est celle que la plupart des registres gèrent le plus mal, parce que l'acceptation y est définitive. La mesure compensatoire est démontée, un exploit fonctionnel est publié, le contexte métier change — et l'acceptation tient toujours, parce que rien ne repose la question.
Ici, chaque acceptation de risque porte une date d'expiration. À l'échéance, l'élément repasse en revue avec son motif d'origine. Rien ne réécrit automatiquement la décision humaine : la trace de qui a formellement accepté le risque, quand et pourquoi, est exactement ce que l'on veut garder.
Où cela se situe dans le produit
Le Vulnerability Operations Centre est inclus dans l'édition Client. Ce n'est pas l'un des six modules et il ne se facture pas en plus — la distinction compte, parce qu'un acheteur ne devrait jamais découvrir une capacité pour la première fois sur un devis. Seul le rapport de posture destiné au comité relève du module SOC Reporting, et le module Threat Intelligence approfondit le contexte d'exploitation. Le registre fonctionne sans l'un ni l'autre.
Il lit les scanners que vous exploitez déjà — à agent, sans agent, ou les constats déjà présents dans l'index que vous opérez, Elastic, OpenSearch, Splunk ou Wazuh — et si le vôtre n'est pas couvert, nous construisons le connecteur. Le tout sur une seule machine, on-prem, sans compteur au gigaoctet et sans que rien ne sorte de chez vous.
Nos propres engagements figurent sur la page sécurité et confiance, y compris ce que nous n'avons pas : aucun rapport de test d'intrusion tiers, aucune certification, aucun SLA. Nous sommes en pré-GA, sans aucun client à citer.
Un registre classé par exposition, recoupé entre plusieurs sources, avec un responsable nommé et une échéance sur chaque ligne, et des acceptations de risque qui expirent. Celui-là, les équipes continuent de l'ouvrir.
Si votre file de vulnérabilités est aujourd'hui triée par score, voyez ce que le Vulnerability Operations Centre en fait, regardez quelle édition l'inclut et ce qu'ajoute chacun des six modules — puis apportez un export de vos constats actuels à une démo : nous vous montrerons dans quel ordre ils ressortent.