Priorisation des vulnérabilités : décider quoi corriger en premier

Pourquoi la sévérité seule ne fonctionne pas

Le réflexe par défaut est de trier par CVSS et de descendre à partir du niveau critique. Cela paraît objectif, et cela échoue pour trois raisons :

• Le CVSS mesure la sévérité, pas le risque. Il décrit la gravité d'une vulnérabilité si elle était exploitée. Il ne dit pas si quelqu'un l'exploite, ni si elle compte dans votre produit.
• Une trop grande partie de la liste est urgente. De nombreuses CVE publiées obtiennent un score élevé ou critique : une file triée par CVSS place donc des centaines de résultats en tête, sans aucun moyen de choisir entre eux.
• La liste ne vaut que ce que vaut l'inventaire. Un scanner qui lit un lockfile signale des dépendances de développement qui ne sont jamais livrées et rate les paquets que le build a téléchargés en dehors du gestionnaire de paquets. Les deux faussent le classement avant même qu'il commence.

La priorisation ajoute les questions manquantes : la vulnérabilité est-elle exploitée, quelle est la probabilité qu'elle le soit, et que vous arrive-t-il si elle l'est ?

Les signaux

Signal	La question à laquelle il répond	Source
CVSS	Quelle est sa sévérité si elle est exploitée ? Score de 0 à 10.	FIRST (la norme) ; la NVD et les éditeurs publient les scores
EPSS	Quelle est la probabilité d'exploitation dans les 30 prochains jours ? Une probabilité de 0 à 1.	FIRST, mis à jour chaque jour, gratuit
CISA KEV	Est-elle déjà exploitée en conditions réelles ?	Le catalogue Known Exploited Vulnerabilities de la CISA
SSVC	Compte tenu de l'exploitation, de l'impact et de votre mission, que devez-vous faire : track, attend ou act ?	Arbres de décision du CERT/CC et de la CISA
Votre contexte	La version vulnérable est-elle livrée ? Est-elle exposée ? Quelle est l'importance du produit ? Existe-t-il un correctif ?	Votre inventaire, votre architecture et vos registres d'actifs

Les signaux publics décrivent la vulnérabilité. Seul votre contexte décrit votre risque, et c'est la partie que la plupart des équipes tirent de la source la moins fiable.

Une méthode de priorisation pratique

La plupart des programmes finissent par adopter une version de ces niveaux. Fixez les délais selon ce que demandent votre politique et vos clients.

1. Corriger maintenant : exploitation connue, dans un logiciel que vous livrez. Tout ce qui figure sur la liste KEV, ou présente d'autres preuves d'exploitation, et qui est présent dans un build publié. À titre de comparaison, la directive BOD 26-04 de la CISA ne donne aux agences fédérales américaines que 3 jours pour une entrée KEV sur un système exposé publiquement.
2. Corriger ensuite : probablement exploitée et sévère. Un score EPSS élevé combiné à un CVSS élevé ou critique, dans un composant livré et exposé. Choisissez un seuil EPSS qui donne une file que votre équipe peut réellement traiter.
3. Corriger en routine : tout le reste de ce qui est livré. Regroupez ces résultats dans des mises à niveau régulières des dépendances au lieu de traiter chacun comme un incident.
4. Documenter : non concerné. Le paquet vulnérable est présent mais le code vulnérable n'est pas utilisé, ou le composant n'est pas livré. Consignez le raisonnement dans une déclaration VEX, pour que le même résultat ne revienne pas en revue et que les clients qui posent la question puissent voir pourquoi.

Puis reclassez en continu. Une vulnérabilité restée au niveau trois peut passer au niveau un du jour au lendemain lorsqu'elle est ajoutée au KEV ou que son score EPSS bondit.

Les vulnérabilités que vous n'avez jamais l'occasion de classer

Toute méthode de priorisation classe les résultats qui se trouvent devant elle. Un paquet vulnérable que le scanner n'a jamais vu ne produit aucun résultat : il n'obtient donc jamais de score CVSS, de score EPSS ni de correspondance KEV. Il n'est pas classé bas. Il n'est pas classé du tout, et il est livré malgré tout.

