Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

Je me suis rendu compte d’un truc l’autre jour en écrivant le post sur la CVE-2026-0544. On balance du “CVE” à toutes les sauces, mais est-ce qu’on sait vraiment comment le figatellu est fabriqué ? Tiens, prenons un moment pour décortiquer ce monument de la sécurité informatique, avant que l’IA ne décide de gérer ça toute seule et qu’on ne comprenne plus rien.

Qui tient la boutique ?

C’est le MITRE Corporation qui gère la liste CVE (Common Vulnerabilities and Exposures). C’est une organisation à but non lucratif américaine, financée par la CISA (Cybersecurity and Infrastructure Security Agency) du DHS. Bref, c’est l’Oncle Sam qui régale.

En gros, si les USA décident de couper le robinet, on est mal. (Spoiler : on a failli voir ça de près).

Comment on chope un numéro ?

Ce n’est pas le MITRE qui fait tout le boulot (ils ne sont pas fous). Ils délèguent à des CNA (CVE Numbering Authorities). Ce sont des entreprises (Microsoft, Google, Red Hat…), des chercheurs ou des organismes qui ont le droit d’attribuer des IDs.

Quand je trouve une faille, je ne demande pas au MITRE directement, je vais voir un CNA. Si la faille est dans un produit Microsoft, c’est Microsoft (le CNA) qui me donne le numéro. Juge et partie ? Un peu, oui.

Un peu d’histoire (et de poussière)

La Genèse

La première CVE ?

CVE-1999-0001 : Une vulnérabilité dans la stack IP de BSD.

Extrait de la description officielle :

Buffer overflow in ip_input.c in BSD-derived TCP/IP implementations allows remote attackers to cause a denial of service (crash or hang) via crafted packets.

Elle a été créée en 1999 pour une raison simple : c’était le bazar.

Chaque outil de sécurité avait ses propres noms pour les mêmes failles. “Bug-42” chez l’un, “Vuln-X” chez l’autre. La CVE, c’était l’Espéranto de la sécu. Sauf que l’Espéranto, personne ne le parle (sauf Vera ), alors que la CVE, tout le monde l’utilise.

Le “Great CVE Freeze” de 2025

Ah, 2025… Quelle année. Suite à l’élection et aux coupes budgétaires drastiques dans les agences fédérales (“Make Budgets Small Again”), le NVD (National Vulnerability Database) qui enrichit les CVE s’est retrouvé à l’arrêt complet pendant des mois. On a bien cru que c’était la fin. Les délais d’analyse ont explosé.

Comment on s’en est sorti ? La communauté a dû prendre le relais. CISA a lancé son programme “Vulnrichment” pour que les CNA enrichissent eux-mêmes les données (CVSS, CPE) sans attendre le NVD. C’était le chaos, mais un chaos collaboratif. Une belle leçon d’humilité pour l’administration centralisée.

L’inflation galopante

Si on regarde les stats :

  • 1999 : quelques centaines.
  • 2010 : ~4 500.
  • 2020 : ~18 000.
  • 2025 : on approche les 50 000.

C’est exponentiel. Soit le code est de plus en plus pourri, soit on cherche mieux. (Je vote pour la réponse 42 :-) ).

Pourquoi les numéros sont devenus bizarres ?

Avant, c’était simple : CVE-AAAA-NNNN (4 chiffres). On se disait “9999 failles par an, ça suffira large !”. Quelle naïveté. En 2014, on a fait sauter la limite. Maintenant, on peut avoir 5, 6, 7 chiffres.

Mais pourquoi ça semble aléatoire ? Parce que les CNA réservent des blocs. Microsoft peut réserver le bloc 20000-30000 en début d’année. S’ils publient la CVE-2026-20001 en janvier et que Google publie la CVE-2026-10001 en mars, on a l’impression que les numéros ne se suivent pas chronologiquement. C’est normal, c’est de la pré-allocation.

Le parcours du combattant (Processus)

  1. Découverte : Je trouve une faille (ou mon prompt d’IA la trouve pour moi).
  2. Report : Je contacte le vendeur ou un CNA tiers.
  3. Réservation : Le CNA me file un ID (ex: CVE-2026-1337) qui reste “RESERVED”.
  4. Publication : Une fois le patch prêt (ou le délai dépassé), la CVE devient “PUBLIC” avec les détails.

Les autres, ceux qui ne sont pas CVE

Le monde n’est pas qu’américain (si, si, je vous jure).

  • GitHub Advisory Database (GHSA) : Très orientée Data/Dev et open source. Souvent plus rapide pour les libs npm/pip/etc. Ils ont leurs propres IDs (GHSA-xxxx-xxxx-xxxx) qui sont souvent mappés vers des CVE plus tard.

  • L’Union Européenne : L’Europe essaie de pousser ses propres standards via l’ENISA et le réseau des CSIRT, notamment avec la directive NIS2 qui impose du reporting. On n’a pas encore une “EVE” (Euro Vulnerability Exposure) unifiée qui remplace la CVE, mais on a des bases comme celle du CERT-EU qui agrègent différemment.

  • La Chine (CNNVD) : La China National Vulnerability Database. C’est… particulier. Ils sont souvent très rapides (parfois plus que le MITRE), mais on soupçonne parfois que certaines failles y sont analysées par les services de renseignement avant d’être publiées. C’est une autre vision de la “veille”.

À retenir 📌

  • La base CVE est gérée par le MITRE (USA) mais alimentée par des CNA fédérés.
  • Le format des numéros n'est plus séquentiel à cause des réservations de blocs par les CNA.
  • La crise de 2025 a forcé la communauté à décentraliser l'enrichissement des données (Vulnrichment).
  • Il existe d'autres systèmes de numérotation (GHSA, CNNVD) qui coexistent avec la CVE, chacun ayant ses spécificités.
  • La compréhension du processus CVE est cruciale pour une veille efficace en sécurité informatique.
  • La CVE reste un pilier central de la sécurité, malgré ses imperfections et son histoire mouvementée.

Sources

“La sécurité est un processus, pas un produit.”
Bruce Schneier