CVE - Définition, format, processus et limites 2026

Un CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une vulnérabilité de sécurité publiée dans un produit identifié. Pas un score, pas une base de données complète, pas un correctif, juste un ID au format CVE-YYYY-NNNNN qui sert de référence stable entre éditeurs, scanners, équipes et juridictions. Le système est opéré par MITRE depuis 1999, financé par la CISA (Cybersecurity and Infrastructure Security Agency), et repose en 2026 sur un réseau de plus de 400 CNAs (CVE Numbering Authorities) dans 40+ pays. Il publie historiquement entre 25 000 et 30 000 CVE par an depuis 2022, avec un pic à 28 961 CVE publiés en 2023 et un volume similaire en 2024-2025. Comprendre précisément la distinction CVE / NVD / CVSS / EPSS / KEV, le format JSON 5.1, le processus de disclosure et la crise du NVD 2024 est un prérequis pour toute équipe DevSecOps, SOC ou vulnerability management qui ne veut pas piloter dans le brouillard.

Pour le contexte adjacent : voir IOC - Indicateurs de compromission pour la chaîne détection/CTI, et TTP - Tactics, Techniques, Procedures pour le mapping MITRE ATT&CK adversarial.

1. Définition précise et ce qu'un CVE n'est PAS

Un CVE est uniquement trois choses :

