Prioriser les vulnérabilités : un pipeline KEV, EPSS et CVSS v4

Un scanner peut produire des milliers de lignes. La question opérationnelle est plus courte : que faut-il corriger en premier, sur quel actif et avec quel délai ? KEV, EPSS et CVSS apportent des informations complémentaires. Un pipeline utile les rapproche de votre inventaire et conserve la raison de chaque décision, au lieu de produire un score opaque.

1. Attribuer un rôle à chaque source

Le catalogue KEV de CISA recense des vulnérabilités connues comme exploitées. C’est un signal de priorité utile ; l’obligation et les échéances destinées à certaines agences américaines ne deviennent pas automatiquement votre calendrier contractuel.

Selon FIRST, EPSS estime la probabilité qu’une CVE soit exploitée dans la nature dans les 30 prochains jours. Un score de 0,02 correspond à 2 %, pas à son rang dans la population. Un percentile de 0,95 signifie un classement relatif élevé ; il ne signifie pas 95 % de probabilité. Cette estimation ne porte pas directement sur votre machine.

La spécification CVSS v4.0 décrit des métriques de base, de menace, d’environnement et complémentaires. Conservez le vecteur et la version du score. Une note de base élevée attire l’attention, mais ne vous dit pas si le composant est présent, exposé et utilisé dans une fonction essentielle.

2. Préparer les données et leur traçabilité

Pour chaque ligne, conservez l’identifiant d’actif, le propriétaire, le produit, la version observée, la source du constat et la date. Ajoutez les données externes avec leur date de collecte. Ne fusionnez pas aveuglément deux logiciels qui portent un nom proche ; les correspondances de versions et de paquets doivent être vérifiées.

Le pipeline doit tolérer les erreurs d’API, les limites de débit, les doublons et les changements de format. Gardez le dernier jeu valide avec son âge, déclenchez une alerte de fraîcheur et marquez les champs manquants. EPSS absent n’équivaut pas à EPSS égal à zéro.

3. Une logique de décision explicable

Le pseudo-code suivant illustre une politique proposée. Ce n’est pas une norme CISA ou FIRST et il ne fixe pas de seuil universel. Les délais doivent être choisis avec les responsables métiers et opérationnels. Une mesure compensatoire réduit éventuellement une exposition ; elle doit être testée et réexaminée.

SI exploitation observée chez nous :
    déclencher la réponse à incident
SINON SI applicabilité inconnue :
    ouvrir une qualification avec une échéance
SINON SI vulnérabilité non applicable, preuve disponible :
    documenter la conclusion et sa date de révision
SINON SI KEV et actif exposé ou essentiel :
    traiter en priorité urgente
SINON :
    examiner EPSS, CVSS, exposition, impact et dépendances
    attribuer priorité, responsable, délai et justification

N’additionnez pas mécaniquement une probabilité, une note de sévérité et un indicateur binaire. Leur sens n’est pas le même. Si vous utilisez un score interne, documentez ses règles et vérifiez qu’il ne dépriorise pas une exploitation observée simplement parce que le modèle EPSS reste bas.

4. Trois exemples fictifs de tri

Ces exemples n’utilisent pas de numéros de CVE réels pour éviter de donner une priorité actuelle sans inventaire. Une même vulnérabilité peut conduire à deux décisions différentes sur deux actifs. Un service interne peut aussi être accessible après compromission d’un poste ; « non exposé à Internet » ne signifie pas « sans risque ».

5. Fermer la boucle de remédiation

Le ticket doit contenir le changement attendu, le responsable, les dépendances, la date visée et la preuve de clôture. Après correction, contrôlez la version réellement exécutée, le redémarrage éventuel et le fonctionnement métier. Un scan relancé aide à confirmer le résultat, mais une disparition du scanner peut aussi venir d’une perte d’accès à l’actif.

Une exception doit avoir un propriétaire, une justification, une mesure compensatoire vérifiée et une date de réexamen. Suivez l’âge des vulnérabilités applicables prioritaires et le nombre d’actifs sans propriétaire. Une baisse du total brut de lignes ne suffit pas à mesurer une baisse du risque.

6. Recette avant automatisation

• Créer un jeu fictif avec KEV présent, EPSS absent, percentile élevé et probabilité faible.
• Ajouter des doublons, une version ambiguë, un actif disparu et une source périmée.
• Vérifier qu’une exploitation locale entraîne toujours une prise en charge incident.
• Rejouer deux fois le même jeu et obtenir les mêmes décisions explicables.
• Simuler une panne de source : conserver la dernière donnée datée et signaler la dégradation.
• Faire valider les décisions par un responsable opérationnel avant de créer automatiquement des tickets.

Commencez en lecture seule, sans correction automatique. Pour revenir en arrière, désactivez la création de tickets et reprenez la dernière règle approuvée sans perdre l’historique. Ce guide décrit une architecture et une recette à implémenter ; il ne prétend pas fournir un connecteur universel déjà testé sur vos outils.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• CISA - Known Exploited Vulnerabilities Catalog
• FIRST - EPSS FAQ
• FIRST - Données EPSS et API
• FIRST - Spécification CVSS v4.0