Chaque jour, des milliers de pipelines CI/CD s'exécutent dans vos environnements, déployent du code, accèdent à vos bases de données, poussent des images Docker vers votre registre privé. Et dans chacun de ces pipelines se trouvent des secrets — des clés API, des tokens cloud, des mots de passe de production — stockés en clair dans des variables d'environnement. La campagne GhostAction vient de voler 2 577 de ces secrets en quatre semaines. Voici pourquoi vos pipelines CI/CD sont probablement votre plus grande faille de sécurité non adressée.

Ce que cachent vraiment vos pipelines

La plupart des responsables sécurité que je rencontre ont une image floue de ce qui circule dans leurs pipelines CI/CD. Ils savent qu'il y a des clés API quelque part. Ils savent vaguement que le déploiement en production nécessite des credentials. Mais quand je demande de lister exhaustivement tous les secrets présents dans les workflows GitHub Actions ou GitLab CI de l'organisation, la réponse honnête est presque toujours la même : «On ne sait pas exactement».

C'est là que réside le problème. Un pipeline CI/CD moderne rassemble en un seul endroit une concentration de privileges sans équivalent dans le reste de votre infrastructure. Pensez à ce que contient un pipeline de déploiement typique d'une application web en 2026 :

  • Un token AWS ou GCP avec des droits de déploiement sur l'environnement de production
  • Un token Docker Hub ou votre registre privé pour pousser les images
  • Les credentials de votre base de données de staging (souvent identiques à la prod dans les petites équipes)
  • Une clé API Stripe ou Twilio pour les tests d'intégration
  • Un token Slack ou PagerDuty pour les notifications
  • Une clé SSH pour déployer sur vos serveurs physiques
  • Un token GitHub ou GitLab à large périmètre pour les opérations cross-repo

Dans un audit que j'ai réalisé pour un éditeur SaaS de taille moyenne en 2025, j'ai recensé 47 secrets distincts répartis sur 12 pipelines. Parmi eux, 8 donnaient un accès direct à la production, dont 3 avec des permissions administrateur cloud. Aucun ne faisait l'objet d'une rotation régulière. Certains n'avaient pas été changés depuis la création du pipeline, il y a trois ans. Un seul de ces secrets compromis aurait suffi pour un attaquant motivé à déclencher une catastrophe opérationnelle.

La concentration de ces privileges dans les pipelines n'est pas accidentelle — c'est une nécessité fonctionnelle. Un déploiement automatisé a besoin d'accès. Le problème n'est pas l'existence de ces secrets mais leur gestion : leur stockage, leur durée de vie, leurs permissions, leur auditabilité. Et sur ces quatre dimensions, la plupart des organisations que j'accompagne ont des lacunes significatives.

Comment les attaquants trouvent et exploitent vos secrets

Les attaquants qui ciblent les pipelines CI/CD en 2026 ont affiné leurs méthodes au point de les rendre quasi industrielles. Il existe aujourd'hui au moins quatre vecteurs d'attaque bien documentés qui permettent d'extraire des secrets de pipelines, avec des niveaux de sophistication variables.

Le vol de credentials de compte développeur

C'est le vecteur utilisé par GhostAction. L'attaquant compromet le compte GitHub ou GitLab d'un développeur — via du phishing ciblé, du credential stuffing sur des mots de passe réutilisés, ou le vol de tokens via un malware. Une fois le compte contrôlé, il dispose des droits du développeur sur ses dépôts, et peut injecter du code malveillant directement dans les workflows CI/CD sans déclencher la plupart des alertes de sécurité. Le commit passe comme un commit ordinaire d'un contributeur légitime.

Ce vecteur est particulièrement efficace parce qu'il contourne complètement les protections côté plateforme. GitHub ne peut pas distinguer un commit légitime d'un commit malveillant s'ils viennent du même compte avec les mêmes tokens d'authentification. Les organisations sans revue obligatoire des modifications de workflows sont directement exposées.

L'exploitation des pull requests de contributeurs externes