Cela arrive plus souvent qu'on ne le croit, car la plupart des scanners déterminent le contenu de votre logiciel à partir de fichiers : le lockfile, les manifestes ou la sortie du build. Tout ce que le build récupère et qu'aucun lockfile ne liste est une dépendance cachée, et les outils basés sur les fichiers passent à côté :

• Les hooks d'installation. Le code téléchargé par les scripts npm preinstall et postinstall, la voie empruntée par le ver Shai-Hulud.
• Les scripts de build. Les scripts de build Rust, par exemple, qui téléchargent du code au moment du build.
• Les images de base. L'image de base d'un build de conteneur et ses couches de système d'exploitation.
• Les caches. Les paquets restaurés depuis un cache CI au lieu d'être installés à partir du lockfile.

Scanner la sortie après coup ne comble pas la lacune. Un binaire terminé, surtout du code compilé comme Rust, oblige le scanner à deviner ce qui y est entré. Et comme les builds ne sont pas reproductibles par défaut, reconstruire le même commit plus tard ne garantit pas les mêmes dépendances.

Une SBOM au build part de l'autre bout. CRACI exécute vos jobs GitHub Actions et voit le trafic qui entre dans chaque build : il enregistre donc chaque paquet que le job a réellement récupéré, dépendances cachées comprises. Chaque SBOM comporte un état de complétude qui indique quand quelque chose n'a pas pu être vu. Dans la pratique, CRACI a trouvé des paquets vulnérables que Snyk et Aikido n'avaient pas signalés, parce que leurs scans ne voyaient pas ces composants. Ce sont précisément les résultats qu'une méthode de priorisation n'a jamais l'occasion de classer.

Le contexte : ce que les scanners ne peuvent pas noter pour vous

La version vulnérable est-elle réellement livrée ?

C'est la question qui élimine le plus de bruit. Un framework de test dans un lockfile, un paquet épinglé dans une branche qui n'est jamais publiée, une étape de conteneur jetée : rien de cela n'atteint les clients. Une SBOM enregistrée pendant le build répond à la question à partir de ce que le build de release a réellement utilisé, et non de ce que déclare le dépôt.

Quelles releases la contiennent, et depuis quand ?

Un résultat dans un produit que vous livrez à des clients, avec toutes les releases touchées depuis le printemps dernier, passe avant le même résultat dans un outil interne. Connaître la période d'exposition vous indique aussi ce qu'il faut divulguer.

Le code vulnérable peut-il être atteint ?

L'analyse d'atteignabilité détermine si votre code peut appeler la fonction vulnérable d'une dépendance. Plusieurs outils SCA la proposent, et elle fait efficacement descendre dans la liste les résultats inatteignables. Considérez-la comme une donnée parmi d'autres : elle ne voit que les chemins de code que l'analyse peut suivre, et une fonction atteignable n'est pas la même chose qu'une fonction exploitable.

Est-elle exposée, et existe-t-il un correctif ?

Un service exposé à Internet passe avant un job batch sur un réseau privé. Une vulnérabilité avec une version corrigée est moins coûteuse à fermer qu'une vulnérabilité qui nécessite une atténuation. Les deux changent l'ordre, pas le fait qu'elle soit traitée.

Gestion des vulnérabilités basée sur les risques

La gestion des vulnérabilités basée sur les risques est le nom donné à la même idée à l'échelle d'un programme : classer selon les preuves d'exploitation, la probabilité, la sévérité et le contexte métier, mesurer la vitesse de fermeture des résultats les plus risqués et accepter que les résultats à faible risque puissent rester ouverts. Les indicateurs changent avec elle. Au lieu du nombre total de vulnérabilités ouvertes, suivez combien de vulnérabilités exploitées connues sont ouvertes dans les logiciels livrés, et combien de temps elles le restent.

Les outils de priorisation des vulnérabilités

Trois types d'outils assurent aujourd'hui l'essentiel du classement :

