Le rapport arrive par mail, en PDF, quarante pages. La synthèse annonce 47 vulnérabilités : 3 critiques, 11 élevées, 22 moyennes, 11 faibles. Chacune porte un score sur 10 et un paragraphe technique. Le prestataire a fait son travail.
Reste la question que le rapport ne tranche jamais : par laquelle commencer ?
Personne ne corrige 47 vulnérabilités. Il y a une équipe de deux personnes, des projets déjà engagés, des correctifs qui demandent une fenêtre d'interruption négociée trois semaines à l'avance. La vraie décision n'est pas est-ce qu'on corrige, c'est dans quel ordre, et qu'est-ce qu'on assume de laisser.
Ce qui suit ne suppose ni SOC, ni outil de gestion de vulnérabilités, ni équipe sécurité dédiée. Juste une liste de constats et quelqu'un qui doit décider.
D'où viennent ces listes
Le rapport de pentest est le cas le plus visible, mais ce n'est qu'une des sources. Elles ont chacune leur rythme et leur biais.
Le test d'intrusion produit une photographie à un instant T, sur un périmètre négocié. Ses constats sont vérifiés : quelqu'un les a réellement exploités. C'est la source la plus fiable, et la moins fréquente — une fois par an dans le meilleur des cas.
Le scan de vulnérabilités tourne en continu et remonte beaucoup plus de volume. Il détecte des versions logicielles vulnérables sans vérifier qu'elles sont exploitables chez vous. Un scanner qui annonce 400 failles n'affirme pas que vous avez 400 problèmes.
La veille CVE et les bulletins éditeurs vous préviennent qu'une faille vient d'être publiée sur un produit que vous utilisez. C'est la source la plus urgente et la plus mal exploitée : elle arrive par mail, au milieu du reste, sans indiquer si vous êtes concerné.
Ces trois flux alimentent la même pile. Et sur cette pile, tout le monde applique par défaut le même réflexe : trier par score CVSS décroissant. C'est là que le problème commence.
Le CVSS mesure la gravité, pas l'urgence
Le Common Vulnerability Scoring System attribue à chaque faille une note de 0 à 10, à partir de critères techniques : difficulté d'exploitation, privilèges nécessaires, impact sur la confidentialité, l'intégrité et la disponibilité.
Ce score répond à une question précise : si cette vulnérabilité est exploitée, à quel point est-ce grave ?
Il ne répond pas à celle qui décide de l'ordre : quelle est la probabilité qu'elle le soit, chez moi, dans les semaines qui viennent ?
La différence n'est pas théorique. Une faille notée 9.8 sur un composant que vous n'exposez pas sur Internet, qu'aucun code d'exploitation public ne cible et que personne n'a jamais attaquée peut légitimement attendre. Une faille notée 6.5 activement exploitée en ce moment sur un service exposé passe devant. Trier par CVSS décroissant place pourtant systématiquement la première en haut de la liste.
C'est un problème connu, et le CVSS lui-même prévoit des correctifs — les métriques environnementales, censées pondérer par votre contexte. Presque personne ne les renseigne : cela demande de documenter la criticité de chaque actif, un travail que les organisations sans équipe sécurité dédiée ne font pas. En pratique, le score utilisé est le score brut, publié par l'éditeur, identique pour toutes les entreprises du monde.
(Sur le fonctionnement du score et ce que la version 4.0 a changé, nous détaillons le sujet dans CVSS 4.0 : ce que le score de vulnérabilité mesure vraiment.)
Ce que l'autorité américaine vient d'acter
Ce n'est plus seulement un débat d'experts. Le 10 juin 2026, l'agence américaine de cybersécurité a publié la directive BOD 26-04, « Prioritizing Security Updates Based on Risk », qui révoque et remplace deux directives antérieures.
Le changement tient en une phrase : le score CVSS n'est plus le critère qui fixe les délais de correction. Il est remplacé par un modèle à quatre variables, évaluées pour chaque vulnérabilité en fonction de l'actif qu'elle menace :
- L'exposition publique — l'actif est-il joignable depuis Internet ?
- Le statut KEV — l'exploitation de cette faille est-elle confirmée dans la vraie vie ?
- L'automatisation de l'exploitation — un attaquant peut-il l'exploiter à la chaîne, sans intervention manuelle ?
- L'impact technique — donne-t-elle le contrôle total du système, ou partiel ?
Ces quatre variables déterminent un délai : trois jours pour les combinaisons les plus graves, quatorze jours pour un régime accéléré, soixante jours pour les cas moins risqués, et « à la prochaine mise à niveau » lorsqu'aucun critère de risque n'est atteint.
Deux précisions importantes. Cette directive est contraignante pour les agences fédérales américaines uniquement — vous n'y êtes pas soumis, et l'agence encourage simplement le secteur privé à s'en inspirer. Et elle ne dit pas que le CVSS est inutile : elle dit qu'il ne suffit pas, seul, à décider d'un calendrier.
Ce qui la rend intéressante pour une entreprise française, ce n'est pas la contrainte. C'est qu'une administration qui gère des dizaines de milliers de systèmes a formalisé, après des années, exactement l'arbitrage que fait un responsable informatique de PME devant son rapport de 47 lignes. La méthode qui suit en est directement inspirée.
Les trois signaux qui manquent au score
Le CVSS vous donne la gravité. Trois autres sources, toutes gratuites et publiques, vous donnent le reste.
L'exposition, c'est vous qui la connaissez. Aucun outil ne peut vous dire si le serveur concerné est publié sur Internet ou enfermé dans un réseau interne segmenté. C'est la variable la plus déterminante du modèle, et c'est la seule que vous êtes seul à pouvoir renseigner. Elle ne demande aucun abonnement : elle demande de savoir ce que vous exposez — ce qui, en soi, est souvent le premier chantier.
Le catalogue KEV liste ce qui est réellement attaqué. Le Known Exploited Vulnerabilities Catalog recense les vulnérabilités dont l'exploitation est confirmée par des observations de terrain. Il est binaire : une faille y figure ou non. Si l'une des vôtres y est, le débat sur l'ordre est terminé — elle passe en tête, quel que soit son score. Le catalogue reste publié et à jour ; c'est la directive qui l'encadrait qui a été remplacée.
L'EPSS estime la probabilité d'exploitation. L'Exploit Prediction Scoring System est un modèle statistique qui produit, pour chaque CVE publiée, une probabilité d'être exploitée dans les trente jours à venir. Là où le CVSS dit « ce serait grave », l'EPSS dit « c'est probable » — ou l'inverse. Une faille à 9.8 de CVSS avec un EPSS à 0,1 % est un mauvais candidat à l'urgence.
Sa limite mérite d'être dite : une probabilité n'est pas une prédiction, et le modèle ne connaît rien de votre infrastructure. Il vous classe le monde, pas votre parc. Il remplace un tri à l'aveugle, pas votre jugement.
La méthode : quatre questions, dans cet ordre
L'ordre compte autant que les questions. Le CVSS n'arrive qu'en dernier.
1. Est-ce exposé ? Séparez la liste en deux : ce qui est joignable depuis Internet, et le reste. Sur un rapport typique, cette seule question écarte la moitié des lignes du champ de l'urgence. Elle ne les annule pas — elle les sort de la file prioritaire.
2. Est-ce activement exploité ? Passez les CVE restantes dans le catalogue KEV. Celles qui y figurent constituent votre liste courte, et elle est généralement très courte : deux ou trois lignes sur quarante-sept. C'est votre semaine.
3. Est-ce probable et automatisable ? Pour celles qui ne sont pas au KEV, l'EPSS départage. Une probabilité élevée sur un service exposé signale une faille que les attaquants scannent en masse. C'est le deuxième cercle, celui du mois qui vient.
4. Qu'est-ce que ça atteint chez nous ? À ce stade seulement, regardez la gravité — et pas seulement le chiffre. Une faille qui donne le contrôle total d'un serveur portant votre base clients n'a pas le même poids qu'une divulgation d'information sur un poste isolé, à score CVSS égal.
L'agence américaine formalise la sortie de cet arbitrage en quatre décisions, via une méthode appelée SSVC : Track (ne rien faire, surveiller), Track* (surveiller de près), Attend (traiter au niveau de l'encadrement), Act (remonter à la direction). Un calculateur public permet de dérouler l'arbre de décision. Vous n'êtes pas obligé d'adopter ce vocabulaire — mais l'idée qu'une vulnérabilité puisse légitimement sortir avec la décision « on surveille, on ne corrige pas maintenant » est celle qui manque le plus souvent dans les organisations qui subissent leurs rapports.
Les 47 constats, reclassés
Voici ce que donne la même liste, triée par CVSS puis par la grille ci-dessus. Les chiffres sont ceux d'un cas réel, anonymisé.
| Tri par CVSS | Tri par risque réel |
|---|---|
| 3 critiques (9.0+) en tête | 2 failles exposées et au catalogue KEV — cette semaine |
| 11 élevées ensuite | 5 exposées, EPSS élevé — ce mois-ci |
| 22 moyennes | 9 exposées, faible probabilité — prochain cycle de patch |
| 11 faibles | 31 non exposées — suivies, corrigées au fil des mises à jour |
Les deux failles en tête du second tableau étaient classées « élevées », pas « critiques ». Deux des trois « critiques » sont dans la dernière ligne : composant interne, non exposé, aucune exploitation connue.
Le rapport n'était pas faux. Il mesurait la gravité, ce qu'on lui demandait. Il ne pouvait pas mesurer votre exposition, parce que personne ne la lui avait décrite.
Ce qu'on assume de ne pas corriger
C'est la partie que les méthodes de priorisation escamotent. Trier, c'est décider que trente et une lignes attendront — et cette décision-là engage.
Trois règles suffisent à ce qu'elle reste défendable.
Elle s'écrit. Une vulnérabilité non corrigée doit apparaître quelque part avec sa justification : non exposée, pas d'exploitation connue, correction planifiée à telle échéance. Un tableur suffit. Ce qui n'est pas écrit n'est pas une décision, c'est un oubli.
Elle se date. Les quatre variables changent. Une faille inoffensive parce que non exposée devient urgente le jour où le service est publié ; une faille ignorée entre au catalogue KEV six mois plus tard. Une décision de report sans date de réexamen est un report définitif.
Elle se signe. Accepter un risque est un acte de direction, pas d'administration système. Si personne n'a validé la liste de ce qu'on ne corrige pas, c'est que la question n'a pas été posée à qui de droit.
Le cas particulier de la faille publiée hier
Le flux de veille ne passe pas par cette grille, parce qu'au moment où la CVE tombe, ni le KEV ni l'EPSS n'ont eu le temps de dire quoi que ce soit.
Deux questions suffisent : est-ce qu'on utilise ce produit, et est-ce qu'il est exposé ? Si les deux réponses sont oui, on applique le correctif sans attendre les scores — c'est exactement la fenêtre pendant laquelle une faille est la plus rentable pour un attaquant et la moins documentée pour vous. Si l'une des deux est non, la CVE rejoint la pile et sera traitée au cycle suivant.
Le préalable est le même que pour tout le reste : savoir ce que vous faites tourner et ce que vous exposez. Sans inventaire, la veille CVE est un bruit de fond qu'on finit par ne plus lire.
Ce qu'il faut retenir
Le score CVSS n'a jamais prétendu ordonner vos corrections — il mesure la gravité d'une faille dans l'absolu, pas son urgence chez vous. L'utiliser comme unique critère de tri revient à laisser un chiffre calculé sans rien savoir de votre entreprise décider de l'emploi du temps de vos équipes.
La correction ne demande ni outil ni budget : l'exposition, vous la connaissez ; le catalogue KEV et l'EPSS sont publics et gratuits. Ce qu'elle demande, c'est un inventaire à jour et quelqu'un qui accepte de signer la liste de ce qu'on ne corrigera pas tout de suite.
C'est aussi ce qui distingue un rapport d'audit utile d'un rapport classé : le premier repart avec un ordre, une échéance et un nom en face de chaque ligne.