Votre pipeline CI/CD : La porte dérobée favorite des attaquants 🚪

Dans le paysage actuel du développement logiciel, les pipelines d’Intégration Continue et de Déploiement Continu (CI/CD) sont devenus la colonne vertébrale d’une livraison logicielle efficace et rapide. Ces systèmes automatisés simplifient le passage du commit de code au déploiement en production, permettant aux organisations de livrer des fonctionnalités plus vite que jamais. Cependant, cette efficacité a un coût caché : les pipelines CI/CD sont devenus l’une des cibles les plus attrayantes pour des attaquants sophistiqués, offrant un accès direct aux “clés du royaume.”

La montée du paysage de menaces

Le contexte de sécurité entourant les pipelines CI/CD s’est considérablement détérioré ces dernières années. En 2024, la Base de Données Nationale de Vulnérabilités (NVD) a enregistré près de 40 000 CVE – une augmentation de 39 % par rapport à 2023. Plus inquiétant encore, la tendance : les experts en sécurité anticipent une hausse des incidents de sécurité liés à CI/CD, alors que les attaquants continuent d’exploiter les vulnérabilités dans les processus de build, pipelines et dépendances.

Cette recrudescence d’attaques n’est pas accidentelle. Les pipelines CI/CD représentent une cible irrésistible car ils contiennent tout ce qu’un attaquant doit pour compromettre une organisation entière : identifiants de déploiement, clés API, mots de passe de bases de données, jetons d’accès à l’infrastructure cloud, et la capacité d’injecter du code malveillant directement dans les systèmes en production. Contrairement aux vecteurs d’attaque traditionnels qui nécessitent de franchir plusieurs couches de défense, un pipeline CI/CD compromis offre un point d’entrée unique avec un accès en cascade aux ressources critiques.

Pourquoi les pipelines CI/CD sont des cibles privilégiées

Considérez votre pipeline CI/CD comme le système nerveux central de votre processus de livraison logicielle. Il touche tous les aspects du cycle de développement, des dépôts de code source aux environnements de production. Cette position privilégiée en fait le rêve de tout attaquant pour plusieurs raisons.

Premièrement, les pipelines CI/CD nécessitent des permissions étendues pour fonctionner. Ils doivent accéder aux dépôts de code source, aux registres d’artefacts, à l’infrastructure cloud, aux cibles de déploiement, et à de nombreux services tiers. Chacun de ces points d’accès représente un potentiel coffre-fort de crédentiels et de secrets. Un seul pipeline compromis peut exposer des clés AWS, des identifiants de service Azure, des chaînes de connexion de bases de données, des tokens API, et des certificats de signature — tout ce qui est nécessaire pour prendre le contrôle de toute votre infrastructure.

Deuxièmement, les systèmes CI/CD fonctionnent avec une confiance implicite. Le code qui traverse le pipeline est généralement supposé légitime, puisqu’il provient de votre système de contrôle de version et passe par vos processus de build. Cette relation de confiance crée un point aveugle où du code malveillant peut se cacher en toute impunité, contournant les contrôles de sécurité traditionnels qui se concentrent sur les menaces externes.

Troisièmement, la complexité des écosystèmes CI/CD modernes crée de nombreuses surfaces d’attaque. Un pipeline typique s’intègre à des dizaines d’outils et de services : systèmes de contrôle de version, gestionnaires de paquets, frameworks de test, scanners de sécurité, outils de couverture de code, registres de conteneurs, et plateformes de déploiement. Chaque point d’intégration représente une vulnérabilité potentielle, et la toile d’interconnexions rend difficile une visibilité et une sécurité globales.

Confusion des dépendances : exploiter la chaîne d’approvisionnement

L’une des techniques d’attaque les plus insidieuses ciblant les pipelines CI/CD est l’attaque par confusion des dépendances. Cette technique exploite la façon dont les gestionnaires de paquets résolvent les dépendances, notamment lorsque les organisations utilisent à la fois des dépôts publics et privés.

