Vue lecture

L’Europe tient son programme CVE décentralisé

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.

  •  

ServiceNow et OpenAI embrayent sur le vocal… et le legacy

Pour faire tomber la barrière de la langue, il y a OpenAI.

ServiceNow présente les choses ainsi. En toile de fond, un accord sur 3 ans qui le verra, entre autres, exploiter GPT-5.2 pour développer des technologies de compréhension et de synthèse vocales. Au bout, nous promet-on, il y aura des agents multilingues qui fonctionneront sans passer par la modalité texte.

Les modèles GPT seront également mis à contribution sur la partie computer use (« agent utilisateur d’ordinateur »). En ligne de mire, notamment, l’orchestration des outils bureautiques et l’automatisation des systèmes hérités (ServiceNow évoque les mainframes).

Les modèles OpenAI, déjà bien ancrés dans ServiceNow

Dans la pratique, ServiceNow a déjà établi de multiples passerelles avec OpenAI.

Sur sa plate-forme, les fonctionnalités conversationnelles, génératives et agentiques sont majoritairement regroupées sous la marque Now Assist.

Les produits Now Assist s’installent comme des plug-in. Ils donnent accès à trois types de composantes : des skills génératives, des agents et des flux agentiques. Ces briques ciblent généralement un usage au sein d’une application. Par exemple, pour les skills, la génération de documentation sur la partie gestion du travail collaboratif. Pour les workflows agentiques, l’obtention de conseils de gouvernance dans la CMDB.

Certains flux agentiques opèrent au niveau de la plate-forme : enquêter sur des incidents, créer des tâches à partir d’images, proposer des réponses à un sondage…

Par défaut, Now Assist repose sur un service interne, qui associe des modèles maison spécialisés* et des modèles ouverts « sélectionnés, configurés ou améliorés par ServiceNow, sa communauté ou ses partenaires ».

Pour certaines skills, il est possible de basculer sur des fournisseurs alternatifs : Google (Gemini 2.5 Flash et 2.5 Pro), Anthropic (Claude 3.7 Sonnet sur Amazon Bedrock)… ou OpenAI (GPT-4.1 et GPT-4.1-mini sur Azure OpenAI).

Avec toute application est installé un « contrôleur d’IA générative ». Il permet d’interfacer des LLM externes par API, au niveau des concepteurs de flux, d’agents et de scripts. En standard, cela donne quatre possibilités :

  • Générer du texte à propos d’un topic ServiceNow
  • Résumer un topic
  • Créer un use case et un prompt associé
  • Faire de l’analyse de sentiment

Ce contrôleur fait la passerelle avec OpenAI et Azure OpenAI. Ainsi qu’avec Google, Aleph Alpha, Amazon (Bedrock) et IBM (watsonx). Il inclut aussi un connecteur générique.

* En tête de liste, un modèle 12B à usage général (création de flux, modération, écriture de code…) fondé sur Mistral Nemo Instruct.

Illustration générée par IA

The post ServiceNow et OpenAI embrayent sur le vocal… et le legacy appeared first on Silicon.fr.

  •  

Accor a écarté Terraform de sa stack data engineering

Terraform est efficace pour gérer de l’infrastructure ; pas des workflows data.

À force de s’en servir en conjonction avec Snowflake, Accor en est arrivé à ce constat. Entre absence de validation locale, gestion manuelle des dépendances et nécessité d’outils externes pour contrôler la qualité des données, la mise à l’échelle et la collaboration s’en trouvaient limitées.

Le groupe hôtelier a fini par basculer vers une stack associant dbt Core pour les transformations et un Airflow managé (Astro) pour l’orchestration, avec la bibliothèque Cosmos – proposée par le fournisseur d’Astro – pour faire la passerelle. Cette dernière déduit automatiquement le lignage des tâches et déclenche les contrôles de data quality immédiatement après la matérialisation d’une table ou d’une vue lors d’un dbt run.

Une déploiement Airflow « léger » qui rafraîchit uniquement les DAG

Le passage au tandem dbt-Airflow a impliqué un changement des pratiques de data engineering. Entre autres, passer d’étapes séparées pour la création et le peuplement de tables à une action unique utilisant exclusivement la commande SQL SELECT.

Chaque équipe possède son repo et déploie indépendamment. Tout part d’un template géré avec Copier. L’ensemble est réconcilié dans le projet principal, poussé vers Astro. Les scripts CI/CD sont centralisés dans un dépôt étiqueté.

Par défaut, Astro reconstruit l’image Docker à chaque modification. Le déploiement : dure alors environ 5 minutes. Il existe toutefois un mode « léger » dont Accor a tiré parti. Celui-ci synchronise simplement les DAG (graphes acycliques dirigés, représentant les tâches à exécuter) et évite ainsi un rebuild.

Pour exploiter ce mécanisme, le pipeline CI/CD place chaque projet dbt dans le répertoire dags/ du projet principal. Le déploiement dure alors environ 1 minute. Il couvre 95 % des exécutions. L’autre option reste utilisée pour l’upgrade des dépendances et les changements sur l’image de base (i.e. modification des fichiers include, requirements.txt ou Dockerfile).

Imbriquer chaque projet dbt dans le répertoire dags/ permet à Cosmo de générer automatiquement les tâches Airflow correspondantes. Et de construire des DAG sans intervention manuelle. Les tests peuvent se faire en local, avec dbt run et dbt test.

Accor vise un pipeline pour chaque équipe

Avec une telle configuration multilocataire, les cycles d’upgrade d’Airflow peuvent ralentir. Il n’y a, par ailleurs, pas moyen de prioriser des jobs. Et l’existence d’un seul chemin CI/CD vers la prod pose la question du point unique de défaillance, en plus des risques de conflit de noms et de bibliothèques.

Accor réfléchit donc à donner à chaque équipe son pipeline et à découpler la propriété du code. Tout en permettant l’hibernation des workflows à faible trafic.

Illustration générée par IA

The post Accor a écarté Terraform de sa stack data engineering appeared first on Silicon.fr.

  •  
❌