Dans les projets open source ou les dépôts acceptant des contributions externes, les workflows GitHub Actions peuvent être configurés pour s'exécuter automatiquement sur les pull requests. Si la configuration n'est pas correctement restreinte, un contributeur externe malveillant peut soumettre une pull request modifiant un workflow de manière à exfiltrer les secrets lors de l'exécution automatique du pipeline. Ce vecteur a été exploité dans plusieurs incidents supply chain documentés entre 2023 et 2026, notamment contre des projets NPM populaires.

La réinjection dans les logs d'exécution

Certaines configurations exposent accidentellement des secrets dans les logs de pipeline accessibles publiquement ou à l'ensemble de l'organisation. Un secret logué par inadvertance — via un echo de debug, une commande env ou un message d'erreur verbeux — peut rester accessible pendant des mois dans les archives de logs. J'ai trouvé des tokens de production valides dans des logs GitLab vieux de 18 mois lors d'un audit, jamais révoqués parce que personne ne surveillait les logs CI pour des patterns de secrets.

L'attaque sur l'infrastructure de runners

Les organizations qui utilisent des runners self-hosted pour leurs pipelines CI/CD ont une surface d'attaque supplémentaire : le runner lui-même. Un runner compromis — via une vulnérabilité dans le daemon d'exécution, un mauvais contrôle d'accès à la machine, ou une image Docker modifiée — a accès à tous les secrets injectés dans les pipelines qu'il exécute. Dans les architectures où un seul runner gère à la fois des déploiements de staging et de production, la compromission du runner équivaut à la compromission simultanée de tous ces environnements.

L'anatomie d'une attaque supply chain GitHub Actions : le cas GhostAction

La campagne GhostAction mérite une analyse détaillée parce qu'elle illustre parfaitement le niveau de sophistication auquel sont arrivés les attaquants qui ciblent les pipelines CI/CD, et parce qu'elle est représentative d'une catégorie d'attaques qui va continuer à progresser.

GhostAction est actif depuis septembre 2025. Sa première vague a touché 817 dépôts publics GitHub, exfiltrant 3 325 secrets. La vague d'août-septembre 2026 a touché 772 dépôts supplémentaires pour 2 577 secrets. Une troisième vague, détectée début octobre 2026, aurait atteint plus de 30 000 dépôts avec des modalités d'exfiltration confirmées. L'accélération est significative : entre la première et la troisième vague, le nombre de dépôts touchés a été multiplié par 37 en un an.

Ce qui distingue GhostAction des attaques supply chain moins sophistiquées, c'est la précision chirurgicale du workflow malveillant injecté. L'attaquant ne se contente pas de déployer un workflow générique qui tente d'accéder à des noms de secrets prédéfinis. Il analyse préalablement les workflows existants dans chaque dépôt ciblé pour identifier les noms exacts des secrets utilisés par cette organisation spécifique, puis génère un workflow sur-mesure qui ne cible que ces secrets précis. Cette approche maximise le taux de succès de l'exfiltration et minimise les signaux d'erreur qui pourraient alerter les équipes de sécurité.

Le nom du fichier injecté — github_actions_security.yml — et le message de commit — «Add Github Actions Security workflow» — sont soigneusement choisis pour paraître légitimes. Dans une organisation où les workflows de security scanning automatisé sont courants, ce commit passerait naturellement inaperçu dans une revue rapide. C'est du social engineering appliqué au niveau du commit, pas du phishing classique.

La transmission des secrets exfiltrés via une simple requête HTTP POST vers un serveur externe est à la fois une force et une faiblesse pour l'attaquant. C'est une force parce que c'est trivial à implémenter et difficile à bloquer dans les environnements où les runners ont accès à internet. C'est une faiblesse parce que c'est détectable par une surveillance du trafic réseau sortant des runners. Mais dans la réalité, combien d'organisations surveillent effectivement les connexions réseau de leurs runners CI/CD ? Dans mon expérience terrain, très peu.

Les erreurs que je vois systématiquement en audit

