CI/CD : le nouveau vecteur roi des attaques supply chain en 2026

En 2026, compromettre un réseau d'entreprise à la traditionnelle — scanner des ports, exploiter une CVE, pivoter — c'est du travail. Compromettre la chaîne CI/CD qui construit et déploie les applications de l'entreprise, c'est beaucoup plus rentable. Un seul point d'entrée, un impact sur l'intégralité de la production. Les attaquants ont fait leurs calculs depuis longtemps. La question est : est-ce que les défenseurs les ont faits aussi ?

La CVE-2026-97229 n'est pas un accident — c'est un signal

Quand GitLab publie une CVE CVSS 10.0 dans son parseur de configuration CI/CD, et que Rapid7 sort un PoC fonctionnel en moins de 24 heures, certains lisent ça comme un incident technique de plus à patcher. Je lis ça comme la confirmation d'une tendance lourde qui s'accélère depuis trois ans.

CVE-2026-97229 permet à n'importe qui d'exécuter du code arbitraire sur un serveur GitLab en soumettant une regex malformée dans un fichier .gitlab-ci.yml. Pas besoin de compte. Pas besoin de connaître l'organisation ciblée. Il suffit que l'instance soit accessible et non patchée. Et 25 766 instances l'étaient au moment de la publication du PoC, selon Censys.

Ce qui rend cette faille particulièrement intéressante du point de vue d'un attaquant, c'est son positionnement dans la kill chain. Une instance GitLab compromise donne accès à :

• L'intégralité des dépôts de code source, y compris les branches protégées et les secrets parfois intégrés par inadvertance dans l'historique git
• Les variables CI/CD — là où les équipes stockent leurs clés cloud, leurs tokens API, leurs credentials de production
• Les pipelines de build — un endroit idéal pour injecter du code malveillant qui se retrouvera dans chaque déploiement suivant
• Les deploy keys et tokens de déploiement qui donnent souvent accès direct aux environnements de production

C'est le jackpot de la supply chain attack. Et tout ça pour le coût d'une requête HTTP mal formée vers un serveur non patché.

Pourquoi le CI/CD est devenu la cible prioritaire

Il y a cinq ans, les attaques supply chain visaient principalement les registres de packages publics — PyPI, npm, RubyGems. L'empoisonnement de packages (event-stream en 2018, ua-parser-js en 2021) avait démontré qu'une dépendance compromise pouvait toucher des millions de projets en cascade.

Mais les entreprises ont réagi. Les outils de Software Composition Analysis se sont généralisés. Les lock files sont devenus standard. Les registres privés proxifient les packages publics. La surface d'attaque des dépendances directes s'est réduite — pas éliminée, mais réduite.

Résultat logique : les attaquants ont remonté la chaîne. Pourquoi cibler une dépendance en espérant qu'elle soit importée dans la bonne cible, quand on peut attaquer directement l'outil qui assemble toutes les dépendances et construit le binaire final ? Le CI/CD est devenu le point de contrôle ultime de la supply chain logicielle.

Les chiffres confirment cette évolution. Selon le rapport Sonatype 2025, les attaques ciblant directement les plateformes CI/CD ont augmenté de 312% entre 2023 et 2025. Le rapport Palo Alto Unit 42 de début 2026 identifie la compromission de pipelines CI/CD comme le vecteur d'entrée numéro un dans les incidents de supply chain analysés — devant les dépendances empoisonnées et les typosquats combinés.

L'anatomie d'une attaque CI/CD réussie

Pour comprendre pourquoi c'est si dévastateur, il faut suivre le chemin d'un attaquant qui exploite CVE-2026-97229 ou une vulnérabilité équivalente sur une plateforme CI/CD.

Phase 1 — Accès initial. L'attaquant exploite la CVE et obtient l'exécution de code sur le serveur GitLab. Dans les cas observés en 2026, cette phase dure moins d'une minute sur une instance non patchée exposée sur Internet.

Phase 2 — Récupération des secrets. Les variables CI/CD sont la première cible. Sur un serveur GitLab compromis au niveau du processus, les mécanismes de chiffrement au repos sont contournés par lecture directe en mémoire. En pratique, les attaquants récupèrent en moyenne 47 credentials distincts par instance GitLab compromise selon les observations de Wiz Research en 2025 — clés AWS, tokens GitHub, credentials de bases de données production.

Phase 3 — Modification des pipelines. L'attaquant insère dans les fichiers de configuration CI/CD une étape discrète qui s'exécute dans chaque build. Le code peut être aussi simple qu'un script shell qui exfiltre les artefacts vers un C2, ou aussi sophistiqué qu'une modification binaire des livrables finaux — injection de backdoors dans les binaires compilés.

Phase 4 — Persistance et propagation. Les artefacts compromis sont déployés dans les environnements de staging puis de production, à chaque cycle de déploiement. L'attaquant n'a plus besoin d'accès direct aux environnements de production — ils lui livrent automatiquement les systèmes compromis.

C'est précisément pour cette raison que les attaques supply chain via CI/CD sont difficiles à détecter : le vecteur d'intrusion est dans l'outil de développement, loin des environnements de production surveillés par les équipes SOC.

Les angles morts des équipes de sécurité

