Ceci n’est pas un concurrent du programme CVE de MITRE, mais un complément.

En façade, telle a toujours été la position du CERT luxembourgeois depuis l’annonce du projet GCVE (Global CVE Allocation System). C’était en avril 2025. On nous promettait alors le développement d’un système décentralisé : les autorités de numérotation allaient pouvoir attribuer des identifiants et gérer la divulgation sans passer par un organisme central.

Neuf mois plus tard, l’initiative, cofinancée par l’UE, a effectivement pris corps… dans une certaine mesure. Une base de vulnérabilités vient notamment d’y être adossée. Plusieurs bonnes pratiques ont par ailleurs été publiées pour assurer le fonctionnement du système. Et une vingtaine d’entités, de natures assez diverses, ont été désignées autorités de numérotation.

Autorité	Identifiant
CIRCL (CERT luxembourgeois)	1
EUVD	2
Red Hat	3
Swisscom	79
VulDB	100
Ericsson	101
EAGC	102
Schutzwerk	103
AboutCode Europe	104
OPC Foundation	105
SK-CERT	106
Thales PSIRT	107
Securin	108
Concinnity Risks	109
Vulnetix	110
Mogwai Labs	111
CERT-QC	112
VulnCheck	404
DFN-CERT Services	680
Austin Hackers Anonymous	1337
Pentagrid	2342
Cisco Talos	31337

Cette diversité reflète les critères d’admission : en théorie, quiconque a une politique de divulgation publique de vulnérabilités peut prétendre devenir autorité de numérotation.

L’identifiant 1 a été réservé au CIRCL, porteur du projet. Le 2, à la base EUVD (EU Vulnerability Database), opérée par l’ENISA (Agence européenne pour la sécurité). L’identifiant 0 est quant à lui dédié au mapping des CVE.

GCVE, contre les aléas géopolitiques

L’annuaire des autorités de numérotation est publié au format JSON. Ces dernières ont deux options pour communiquer les données sur les vulnérabilités. D’un côté, un endpoint statique fournissant un fichier. De l’autre, une API REST avec des points de terminaison recent et latest, éventuellement assortis de filtres (sources et nombre de résultats). Le projet GCVE n’impose pas de format, mais recommande de s’aligner sur CVE Record.

Les bonnes pratiques publiées concernent la vérification de l’intégrité du fichier d’annuaire, la divulgation coordonnée de vulnérabilités et l’attribution d’identifiants. Trois autres sont à l’état de brouillon. Elles abordent les formats de déclaration des vulnérabilités et le protocole de publication décentralisée.

Un outil open source sert d’implémentation de référence pour ces bonnes pratiques : vulnerability-lookup… qu’on doit aussi au CIRCL. C’est sur lui que repose la base GCVE*. L’EUVD aussi, d’ailleurs.

Pas d’opposition frontale avec MITRE, donc, mais un enjeu de résilience non dissimulé. Il s’agit à la fois d’éviter le « point de défaillance unique »… et de moins dépendre des aléas géopolitiques. En toile de fond, l’avenir un temps très incertain du programme CVE. L’an dernier, le gouvernement américain l’avait refinancé in extremis.

* Base hébergée dans les datacenters du CERT luxembourgeois.

Illustration générée par IA

The post L’Europe tient son programme CVE décentralisé appeared first on Silicon.fr.

-- Article en partenariat avec LockSelf --

Il faut bien se rendre à l'évidence qu'une bonne partie des fuites de données en entreprise passent par des fichiers mal sécurisés. Par exemple ce fameux document Excel avec les salaires qui traîne sur le serveur depuis 2019, le ZIP envoyé via WeTransfer "parce que c'est plus simple", ou encore le dossier client partagé sur Google Drive avec le lien accessible à quiconque a l'URL.

Bref, c'est le Far West total en matière de sécurité et de confidentialité !