Après avoir audité plusieurs dizaines de pipelines CI/CD ces trois dernières années, j'ai une liste de patterns d'erreur que je retrouve quasi systématiquement. Ce ne sont pas des erreurs de débutants — des équipes expérimentées les commettent parce que la sécurité des pipelines est une discipline relativement récente et que les outils de référence (GitHub Actions, GitLab CI, Jenkins) ne poussent pas nativement vers les bonnes pratiques.

Erreur n°1 : des permissions trop larges sur les tokens

Le token par défaut GITHUB_TOKEN dans GitHub Actions a des permissions en lecture-écriture sur le dépôt. La plupart des workflows n'ont besoin que de la lecture. Donner accès en écriture à un workflow qui n'en a pas besoin, c'est offrir aux attaquants la capacité de modifier le code, de créer des releases, de déclencher d'autres workflows. Je vois régulièrement des workflows de tests unitaires avec des droits d'écriture sur le dépôt. Aucune justification technique.

Erreur n°2 : des secrets jamais révoqués

La durée de vie moyenne d'un secret dans un pipeline CI/CD est scandaleusement longue. Dans un audit récent, j'ai trouvé un token AWS créé en 2021 et jamais révoqué, utilisé pour déployer une application qui avait été retirée en 2023. Le secret continuait d'exister dans les variables du pipeline et dans les credentials AWS, offrant un accès à un compte cloud actif à quiconque le compromettrait. La rotation des secrets de pipeline est rarement intégrée dans les processus opérationnels.

Erreur n°3 : des secrets partagés entre staging et production

Pour des raisons de commodité, les équipes réutilisent souvent les mêmes credentials entre l'environnement de staging et de production. «C'est juste pour les tests». Sauf que le pipeline de staging est typiquement moins protégé que celui de production, ses logs sont plus accessibles, ses runners moins surveillés. Compromettre le staging pour accéder aux credentials de production est une technique classique, documentée dans plusieurs incidents majeurs ces trois dernières années.

Erreur n°4 : pas de review obligatoire sur les workflows

Dans la grande majorité des organisations que j'audite, il n'existe pas de politique de review obligatoire spécifique aux modifications de fichiers de workflow CI/CD. Les workflows sont traités comme du code ordinaire et suivent le processus de PR standard. Or modifier un workflow, c'est potentiellement modifier les permissions d'exécution de code dans un contexte privilégié. Ça devrait déclencher une revue sécurité systématique, distincte de la revue fonctionnelle du code.

Erreur n°5 : des runners self-hosted avec trop d'accès réseau

Les runners self-hosted ont souvent un accès réseau large parce qu'ils ont été configurés pour résoudre des problèmes de connectivité rencontrés lors des premiers déploiements. «On a ouvert le port machin parce que le build échouait». Ce pragmatisme initial crée une dette sécurité durable : un runner avec un accès réseau large et des secrets de production est une cible idéale pour un pivot latéral depuis un réseau compromis.

Comment sécuriser vos pipelines sans ralentir vos équipes

La bonne nouvelle : la sécurisation des pipelines CI/CD ne nécessite pas de refondre toute l'architecture. La plupart des mesures les plus efficaces sont des configurations, pas des développements. Voici les cinq actions les plus impactantes, par ordre de rapport efficacité/effort.

Action 1 : inventaire et audit des secrets (1-2 jours)

Avant toute chose, faites l'inventaire exhaustif de tous les secrets présents dans vos pipelines. GitGuardian propose un scanner gratuit pour GitHub et GitLab qui détecte les patterns de secrets dans les dépôts et les workflows. Trufflehog (open source) fait la même chose pour les dépôts privés en local. L'objectif est d'avoir une liste précise : quel secret, dans quel pipeline, avec quelles permissions, créé quand. Cet inventaire est le point de départ de tout programme de gestion des secrets CI/CD.

Action 2 : principe de moindre privilège sur tous les tokens (1 semaine)

