Prioriser une CVE avec le contexte de l’actif.

Méthode pas à pas

Un chemin reproductible, de la question à la conclusion.

1. 1

   Associer la CVE à un actif

   Relevez produit, version, composant, propriétaire et rôle métier. Vérifiez l’avis de l’éditeur et les conditions d’exploitation. Une bannière publique ancienne ne prouve pas la présence actuelle de la version vulnérable.

2. 2

   Lire la gravité avec son vecteur

   Conservez la version CVSS, le vecteur, la source du score et les conditions comme les privilèges ou l’interaction nécessaires. Un nombre sans son contexte est insuffisant pour comparer deux cas.

3. 3

   Examiner les signaux d’exploitation

   Consultez KEV pour l’exploitation connue et EPSS pour une estimation sur trente jours. Notez leur date. Un percentile EPSS est un rang, différent de la probabilité.

4. 4

   Évaluer l’exposition et les conséquences

   Vérifiez avec l’équipe autorisée si le composant est accessible, si les conditions existent et quelles données ou activités seraient touchées. Le contrôle défensif ne nécessite pas de tester une exploitation sur une cible publique.

5. 5

   Choisir et vérifier la mesure

   Appliquez le correctif ou une mesure provisoire recommandée par l’éditeur, selon la procédure de changement. Conservez validation, tests de fonctionnement, responsable et date de revue des mesures temporaires.

CVSS, KEV et EPSS : trois questions différentes

CVSS décrit la gravité technique. KEV répertorie des vulnérabilités dont l’exploitation réelle est connue. EPSS estime une probabilité d’exploitation sur les trente prochains jours. Aucun de ces éléments ne décrit à lui seul les conséquences pour votre actif.

Un EPSS faible ne neutralise pas une exploitation connue. Une CVE absente de KEV peut malgré tout être exploitée. Les échéances du catalogue CISA répondent à un cadre fédéral américain ; votre organisation doit définir ses délais selon son contexte et ses obligations.

Documenter un actif concerné ou non concerné

Le dossier doit permettre de retrouver l’inventaire utilisé, la version effectivement installée et le paragraphe de l’avis justifiant l’applicabilité. Une hypothèse fondée uniquement sur un résultat de moteur reste à confirmer.

Si la version est inconnue ou si la condition d’exploitation ne peut pas être contrôlée, gardez le statut « à vérifier ». Pour conclure non applicable, notez la raison et la source technique plutôt que de fermer l’alerte sans trace.

Une décision expliquée vaut mieux qu’un score composite

Examinez séparément exploitation, accessibilité du composant, contrôles existants et conséquences métier. Une application exposée qui traite des données sensibles peut appeler une action différente d’un composant isolé, même avec le même score de gravité.

Documentez le choix : correction planifiée, confinement provisoire, examen d’incident ou non-applicabilité démontrée. Une mesure compensatoire doit avoir un propriétaire, une limite d’efficacité et une échéance de réexamen.

Vérifier après le changement

Contrôlez la version corrigée, le composant réellement chargé et la disponibilité du service. Un ticket fermé ou un paquet téléchargé ne démontre pas que tous les actifs concernés ont été mis à jour.

Si des signes de compromission existent, la correction seule ne clôt pas l’incident. Préservez les journaux disponibles et déclenchez la procédure de réponse avec l’équipe compétente.

Erreurs fréquentes

Quatre raccourcis qui fragilisent le résultat.