La confusion des dépendances se produit lorsqu’un gestionnaire de dépendances récupère par erreur une version publique d’une dépendance au lieu de la dépendance privée prévue depuis un artifactory interne. L’attaque fonctionne parce que de nombreux gestionnaires de paquets, lors de la résolution des dépendances, vérifient les dépôts publics comme npm, PyPI ou Maven Central en complément ou même avant de consulter les registres privés.

Les attaquants exploitent ce comportement en identifiant les noms de paquets internes utilisés par les organisations ciblées — souvent divulgués via des messages d’erreur, des dépôts publics ou des offres d’emploi — puis en publiant des paquets malveillants portant des noms identiques dans des dépôts publics. Lorsqu’un développeur ou un système CI/CD tente d’installer des dépendances, le gestionnaire peut télécharger involontairement la version malveillante publique au lieu de la version privée légitime.

Les conséquences peuvent être graves. En 2024, des chercheurs ont découvert deux faux paquets utilisant le DLL side-loading pour échapper à la détection et exécuter du code nuisible. Une fois installés, ces dépendances malveillantes exécutent du code arbitraire dans l’environnement de build, pouvant voler des secrets, modifier le code source ou établir des portes dérobées persistantes.

Des attaques de grande envergure récentes ont montré l’impact réel de cette menace. Le 5 septembre 2025, GitGuardian a découvert GhostAction, une attaque massive de la chaîne d’approvisionnement affectant 327 utilisateurs GitHub sur 817 dépôts. Les attaquants ont injecté des workflows malveillants qui ont exfiltré 3 325 secrets, incluant des tokens PyPI, npm, et DockerHub via des requêtes HTTP POST vers un endpoint distant.

La sophistication de ces attaques continue d’évoluer. Les attaques modernes par confusion des dépendances utilisent souvent des techniques pour échapper à la détection, telles que l’exécution différée de charges utiles, une logique conditionnelle qui ne se déclenche que dans des environnements spécifiques, et l’obfuscation pour dissimuler le code malveillant aux scanners automatisés.

Exécution de pipeline empoisonnée : injection de code malveillant

Une autre menace critique pour la sécurité des CI/CD est l’Exécution de pipeline empoisonnée (PPE), une technique qui a gagné en importance à mesure que les attaquants ont affiné leurs méthodes de compromission des processus de build. PPE est un vecteur d’attaque qui abuse des permissions d’accès à un système de gestion du code source (SCM) dans le but de faire exécuter des commandes malveillantes par un pipeline CI.

Ce qui rend PPE particulièrement dangereux, c’est que les attaquants n’ont pas besoin d’un accès direct à l’environnement de build lui-même. Ils exploitent plutôt les permissions dans le dépôt de code source pour manipuler la façon dont le pipeline s’exécute. Il existe deux variantes principales de cette attaque : PPE directe et PPE indirecte.

Dans les attaques PPE directes, les adversaires modifient directement les fichiers de configuration du pipeline — comme .gitlab-ci.yml, .github/workflows, ou Jenkinsfile — pour injecter des commandes malveillantes. Ces modifications peuvent ajouter des étapes qui exfiltrent des secrets, établissent des portes dérobées, ou modifient les artefacts de build.

Cependant, les pratiques de sécurité modernes protègent souvent ces fichiers de configuration par des revues de code et des permissions restreintes. C’est là que la PPE indirecte devient pertinente. L’attaquant peut empoisonner le pipeline en injectant du code malveillant dans des fichiers référencés par le fichier de configuration, comme des Makefiles exécutant des commandes définies dans le “Makefile”, des scripts référencés dans le pipeline, ou des fichiers de tests où les frameworks de test s’appuient sur des fichiers dédiés stockés dans le même dépôt.