Maintenant si vous avez lu mon article sur LockPass (le gestionnaire de mots de passe certifié ANSSI), vous savez déjà que LockSelf fait les choses sérieusement. Et c'est pourquoi, aujourd'hui je vais vous présenter deux autres de leurs outils : LockTransfer pour les fichiers en transit, et LockFiles pour les fichiers au repos.

Et c'est reparti pour une journée de moine à écrire sur le meilleur site tech de l'univers et aujourd'hui, j'ai envie de vous parler de Core War et de cybersécurité.

Core War, c'est un jeu de programmation hyper culte qui est devenu populaire dans les années 80 et dans ce jeu, y'a des sortes de guerriers numériques qui se foutent sur la gueule pour prendre le contrôle d'une machine virtuelle . Et je vous avoue que c'est assez kiffant à voir.

Et croyez le ou non, des chercheurs de Sakana AI et du MIT se sont appuyés sur ce concept pour créer leur Digital Red Queen (DRQ) , c'est à dire un algorithme qui utilise des LLM pour faire évoluer ces programmes de "combat" de façon totalement autonome.

L'idée de base en fait, c'est de simuler la fameuse " Reine Rouge " de l'évolution biologique. Cette théorie de la Reine Rouge explique en gros que les espèces doivent évoluer sans cesse juste pour rester à leur place face à leurs prédateurs.

Et sous la forme de code, ça donne qu'à chaque round, l'algorithme cherche à faire éclore un nouveau "warrior" capable de battre tous les champions précédents. Pour cela, l'algo DRQ s'appuie par défaut sur un modèle gpt-4.1-mini (mais c'est configurable évidemment) qui fait office de moteur de mutation génétique. L'IA génère alors de nouveaux programmes, les fait se combattre, et ne garde que celui qui surpasse la lignée.

C'est une bataille de code sans fin où seuls les meilleures survivent !

Et là où ça devient vraiment balaise, c'est que l'IA ne se contente pas de copier-coller du code existant. Non, cette petite futée invente de véritables stratégies qui feraient bégayer Sun Tzu.

Les chercheurs ont également pu observer certains phénomènes de convergence phénotypique (oui moi aussi j'avais aucune idée de ce que ça voulait dire). C'est-à-dire que des guerriers issus de lignées différentes finissent à un moment par adopter tous les mêmes tactiques de combat. Genre bombardement ciblé, auto-réplication massive ou création intensive de processus. Et ça c'est pas bon.

Alors pour tenter de maintenir une certaine diversité de comportements, l'équipe a utilisé des algos de MAP-Elites ce qui leur a permis de classer les programmes selon des critères comme le nombre de processus créés ou l'occupation de la mémoire pour éviter de tomber dans une sorte de pierre-feuille-ciseaux sans fin !

Et ça a plutôt bien fonctionné car même si les chercheurs notent que la diversité finit par baisser au fil des runs, cela permet quand même de découvrir des stratégies variées avant que l'évolution ne converge.

Maintenant c'est bien rigolo tout ça mais peut-être que vous vous demandez à quoi ça sert à part faire mumuse avec du vieil assembleur ? Et bien les auteurs pensent que leurs travaux pourrait être appliqués en cybersécurité.

En comprenant comment des programmes peuvent s'adapter de façon autonome à des adversaires qui mutent en permanence, on peut imaginer des systèmes de défense plus autonomes et résilients. On est un peu dans la même veine que ce que j'évoquais avec Evo 2 et l'ADN fonctionnel , mais appliqué au logiciel pur.

Voilà, alors je ne sais pas ce que ça va donner mais j'ai trouvé ça cool de voir comment un vieux concept de 1984 est devenu une super sandbox pour tester les limites de l'évolution artificielle des logiciels.

Bien sûr, tout le code est dispo sur GitHub (le simulateur Core War lui-même vient du projet de Rodrigo Setti ), avec des instructions pour installer ça via Conda et lancer vos propres arènes de combat. J'sais pas si vous essayerez mais si c'est le cas, je veux bien un feedback dans quelques temps.

Et surtout, un grand merci à Timothée qui a partagé ça sur son compte LinkedIn .