Pour chaque secret identifié, réduire les permissions au strict nécessaire. Un token AWS utilisé pour déployer une Lambda en production n'a besoin que du droit lambda:UpdateFunctionCode, pas d'un accès administrateur au compte. Un token GitHub Actions n'a besoin que des droits contents: read si le workflow ne modifie pas le dépôt. Cette réduction du périmètre de chaque credential limite drastiquement l'impact d'une compromission.

Action 3 : politique de review obligatoire sur les workflows (configuration, 1 heure)

Sur GitHub, configurez une règle de protection de branche qui requiert une review obligatoire pour toute modification dans le répertoire .github/workflows/. Sur GitLab, utilisez les CODEOWNERS pour désigner des reviewers obligatoires pour les fichiers CI/CD. Cette mesure, négligeable en termes d'effort, crée une friction significative pour un attaquant cherchant à injecter un workflow malveillant.

Action 4 : rotation automatique des secrets (1-2 semaines)

Intégrez la rotation régulière des secrets de pipeline dans vos processus opérationnels. HashiCorp Vault avec le plugin secrets dynamiques pour AWS/GCP/Azure permet de générer des credentials temporaires à chaque exécution de pipeline, révoqués automatiquement après utilisation. Cette approche élimine le problème des secrets longue durée. Pour les organisations sans Vault, une rotation manuelle trimestrielle est un minimum acceptable — calendrier à formaliser dans un runbook.

Action 5 : surveillance du trafic réseau des runners (continu)

Les runners CI/CD doivent être traités comme des assets à surveiller, pas comme des serveurs de build transparents. Activez la surveillance des connexions réseau sortantes sur vos runners self-hosted, avec des alertes sur les connexions vers des domaines inattendus. Pour GitHub Actions avec runners hébergés, activez les logs d'audit GitHub qui tracent les exécutions de workflows et les accès aux secrets. Un workflow qui établit une connexion HTTP vers une adresse externe inconnue doit déclencher une alerte immédiate.

Mon avis d'expert

Le problème fondamental avec la sécurité CI/CD n'est pas technique : c'est organisationnel. Les pipelines sont nés comme des outils de productivité pour les développeurs, pas comme des composants de sécurité. Pendant des années, la sécurité a été appliquée après coup, en couche supplémentaire sur une architecture qui n'y était pas préparée. Résultat : on se retrouve avec des systèmes qui concentrent des privilèges énormes dans des processus rarement audités.

La campagne GhostAction, avec ses 30 000 dépôts potentiellement touchés en octobre 2026, n'est que la face visible du problème. Pour chaque organisation victime d'une exfiltration de secrets via un pipeline, combien d'autres ont des secrets compromis sans le savoir, parce qu'aucun scanner ne tourne, parce que les logs ne sont pas analysés, parce que la rotation n'a jamais été mise en place ? Dans mon expérience, les secrets CI/CD sont l'équivalent moderne des clés laissées sous le paillasson. Tout le monde sait que ce n'est pas une bonne idée. Presque personne ne le change vraiment.

Conclusion

La sécurité des pipelines CI/CD est devenue une priorité de premier rang en 2026, à mesure que les attaquants ont compris que les secrets de déploiement représentent l'accès le plus direct et le moins surveillé vers les environnements de production. GhostAction n'est pas une anomalie — c'est l'avant-garde d'une tendance lourde.

La bonne nouvelle, c'est que les mesures les plus efficaces sont aussi les plus simples : inventorier les secrets, réduire les permissions, imposer les reviews de workflows, faire tourner les credentials. Aucune de ces actions ne demande des mois de développement. Elles demandent de la volonté organisationnelle et du temps d'ingénierie — deux ressources rares, mais disponibles si la direction comprend l'enjeu.

Si vous voulez savoir précisément où se situent vos expositions, commencez par lancer GitGuardian ou Trufflehog sur vos dépôts ce soir. Ce que vous y trouverez vous surprendra probablement. Et si vous avez besoin d'un regard externe pour structurer un programme de sécurisation de vos pipelines, c'est exactement le type de mission que je réalise.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique.

Prendre contact