Considérons un processus de build typique qui exécute make test dans son pipeline. Un attaquant avec un accès en écriture pourrait modifier le Makefile pour inclure des commandes supplémentaires s’exécutant lors de la phase de test. Ces commandes pourraient exporter des variables d’environnement contenant des secrets, envoyer des données sensibles à des serveurs externes via curl, ou modifier les artefacts compilés pour y ajouter des portes dérobées — tout cela sans changer le fichier de configuration du pipeline ni passer par une revue de code.

Le périmètre d’attaque s’élargit encore lorsqu’on considère les scripts de build, frameworks de test, et fichiers de résolution de dépendances. De nombreux pipelines exécutent des scripts Python, shell ou Node.js dans le cadre de leur processus de build. Chacun de ces points représente une opportunité d’injection où un attaquant peut introduire du code malveillant s’exécutant avec tous les privilèges du pipeline.

Le risque d’intégration de tiers

Les pipelines CI/CD modernes n’opèrent que rarement en isolation. Ils s’intègrent à de nombreux outils et services tiers qui améliorent leur fonctionnalité : outils de couverture de code, services de scan de sécurité, plateformes de test de performance, services d’automatisation de déploiement, et solutions de monitoring. Bien que ces intégrations offrent des capacités précieuses, chacune représente un risque potentiel.

Les intégrations tierces nécessitent généralement des permissions étendues pour fonctionner efficacement. Un outil de couverture de code doit accéder à votre code source et aux résultats de test. Un scanner de sécurité requiert des permissions pour lire vos dépôts et souvent des identifiants pour tester les environnements de déploiement. Un service d’automatisation de déploiement doit accéder à l’infrastructure de production. Si l’un de ces services tiers est compromis — via ses propres vulnérabilités ou par une attaque de la chaîne d’approvisionnement — les attaquants peuvent accéder à votre pipeline et à tout ce qu’il touche.

Le problème s’aggrave lorsque l’on considère les crédentiels que ces services nécessitent. Beaucoup utilisent des tokens d’accès longue durée ou des clés API stockées comme variables d’environnement ou secrets dans la configuration du pipeline. Si un attaquant parvient à accéder à votre pipeline par un vecteur — confusion des dépendances, PPE, ou compromission de crédentiels — il peut extraire ces crédentiels tiers et pivoter pour compromettre ces services aussi.

Les outils de couverture de code présentent une surface d’attaque particulièrement intéressante. Ces outils doivent généralement lire l’ensemble de votre code, y compris les fichiers de test, pour calculer la couverture. Certains sont des services SaaS, ce qui signifie que votre code est transmis à des serveurs externes. Bien que les fournisseurs réputés appliquent de solides contrôles de sécurité, l’architecture fondamentale crée des opportunités d’exfiltration de données. Un attaquant qui compromet un service de couverture de code — ou qui exécute simplement un service malveillant déguisé en outil légitime — peut récolter du code source propriétaire, identifier des vulnérabilités, et découvrir des secrets ou crédentiels en dur.

Gestion des secrets : Les joyaux de la couronne

Au cœur de la plupart des incidents de sécurité CI/CD se trouve un problème fondamental : la gestion des secrets. Les pipelines nécessitent l’accès à de nombreux crédentiels sensibles, et de mauvaises pratiques de gestion créent des opportunités pour les attaquants d’accéder à ces “joyaux de la couronne.”

Les secrets courants stockés dans les environnements CI/CD incluent les crédentiels d’infrastructure cloud (clés d’accès AWS, identifiants de service Azure, comptes de service Google Cloud), chaînes de connexion de bases de données, clés API pour des services tiers, certificats SSL/TLS et clés privées, crédentiels de registre de conteneurs, et clés de signature pour le code et les artefacts. La compromission d’un seul secret de grande valeur peut donner à un attaquant un accès étendu aux systèmes en production.

