veillecvecvss
MDstable
NoteSnippetChecklistPlaybook
Suivi des CVE — Méthodologie et priorisation
Comment suivre les nouvelles vulnérabilités, les prioriser (CVSS + EPSS + KEV) et documenter les entrées critiques
noteintermediate 2026-08-02 3 min read
veillecvecvssepsspatch-management
Objectif
Toutes les CVE ne se valent pas — en publier des centaines chaque semaine, il est impossible de tout traiter. Cette note décrit une méthode de tri pour ne remonter que ce qui mérite une action, et le format à utiliser pour archiver une entrée dans veille/cve/.
🔴 Danger — Le score CVSS seul ne suffit pas pour prioriser un patch. Une CVE critique (CVSS 9.8) sans exploit connu est souvent moins urgente qu'une CVE modérée (CVSS 6.5) déjà exploitée activement sur Internet.
Les trois signaux à croiser
| Signal | Ce qu'il mesure | Où le trouver |
|---|---|---|
| CVSS | Sévérité technique intrinsèque (impact + complexité d'exploitation) | NVD, voir Scoring CVSS |
| EPSS | Probabilité d'exploitation réelle dans les 30 jours (modèle statistique) | first.org/epss |
| KEV | Exploitation confirmée et active en conditions réelles | Catalogue CISA KEV |
Règle de priorisation simple
- CVE dans le catalogue KEV → patch immédiat, quel que soit le score CVSS. C'est le signal le plus fiable : ce n'est plus une hypothèse, elle est exploitée.
- CVSS ≥ 9 et EPSS élevé (>10%) → priorité haute, fenêtre de patch courte (24-72h selon la PSSI).
- CVSS élevé mais EPSS faible et absente de KEV → planifier normalement, pas d'urgence de rupture de service pour patcher en catastrophe.
- Vulnérabilité sur un composant hors périmètre (pas déployé, pas exposé) → noter pour référence, pas d'action.
Ce qui déclenche une entrée dans cette section
Toute CVE ne mérite pas une note ici — l'idée n'est pas de dupliquer la NVD. Créer une entrée quand :
- elle touche une technologie effectivement utilisée dans l'environnement (cf. les notes SysAdmin/Network/DevOps de ce site) ;
- et elle est soit dans le catalogue KEV, soit CVSS ≥ 8 avec un exploit public.
Format d'une entrée CVE
markdown
## CVE-YYYY-NNNNN — [Nom du produit affecté]- **CVSS** : X.X (vecteur : AV:N/AC:L/...)- **KEV** : Oui/Non (date d'ajout si oui)- **Composant** : [produit + versions affectées]- **Impact** : [RCE / élévation de privilèges / déni de service / fuite de données...]- **Correctif** : [version corrigée, date de disponibilité]- **Contournement temporaire** : [si patch pas encore appliqué]- **Source** : [lien NVD / avis éditeur]
💡 Tip — Dater systématiquement l'entrée et noter si le correctif a été appliqué en interne — cette note sert aussi de traçabilité pour un audit ultérieur.
Voir aussi
OPS·BRAIN v1.03 notes · Veillelocal