---
title: "Suivi des CVE — Méthodologie et priorisation"
domain: veille
subdomain: cve
type: note
tags: [veille, cve, cvss, epss, patch-management]
difficulty: intermediate
status: stable
updated: "2026-08-02"
---
## 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.</Danger>

## Les trois signaux à croiser

| Signal | Ce qu'il mesure | Où le trouver |
|---|---|---|
| **CVSS** | Sévérité technique intrinsèque (impact + complexité d'exploitation) | [NVD](https://nvd.nist.gov/), voir [Scoring CVSS](/security/pentest/06-reporting/03-cvss-scoring) |
| **EPSS** | Probabilité d'exploitation réelle dans les 30 jours (modèle statistique) | [first.org/epss](https://www.first.org/epss/) |
| **KEV** | Exploitation **confirmée et active** en conditions réelles | [Catalogue CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) |

### Règle de priorisation simple

1. **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.
2. **CVSS ≥ 9 et EPSS élevé (>10%)** → priorité haute, fenêtre de patch courte (24-72h selon la PSSI).
3. **CVSS élevé mais EPSS faible et absente de KEV** → planifier normalement, pas d'urgence de rupture de service pour patcher en catastrophe.
4. **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.</Tip>

## Voir aussi

- [Scoring CVSS — comprendre les métriques](/security/pentest/06-reporting/03-cvss-scoring)
- [Sources de veille cybersécurité](/veille/actualites/sources-veille-cybersecurite)