• Les plateformes de gestion des vulnérabilités d'infrastructure telles que Tenable, Qualys et Rapid7 notent les hôtes, les endpoints et les actifs cloud avec leurs propres scores de risque, fondés sur le renseignement sur l'exploitation.
• Les outils SCA et de sécurité applicative tels que Snyk, Endor Labs et Semgrep classent les résultats sur les dépendances, plusieurs d'entre eux avec l'analyse d'atteignabilité.
• Les outils open source tels que Grype, qui indique les données EPSS et KEV avec ses résultats, et Dependency-Track, qui analyse les SBOM en continu.

Le comparatif des outils de gestion des vulnérabilités les passe en revue un par un.

Comment CRACI aide à prioriser

CRACI commence là où le classement dérape le plus souvent : l'inventaire. Il exécute vos jobs GitHub Actions et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches et les dépendances cachées qu'aucun lockfile ne liste.

• Des résultats sur ce qui a été livré. Les SBOM surveillées sont réévaluées en continu, et les vues d'organisation agrègent les résultats de l'ensemble des builds et des dépôts. Chaque paquet affiche ses avis de sécurité avec leur sévérité et les paquets qui l'entraînent.
• La période d'exposition. L'historique des builds montre quels builds passés contenaient une dépendance vulnérable, directe ou transitive : vous savez ainsi quelles releases ont été touchées et pendant combien de temps.
• Tri et routage. Les équipes sécurité trient les résultats et envoient chacun à l'équipe chargée de la correction. CRACI prend en charge VEX pour consigner qu'une vulnérabilité n'affecte pas votre produit.
• Les gates. Les gates de politique peuvent bloquer un build en fonction des résultats, y compris un build qui contient une CVE précise.

CRACI ne propose pas d'analyse d'atteignabilité. Si c'est le signal dont vous avez le plus besoin, choisissez l'un des outils SCA qui la proposent. Voir le suivi des vulnérabilités pour l'ensemble de la fonctionnalité.

Priorisation des vulnérabilités : questions fréquentes

Qu'est-ce que la priorisation des vulnérabilités ?

La priorisation des vulnérabilités consiste à décider quelles vulnérabilités connues corriger d'abord, lesquelles peuvent attendre et lesquelles ne vous concernent pas du tout. Elle classe les résultats selon leur probabilité d'être exploités et les dégâts que cela causerait dans votre environnement, et non selon la seule sévérité.

Comment prioriser les vulnérabilités ?

Partez d'un inventaire exact, afin de classer les vulnérabilités des logiciels réellement livrés. Placez en tête tout ce qui figure sur la liste Known Exploited Vulnerabilities de la CISA, puis classez le reste selon la probabilité d'exploitation (EPSS) et la sévérité (CVSS), ajustées à votre contexte : exposition, importance du produit et existence d'un correctif. Consignez celles qui ne vous concernent pas dans des déclarations VEX.

Le CVSS suffit-il pour prioriser les vulnérabilités ?

Non. Le CVSS mesure la sévérité d'une vulnérabilité, et non sa probabilité d'être exploitée ni son importance pour vous. Classer par CVSS seul marque une grande partie du backlog comme élevée ou critique, et la plupart de ces vulnérabilités ne sont jamais exploitées.

Qu'est-ce que la gestion des vulnérabilités basée sur les risques ?

La gestion des vulnérabilités basée sur les risques classe et corrige les vulnérabilités selon le risque qu'elles représentent pour votre organisation, en combinant preuves d'exploitation, probabilité, sévérité et contexte métier, au lieu de les traiter par score CVSS ou par ancienneté.

Quelle est la différence entre EPSS et KEV ?

EPSS est une prévision : la probabilité estimée qu'une CVE soit exploitée dans les 30 prochains jours. KEV est un registre : le catalogue de la CISA des vulnérabilités dont l'exploitation en conditions réelles est prouvée. Une entrée KEV est un fait ; un score EPSS est une probabilité. Utilisez d'abord KEV, puis EPSS pour classer tout le reste.

L'analyse d'atteignabilité remplace-t-elle la priorisation ?

Non, c'est une donnée de plus. L'atteignabilité vérifie si votre code peut appeler la fonction vulnérable d'une dépendance. Elle élimine les résultats qui ne peuvent pas être déclenchés, mais elle ne dit rien de la probabilité d'exploitation et ne couvre que le code que l'analyse peut suivre.