Les approches traditionnelles de stockage des secrets dans les pipelines CI/CD s’avèrent souvent inadéquates. Hardcoder des secrets dans le code source ou dans des fichiers de configuration — malgré leur mauvaise réputation — reste étonnamment courant. Les secrets stockés en texte clair dans des variables d’environnement du pipeline sont facilement accessibles à quiconque a accès au dépôt. Même les secrets chiffrés ou variables peuvent être vulnérables si les clés de déchiffrement sont mal gérées ou si le pipeline lui-même est compromis.

Le défi s’intensifie avec la rotation des secrets. Beaucoup d’organisations utilisent des crédentiels à long terme dans leurs pipelines, car faire tourner des secrets nécessite de mettre à jour la configuration, de coordonner avec plusieurs équipes, et peut causer des interruptions. Cette réticence à faire tourner les crédentiels signifie qu’une fois compromis, les attaquants peuvent avoir un accès prolongé avant détection.

Conséquences réelles

Les risques théoriques liés aux vulnérabilités de sécurité CI/CD se sont concrétisés dans de nombreuses brèches de grande envergure. La campagne GhostAction mentionnée plus tôt a affecté des centaines de dépôts et exfiltré des milliers de crédentiels. Des attaques similaires ont ciblé des grandes organisations, entraînant des fuites de données, un accès non autorisé aux systèmes en production, et le déploiement de code malveillant aux utilisateurs finaux.

Lorsqu’un pipeline CI/CD est compromis, le rayon d’action peut être étendu. Les attaquants peuvent injecter des portes dérobées dans des applications en production, voler de la propriété intellectuelle et des données sensibles, déployer des mineurs de cryptomonnaie pour exploiter les ressources, établir des mécanismes de persistance pour un accès à long terme, pivoter pour compromettre des systèmes et services connectés, et même manipuler des builds pour introduire des vulnérabilités contournant les revues de sécurité.

Les coûts financiers et réputationnels de ces incidents peuvent être énormes. Au-delà des coûts de remédiation immédiats, les organisations risquent des amendes réglementaires, la perte de confiance des clients, et des dommages à long terme à leur posture de sécurité. Dans certains cas, des pipelines compromis ont conduit à des attaques de la chaîne d’approvisionnement affectant des clients et partenaires en aval, multipliant l’impact.

Se protéger : mesures de sécurité essentielles

Sécuriser les pipelines CI/CD nécessite une approche de défense en profondeur qui adresse les multiples vecteurs d’attaque évoqués. Bien qu’aucune solution unique ne garantisse une protection complète, la mise en œuvre de contrôles de sécurité en couches réduit considérablement le risque.

Commencez par le contrôle d’accès et l’authentification. Mettez en place des contrôles d’accès basés sur les rôles (RBAC) stricts pour la configuration des pipelines et la gestion des secrets. Exigez une authentification multifactorielle pour tous les comptes ayant accès aux pipelines. Limitez le nombre d’utilisateurs pouvant modifier la configuration ou accéder aux secrets. Utilisez des crédentiels à courte durée de vie, générés dynamiquement, plutôt que des tokens à long terme autant que possible.

Pour la gestion des dépendances, mettez en place des mesures de protection contre la confusion des dépendances. Configurez les gestionnaires de paquets pour privilégier les registres privés. Utilisez des fonctionnalités comme les préfixes de scope npm ou les group IDs Maven pour namespace les paquets internes. Envisagez d’enregistrer des paquets fictifs dans des dépôts publics pour empêcher l’usurpation. Vérifiez régulièrement les dépendances via des sommes de contrôle ou la validation de signatures.

La sécurité de la configuration des pipelines est cruciale. Stockez-les dans un contrôle de version et exigez une revue de code pour toutes modifications. Utilisez des règles de protection de branches pour empêcher les modifications non autorisées. Séparez la configuration du code applicatif autant que possible. Implémentez des pipelines en tant que code avec validation et tests avant déploiement. Utilisez des commits signés pour garantir l’intégrité des modifications.

