Introduction
Pendant longtemps, les équipes data et les équipes de développement logiciel ont évolué dans des infrastructures séparées. Les premières orchestraient leurs traitements via des schedulers dédiés, des scripts shell ou des plateformes ETL propriétaires. Les secondes vivaient dans des dépôts git, des pipelines CI/CD et des registres de conteneurs. Ces deux mondes ont fusionné au fil des dernières années : les équipes data engineering ont adopté massivement GitLab comme colonne vertébrale de leurs pipelines — dbt, Apache Spark, ingestion temps réel, tests de qualité de données, déploiement de modèles. Et avec cette convergence arrive un risque que peu d'organisations ont clairement cartographié.
Une faille dans le cœur du moteur CI/CD
Le 12 octobre 2026, GitLab a divulgué la CVE-2026-97229, une vulnérabilité de sévérité maximale (CVSS 10.0) affectant le compilateur d'expressions régulières intégré à son moteur CI/CD. La faille — un dépassement d'entier (integer overflow) — réside dans le composant qui analyse, compile et évalue les expressions régulières présentes dans les fichiers de configuration de pipelines.
Concrètement, lorsque le compilateur calcule la mémoire nécessaire pour traiter les états et les transitions d'une regex, un débordement arithmétique peut produire une taille bien inférieure à la réalité. Le moteur alloue alors un espace insuffisant, écrit au-delà des limites du tampon, et ouvre la voie à une exécution de code arbitraire sur le serveur. L'analyse de Rapid7 précise que l'exploitation pratique nécessite des droits de contribution sur un projet public — une condition aisément remplie sur les instances self-managed qui autorisent la création de projets ouverts, configuration courante dans de nombreux déploiements d'entreprise.
Toutes les installations GitLab CE et EE en versions 19.2, 19.3 et 19.4 antérieures aux correctifs (respectivement 19.2.8, 19.3.5 et 19.4.2) sont concernées. Les instances GitLab.com et GitLab Dedicated ont été corrigées dès la divulgation.
Le vrai problème : ce que les pipelines data stockent
Pour une équipe data engineering, le fichier .gitlab-ci.yml n'est pas un simple fichier de build. Il concentre les variables CI/CD qui alimentent les connexions aux entrepôts de données (Snowflake, BigQuery, Redshift), les clés d'accès aux buckets de stockage objet, les tokens d'authentification vers les catalogues de données, les secrets des registres de conteneurs hébergeant les images de traitement, et les clés de déploiement cloud.
Un attaquant qui exécute du code sur le serveur GitLab ne compromet pas seulement le dépôt source. Il accède à l'ensemble des variables secrètes des pipelines, peut injecter des modifications silencieuses dans les jobs de transformation, ou détourner les flux de données avant qu'ils n'atteignent les couches de reporting. Dans une architecture data moderne où GitLab orchestre l'ingestion, la transformation et la publication, la surface d'exposition dépasse largement le périmètre DevOps classique.
Ce que les équipes data doivent faire maintenant
La priorité absolue est la mise à jour des instances self-managed vers les versions 19.4.2, 19.3.5 ou 19.2.8. Aucune mesure de contournement n'a été documentée par GitLab : la mise à jour est l'unique remédiation.
Au-delà du correctif immédiat, plusieurs points méritent une révision dans les semaines qui suivent :
- Rotation des secrets : renouveler les variables CI/CD donnant accès aux systèmes de données critiques, les clés cloud et les tokens d'API, sans attendre de confirmer si une exploitation a eu lieu
- Revue des droits de contribution sur les projets publics ou semi-ouverts hébergeant des pipelines de données
- Externalisation vers un vault dédié pour les credentials les plus sensibles, plutôt que leur stockage natif dans les variables GitLab
- Surveillance des processus enfants lancés depuis les composants serveur GitLab, signal précoce d'une exploitation non détectée
La convergence data-DevOps appelle une gouvernance unifiée
Cette faille illustre un écart de maturité fréquent : les équipes data ont adopté les outils DevOps sans toujours intégrer les pratiques de sécurité qui les accompagnent. À mesure que les pipelines de données deviennent des infrastructures critiques — alimentant tableaux de bord de direction, modèles de scoring ou flux de reporting réglementaire —, leur sécurité ne peut plus être déléguée par défaut à l'équipe plateforme. Le fichier de configuration CI/CD est devenu, qu'on le veuille ou non, une pièce de gouvernance data à part entière.