1. Un identifiant au format CVE-YYYY-NNNNN (4 chiffres pour l'année, 4 à 7+ chiffres pour le séquentiel depuis le changement de syntaxe en 2014).
2. Une description texte courte de la vulnérabilité (en moyenne 200 à 600 caractères).
3. Une liste de références publiques (advisory vendor, paper, PoC, patch, GHSA équivalent, blog technique).

Un CVE n'est pas :

• Un score de sévérité, c'est CVSS qui le porte, et le score CVSS publié par le CNA peut différer du re-score NVD (cas fréquent en 2024-2025).
• Une classification du défaut, c'est CWE (CWE-79 XSS, CWE-89 SQL injection, CWE-502 Deserialization, etc.).
• Un patch ou un fix, l'attribution d'un CVE est indépendante de l'existence d'un correctif.
• Une preuve d'exploitabilité, un CVE peut exister sans qu'aucune exploitation publique soit observée (c'est CISA KEV qui flagge les vulnérabilités exploitées dans la nature).
• Un catalogue exhaustif, beaucoup de vulnérabilités d'éditeurs hors-CNA ou de produits open-source isolés ne reçoivent jamais de CVE et vivent uniquement dans GHSA, OSV.dev ou les advisories vendor.

2. Format technique et écosystème JSON 5.1

Depuis le CVE Record Format 5.1 (officialisé fin 2023), chaque entrée CVE est un objet JSON normalisé exposé via l'API officielle (cveawg.mitre.org) et téléchargeable en bulk depuis le dépôt GitHub CVEProject/cvelistV5. Le format remplace les anciens flux XML et CSV.

Champs principaux d'un record 5.1 :

Exemple d'extraction CLI rapide via jq (fonctionne sur le bulk download du dépôt cvelistV5) :

# Cloner le bulk
git clone --depth 1 https://github.com/CVEProject/cvelistV5.git
 
# Extraire tous les CVE 2024 avec score CVSS v3.1 >= 9.0 et un CWE assigné
find cvelistV5/cves/2024 -name "CVE-*.json" -exec jq -r '
  select(.containers.cna.metrics[]?.cvssV3_1.baseScore >= 9.0)
  | [
      .cveMetadata.cveId,
      .containers.cna.metrics[0].cvssV3_1.baseScore,
      (.containers.cna.problemTypes[0].descriptions[0].cweId // "n/a"),
      .containers.cna.descriptions[0].value[0:120]
    ] | @tsv
' {} \; 2>/dev/null | sort -k2 -nr | head -50

Cette commande donne en quelques secondes le top 50 des CVE 2024 ≥ 9.0 avec leur CWE et un extrait de description, utile pour un audit ad-hoc, un sourcing de cas d'étude pour formation interne, ou une revue trimestrielle vulnérabilités produit.

3. CNA - le réseau d'attribution distribué

L'attribution n'est pas centralisée : elle est déléguée à des CNAs (CVE Numbering Authorities) à qui MITRE alloue des blocs d'IDs. Au 1er trimestre 2026, on dénombre plus de 400 CNAs dont environ 60 % côté éditeurs logiciels (Microsoft, Google, Apple, Oracle, Cisco, Red Hat, GitHub, GitLab, Atlassian, JetBrains…), 20 % côté CERT nationaux et coordinateurs (CERT/CC, JPCERT/CC, CERT-EU, CERT.PL), 10 % côté plateformes de bug bounty (HackerOne, Bugcrowd, Intigriti), 10 % côté chercheurs et entités diverses.

Hiérarchie typique :

Choix pratique pour un chercheur qui découvre une faille :

1. Vendor est CNA : ouvrir un advisory privé (PSIRT, security@editeur.com), le CNA attribue le CVE et publie. C'est la voie privilégiée.
2. Vendor n'est pas CNA mais un programme bug bounty existe : passer par HackerOne / Bugcrowd qui sont CNA et peuvent attribuer.
3. Aucune des deux : MITRE en CNA-LR via le formulaire cveform.mitre.org. Délai 2 à 30 jours.

4. Le mental model 2026 - CVE, NVD, CISA KEV, EPSS, CVSS

Le piège classique : confondre les couches. Voici le mental model opérationnel à graver, dans l'ordre de la chaîne de valeur :

Position tranchée : en 2026, piloter le vulnerability management uniquement sur le NVD et CVSS est une erreur. Le triplet pertinent en production est CVE × CISA KEV × EPSS. Le NVD reste utile pour la métadonnée (CPE, références) mais n'est plus la source de vérité unique depuis la crise 2024.

5. La crise NVD 2024-2025 - ce que ça change

En février 2024, le NIST a publié un avis indiquant un ralentissement majeur de l'enrichissement du NVD : les nouveaux CVE n'étaient plus systématiquement enrichis avec CPE, CVSS et références additionnelles. Selon les trackers communautaires (vulnchecker, anchore, dépôts GitHub publics qui mesurent le delta), le backlog a dépassé les 17 000 CVE non enrichis fin 2024, et fin 2025 il restait encore plus de 9 000 entrées en attente malgré un partenariat NIST-Analygence et un consortium d'aide externe annoncé en septembre 2024.

Conséquences directes pour les équipes vulnerability management :

• Les scanners SCA qui dépendaient du CPE matching NVD (Trivy, Grype, et plus largement les scanners qui traitaient le NVD comme oracle) ont vu leurs faux négatifs augmenter pendant l'année 2024.
• Les pipelines de gating CVSS-only (ex. « bloquer sur CVSS ≥ 7.0 ») ont commencé à laisser passer des CVE non enrichis (sans CVSS publié côté NVD), donc invisibles à un gate purement seuil-CVSS.
• Le CVSS publié par le CNA dans le record CVE est devenu plus important que le score NVD. Mais beaucoup de CNAs ne publient pas systématiquement de CVSS, d'où le besoin de croiser avec OSV.dev et GHSA.

Réactions outillage 2024-2025 :

• OSV.dev (Google, lancé en 2021) est passé en source primaire pour l'écosystème open-source et a été adopté par OSV-scanner et plusieurs gros consommateurs cloud-native.
• Trivy (Aqua Security) a renforcé l'usage de Red Hat OVAL, Alpine SecDB, Debian Security Tracker, Ubuntu USN comme sources distro, en complément du NVD.
• Grype (Anchore) a publié explicitement le multi-source matching et est passé d'une dépendance NVD prédominante à un mix NVD + GHSA + distro.
• Plusieurs équipes ops ont adopté vulncheck.com (commercial) comme source enrichie de remplacement quand le SLA NVD ne convenait plus.

6. Workflow de disclosure - timeline et statuts

La timeline canonique d'un CVE coordonné :

1. Découverte par chercheur, équipe interne ou via PoC ouvert.
2. Notification confidentielle au vendor / maintainer (PSIRT, security@, programme bug bounty).
3. Réservation CVE auprès du CNA approprié → statut RESERVED, ID alloué mais détails non publiés.
4. Triage par le vendor : confirmation, scoring CVSS interne, plan de patch.
5. Développement du fix → durée variable, médiane observée 2024-2025 environ 60 à 90 jours pour les éditeurs majeurs, mais avec une longue queue : certaines failles complexes sortent à 180+ jours.
6. Publication coordonnée : advisory vendor + record CVE en PUBLIC + parfois GHSA + parfois note distro.
7. Mise à jour KEV par CISA si exploitation observée (parfois pré-publication, parfois quelques semaines après).

Politiques de disclosure usuelles :

• Project Zero (Google), 90 jours + 30 grace. Référence du marché, citée comme borne haute par beaucoup d'équipes sécurité.
• CERT/CC, 45 jours par défaut, ajustable selon complexité.
• ZDI (Trend Micro), 120 jours standard, avec extensions négociables.
• Coordinated Vulnerability Disclosure (CVD), politique flexible, généralement 60-180 jours selon impact, complexité, exploitation observée.

Position tranchée : la fenêtre 90 jours fixée par Project Zero est devenue de facto une norme industrielle saine. Les éditeurs qui dépassent systématiquement 180 jours sans justification spécifique paient en réputation et finissent par avoir des disclosures uncoordinated forcées (cas observés régulièrement chez les éditeurs IoT et les équipementiers réseau historiques).

7. Usage opérationnel - SCA, gating, KEV-driven

Stack outillage 2026 en pipeline DevSecOps autour des CVE :

Exemple de gating CI/CD pragmatique 2026 (GitHub Actions + Trivy + KEV cross-check) :

name: vuln-gate
on: [pull_request]
 
jobs:
  trivy-kev-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Trivy filesystem scan (JSON output)
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          scan-ref: .
          format: json
          output: trivy-report.json
          severity: HIGH,CRITICAL
          ignore-unfixed: true
 
      - name: Pull CISA KEV catalog
        run: |
          curl -sSfL -o kev.json \
            https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
 
      - name: Fail si CVE present dans KEV
        run: |
          jq -r '.Results[]?.Vulnerabilities[]?.VulnerabilityID' trivy-report.json \
            | sort -u > scanned_cves.txt
          jq -r '.vulnerabilities[].cveID' kev.json | sort -u > kev_cves.txt
          comm -12 scanned_cves.txt kev_cves.txt > intersection.txt
          if [ -s intersection.txt ]; then
            echo "CVE présents ET dans KEV (exploités dans la nature) :"
            cat intersection.txt
            exit 1
          fi
          echo "Aucune CVE KEV-listée détectée."

Ce pipeline n'échoue que sur les CVE et présents dans CISA KEV, donc sur des vulnérabilités à la fois détectées dans le code et activement exploitées dans la nature. Tout le reste passe en avertissement et alimente un backlog géré hors du gate. C'est le bon ratio signal/bruit pour ne pas faire désactiver ton scanner par les équipes dev en 4 semaines.

Politique de remédiation pragmatique chiffrée, règle qui marche en 2026 dans des organisations matures :

8. Erreurs fréquentes et pièges 2026

9. Liens framework et SBOM

Le CVE ne vit pas seul, il s'inscrit dans un mapping plus large :

• CWE (Common Weakness Enumeration), taxonomie des classes de défaut. Top 25 CWE 2024 publié par MITRE en novembre 2024 (CWE-79 XSS, CWE-787 Out-of-bounds Write, CWE-89 SQL Injection en tête). Lien : https://cwe.mitre.org/top25/.
• CPE (Common Platform Enumeration), identifiant produit/version utilisé pour le matching. Format cpe:2.3:a:vendor:product:version:.... Maintenu côté NVD.
• NIST SSDF (Secure Software Development Framework, NIST SP 800-218 publié 2022), recommande explicitement la gestion des vulnérabilités via CVE et SBOM dans les pratiques PW.4 / RV.1.
• NIST SP 800-216 (Recommendations for Federal Vulnerability Disclosure Guidelines, mars 2023), cadre de référence pour les programmes CVD côté agences fédérales US.
• ISO/IEC 29147:2018 (Vulnerability Disclosure) et ISO/IEC 30111:2019 (Vulnerability Handling Processes), normes internationales du processus.
• SBOM au format CycloneDX (OWASP) ou SPDX (Linux Foundation), la liste des dépendances qu'on requête contre une base CVE pour produire un VEX (Vulnerability Exploitability eXchange, qui statue sur l'exploitabilité réelle d'un CVE pour un produit donné).
• MITRE ATT&CK, référentiel des techniques adverses, relié aux CVE quand un TTP est rendu possible par exploitation d'un CVE. Voir TTP - Tactics, Techniques, Procedures.

Position pratique : le pipeline 2026 mature génère un SBOM au build (Syft, Trivy, CycloneDX-cli), le persiste comme artefact, et le requête en continu contre les nouveaux CVE quotidiens publiés via le flux MITRE. Ça permet de répondre en heures (et pas en jours) à la question « est-ce que telle CVE qui sort aujourd'hui me concerne ? ». Sans SBOM persisté, la réponse demande un re-scan complet de l'image.

10. Cas marquants 2024-2026 à connaître

Quelques CVE de référence à avoir en tête pour donner du concret aux discussions :

Le cas CVE-2024-3094 xz-utils est particulièrement instructif : la backdoor a été injectée pendant 2+ ans par un mainteneur infiltré, et a été découverte par accident par Andres Freund (Microsoft Postgres) via un benchmark sshd qui consommait 500 ms de plus que la baseline. Sans cette anomalie de performance, la backdoor serait probablement passée en production debian stable. Cas d'école à intégrer dans toute formation supply chain security et toute discussion sur la limite des scanners SCA (qui ne détectent pas les backdoors, seulement les CVE publiées).

11. Pour aller plus loin

• IOC - Indicateurs de compromission, pour la couche détection/CTI qui consomme indirectement les CVE via les indicateurs liés à leur exploitation.
• TTP - Tactics, Techniques, Procedures, pour le mapping MITRE ATT&CK qui relie les CVE aux techniques adverses observées.
• Bootcamp DevSecOps, formation 12 semaines couvrant SCA, gating, SBOM, CVD policy en pipeline.
• Hub catégorie Glossaire cyber, autres définitions de référence Zeroday.
• Documentation officielle MITRE : https://www.cve.org/ et le dépôt bulk https://github.com/CVEProject/cvelistV5.
• CISA KEV catalog : https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
• FIRST EPSS : https://www.first.org/epss/.
• NIST NVD : https://nvd.nist.gov/.

12. Points clés à retenir

• CVE = identifiant, pas score, pas DB, pas patch. Format CVE-YYYY-NNNNN, opéré par MITRE depuis 1999, financé par CISA.
• 400+ CNAs distribuent l'attribution en 2026, dont 60 % côté éditeurs (Microsoft, Google, GitHub, Red Hat…), 20 % CERT/CC nationaux.
• Volume annuel stable : 25 000-30 000 CVE publiés/an depuis 2022, avec un pic à 28 961 en 2023.
• Format JSON 5.1 depuis fin 2023, accessible via API cveawg.mitre.org et bulk GitHub CVEProject/cvelistV5.
• Crise NVD 2024-2025 : 17 000+ CVE non enrichis fin 2024, 9 000+ encore en backlog fin 2025. Conséquence : ne plus traiter le NVD comme oracle unique, croiser avec OSV.dev + GHSA + KEV + distro.
• Mental model 2026 : CVE × CISA KEV × EPSS × CVSS, gate CI sur KEV + EPSS ≥ 0.7, pas sur CVSS seul.
• Politique disclosure de référence : Project Zero 90 jours + 30 grace, devenu standard de fait. ISO/IEC 29147 et 30111 cadrent le processus international.
• CVSS CNA vs CVSS NVD divergent dans 15-20 % des cas avec écart moyen 1.5-2 points : documenter explicitement la source utilisée par le gate.
• CVE marquants à connaître : CVE-2021-44228 (Log4Shell, 10.0), CVE-2024-3094 (xz-utils, supply chain backdoor), CVE-2024-6387 (regreSSHion OpenSSH).
• Stack outillage SCA pragmatique : Trivy + OSV-scanner + Dependabot, multi-source obligatoire, SBOM CycloneDX/SPDX persisté.
• Anti-pattern n°1 : bloquer sur CVSS ≥ 7.0 globalement → désactivation du gate par les devs en 4-6 semaines. Préférer KEV-driven gating.
• REJECTED ≠ patché : un CVE rejeté est un faux positif historique, pas un risque résiduel, filtrer ces entrées dans le triage.