Pour les intégrations tierces, adoptez une approche zero-trust. Évaluez soigneusement la posture de sécurité de tout service tiers avant intégration. Accordez le minimum de permissions nécessaires. Auditez régulièrement les accès et permissions de ces services. Surveillez toute activité inhabituelle ou exfiltration de données. Envisagez d’exécuter les outils sensibles dans des environnements isolés.

La gestion des secrets mérite une attention particulière. Ne stockez jamais de secrets dans le code source ou dans la configuration du pipeline. Utilisez des solutions dédiées comme HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, ou autres. Mettez en place une rotation automatique des secrets. Utilisez des crédentiels à courte durée de vie. Chiffrez les secrets au repos et en transit. Activez la journalisation des accès. Envisagez d’utiliser l’identité de charge de travail pour éliminer complètement les crédentiels longue durée.

Surveillance et détection

Même avec des contrôles préventifs robustes, la détection est essentielle. Implémentez une journalisation complète de toutes les activités du pipeline : modifications de configuration, accès aux secrets, téléchargements de dépendances, opérations de déploiement. Utilisez des systèmes SIEM pour agréger et analyser ces logs.

Surveillez les indicateurs de compromission tels que des exécutions inhabituelles, des modifications inattendues, du trafic réseau anormal, des tentatives d’authentification échouées, des téléchargements ou versions de dépendances suspectes, ou des exfiltrations massives de données.

Mettez en place des alertes automatisées pour toute activité suspecte. Les équipes de sécurité doivent être alertées immédiatement en cas de modification critique, d’accès hors norme aux secrets, ou de comportement anormal. Effectuez régulièrement des audits de sécurité et des tests de pénétration ciblant l’infrastructure CI/CD pour identifier les vulnérabilités avant que des attaquants ne les exploitent.

La voie à suivre

À mesure que les pipelines CI/CD évoluent et deviennent plus centraux dans la livraison logicielle, leur sécurité doit évoluer en parallèle. Les organisations ne peuvent pas se permettre de traiter la sécurité des pipelines comme une réflexion après coup ou de se reposer uniquement sur des défenses périmétriques. Les attaques sophistiquées ciblant ces systèmes exigent des défenses tout aussi sophistiquées.

La bonne nouvelle, c’est qu’il est possible de sécuriser les pipelines CI/CD avec la bonne combinaison de technologies, processus et engagement organisationnel. En comprenant le paysage des menaces, en mettant en œuvre des contrôles de sécurité en profondeur, et en restant vigilant via la surveillance et la détection, les organisations peuvent réduire significativement leur risque de compromission.

Le point clé est de reconnaître que votre pipeline CI/CD n’est pas juste une infrastructure — c’est une frontière de sécurité critique qui nécessite le même niveau de protection que vos systèmes en production. Chaque organisation utilisant des pipelines automatisés doit se demander : Si un attaquant accédait à notre pipeline CI/CD aujourd’hui, que pourrait-il faire ? La réponse à cette question doit orienter vos priorités de sécurité.

N’attendez pas qu’une incident de sécurité survienne pour agir. Passez en revue votre posture de sécurité des pipelines dès aujourd’hui. Auditez votre gestion des secrets, évaluez vos intégrations tierces, mettez en place des contrôles contre la confusion des dépendances et PPE, et établissez des capacités de surveillance et de détection robustes. Votre pipeline doit être votre avantage concurrentiel, pas la porte dérobée favorite d’un attaquant.

L’avenir de la livraison logicielle dépend des pipelines CI/CD, mais cet avenir doit être construit sur une base de sécurité. En prenant des mesures proactives pour protéger ces systèmes critiques, les organisations peuvent bénéficier d’un déploiement rapide tout en maintenant une posture de sécurité pour protéger leurs actifs, leurs clients, et leur réputation dans un paysage de menaces de plus en plus hostile.