Dans mon expérience d'auditeur, les équipes de sécurité ont généralement une bonne visibilité sur leurs réseaux de production. Firewalls, IDS, SIEM alimenté par les logs de prod, EDR sur les serveurs. Mais quand je pose la question du CI/CD, les réponses sont révélatrices.

Qui surveille les logs de votre instance GitLab ? "Les devs." Qui a accès en écriture aux pipelines CI/CD ? "Les développeurs, et l'admin GitLab." Quand avez-vous audité vos variables CI/CD pour la dernière fois ? Silence.

Cette asymétrie de surveillance est systémique. Les plateformes CI/CD ont été conçues pour être accessibles et flexibles — les contraindre avec les mêmes contrôles que les systèmes de production crée des frictions avec les équipes de développement. Résultat : elles restent dans un angle mort de la sécurité, perçues comme des outils de développement plutôt que comme de l'infrastructure critique.

Voici ce que les plateformes CI/CD stockent typiquement dans une organisation de taille moyenne, sur la base des audits que j'ai menés :

Ces chiffres sont issus d'audits sur des entreprises de 200 à 5 000 salariés en France entre 2024 et 2026. La réalité opérationnelle est que le CI/CD est devenu le coffre-fort non gardé du SI moderne.

Les plateformes CI/CD les plus ciblées en 2026

GitLab n'est pas le seul concerné. L'ensemble des plateformes CI/CD majeures présente une surface d'attaque significative.

GitHub Actions est ciblé via des attaques de typosquatting d'actions et des compromissions de comptes de mainteneurs d'actions populaires. En 2025, la compromission d'une action utilisée par 4 200 dépôts avait exposé les secrets CI/CD de l'ensemble de ces projets. GitHub a répondu avec des contrôles supplémentaires, mais la surface reste large.

Jenkins, souvent auto-hébergé dans des configurations legacy, présente régulièrement des vulnérabilités critiques — CVE-2024-23897 en 2024, plusieurs CVE CVSS 9+ en 2025. Sa popularité dans les grandes entreprises industrielles et financières en fait une cible de choix. La problématique Jenkins est aggravée par la dette technique : des instances déployées il y a 5 à 7 ans, rarement mises à jour, avec des plugins tiers accumulés dont personne ne suit le cycle de vie.

CircleCI et Buildkite ont été touchés par des incidents majeurs respectivement en 2023 et 2024, exposant des tokens de déploiement et des secrets de build. Les plateformes SaaS CI/CD ne sont pas immunisées — une compromission côté fournisseur peut avoir des effets en cascade sur tous leurs clients.

La convergence de ces incidents indique une tendance structurelle : les plateformes CI/CD sont passées de la cible opportuniste à la cible délibérée et prioritaire dans les opérations d'espionnage industriel et de cybercriminalité sophistiquée.

Ce que les équipes doivent changer

La réponse à cette menace ne passe pas uniquement par le patching des CVE — bien que ce soit une condition nécessaire. Elle nécessite une réévaluation du modèle de sécurité appliqué aux plateformes CI/CD.

En priorité :

• Audit des secrets CI/CD. Inventorier l'ensemble des variables stockées. Identifier celles qui donnent accès à des ressources critiques. Évaluer si ces accès peuvent être remplacés par des mécanismes OIDC (accès dynamique sans secret statique) — AWS IAM Roles Anywhere, Azure Workload Identity, HashiCorp Vault avec JWT auth.
• Séparation des privilèges de pipeline. Un pipeline de build ne doit pas avoir les mêmes droits qu'un pipeline de déploiement production. Les environnements sensibles (staging, prod) doivent nécessiter une approbation manuelle avec MFA avant tout déploiement.
• Surveillance des modifications de pipeline. Tout changement dans les fichiers de configuration CI/CD doit déclencher une alerte dans le SIEM. Les modifications de .gitlab-ci.yml, Jenkinsfile ou workflows GitHub Actions doivent être traitées avec le même niveau d'attention que les modifications de code dans les zones critiques.
• Rotation régulière des secrets. Les secrets statiques dans les pipelines CI/CD doivent avoir une durée de vie limitée. L'idéal est les remplacer par des mécanismes d'authentification dynamique.
• Durcissement et patch management des plateformes CI/CD. Les instances self-managed doivent être traitées avec la même rigueur que n'importe quel serveur de production exposé. Ce n'est généralement pas le cas aujourd'hui.

Conclusion

Les attaques supply chain via CI/CD représentent un changement de paradigme que beaucoup d'organisations n'ont pas encore intégré dans leur modèle de menace. Nous continuons à construire nos défenses autour du réseau et de l'endpoint pendant que les attaquants contournent ces défenses en remontant plus haut dans la chaîne — là où le code est écrit, assemblé, et préparé pour la production.

La réponse requiert un déplacement du regard : traiter les plateformes CI/CD comme de l'infrastructure critique, avec les mêmes exigences de patching, de surveillance et de contrôle d'accès que les systèmes de production. Ce n'est pas une question d'outils — c'est une question de modèle mental. Tant que GitLab sera perçu comme "un outil de développement" et non comme "une infrastructure critique", la surface d'attaque restera largement ouverte.