Les pipelines CI/CD : l’angle mort qui menace votre système d’information en 2025

En mars 2025, notre écosystème DevOps a subi une compromission qu’on va qualifier en cascade qui a profondément marqué la communauté. Le 11 mars, des attaquants ont réussi à altérer l’action GitHub reviewdog/action-setup@v1 entre 18h42 et 20h31 UTC. Cette première brèche leur a permis d’obtenir plusieurs secrets, dont un jeton (glossaire) appartenant à l’organisation tj-actions.

En utilisant ce token dérobé, ils ont ensuite modifié l’action tj-actions/changed-files. Entre le 12 et le 15 mars, toutes les versions — de v1.0.0 à v45 — ont été redirigées vers un commit malveillant unique. Le code injecté lisait la mémoire du runner pour y récupérer des secrets (clés AWS, jetons GitHub, clés SSH). Ces informations étaient ensuite affichées dans les journaux de workflow.

• Dans les dépôts publics, ces journaux étaient visibles par tous.
• Dans les dépôts privés, les attaquants pouvaient y accéder grâce aux droits déjà obtenus.

Deux CVE ont été enregistrées : CVE-2025-30066 ↗ (tj-actions) et CVE-2025-30154 ↗ (reviewdog). La CISA a publié une alerte dès le 18 mars.

Chiffres clés :

• Fenêtre d’exploitation : 72 heures
• Portée : plusieurs milliers de dépôts
• Détection : 14 mars (StepSecurity)
• Impact : secrets compromis, risques de mouvements latéraux, propagation potentielle vers les environnements cloud

Sources :

• CISA → Supply Chain Compromise alert ↗
• Wiz Research → Cascading supply chain analysis ↗
• Palo Alto Unit42 → GitHub Actions supply chain attack ↗

Pourquoi cette compromission a été aussi efficace

Plusieurs faiblesses structurelles du pipeline CI/CD ont rendu l’attaque redoutable.

1. Utilisation de tags mutables

Beaucoup d’équipes référençaient les actions GitHub avec des tags mutables comme @v1 plutôt qu’avec un hachage immuable. Les attaquants ont pu les rediriger vers leur commit en quelques minutes.

2. Gestion trop permissive des contributeurs

Chez reviewdog, tous les contributeurs étaient ajoutés automatiquement à un groupe doté de droits en écriture. Cette équipe comptait 118 membres. Un seul compte compromis suffisait.

3. Runners persistants

Selon Wiz, 35 % des organisations utilisent encore des runners non éphémères, contrairement aux runners à exécution éphémère. Ces environnements conservent des fichiers temporaires, des variables d’environnement ou des historiques de commandes, facilitant la compromission successive des jobs.

4. Confiance excessive dans les dépendances

Une dépendance compromise suffit à propager rapidement une attaque. Les pipelines utilisent souvent des dizaines d’actions tierces sans vérification d’intégrité.

Ce qu’un pipeline compromis permet réellement

Un attaquant qui prend le contrôle du pipeline obtient des capacités que peu d’administrateurs possèdent :

Accès possibles :

• Code source de tous les projets
• Secrets cloud (AWS, Azure, GCP)
• Jetons API et identifiants de production
• Images Docker
• Artefacts signés
• Scripts et fichiers d’Infrastructure as Code

Actions possibles :

• Injecter du code malveillant dans les livrables
• Déployer automatiquement une backdoor
• Exfiltrer de la propriété intellectuelle
• Créer des comptes privilégiés invisibles
• Modifier des règles de sécurité
• Distribuer des binaires infectés aux clients

Cette mécanique reprend le modèle de l’affaire SolarWinds : compromission du build → diffusion automatique → milliers de victimes.

Les vulnérabilités cachées de vos pipelines

Secrets mal protégés

Les secrets circulent partout dans un pipeline (variables d’environnement, fichiers de configuration, paramètres d’actions). Dès qu’ils fuient dans les logs ou restent en clair sur le disque d’un runner, un attaquant peut les réutiliser pour pivoter vers le cloud ou vos registres d’artefacts.

• Variables d’environnement non sécurisées
• Journaux contenant des secrets
• Rotation insuffisante
• Secrets identiques sur dev/staging/prod

Permissions trop larges

Par défaut, GITHUB_TOKEN et les jetons cloud sont souvent surprovisionnés. Un jeton qui peut écrire dans les dépôts ou pousser des images permet d’empoisonner la chaîne d’approvisionnement. Le principe de moindre privilège limite l’impact d’une compromission.

• GITHUB_TOKEN avec des droits d’écriture par défaut
• Jetons cloud sans moindre privilège
• Runners partagés entre projets sensibles et dépôts publics

Manque de supervision

Sans visibilité, une exfiltration passe inaperçue. La centralisation des logs, des métriques réseau et des alertes comportementales permet de détecter les écarts (téléchargements inattendus, accès aux secrets hors des étapes prévues, connexions vers des domaines inconnus).

• Logs non centralisés
• Aucune alerte sur comportements inhabituels
• Connexions réseau non surveillées

Dépendances non verrouillées

Les workflows s’appuient sur des dizaines d’actions tierces. Avec des tags mutables ou latest, un acteur peut rediriger une référence vers un commit malveillant. Verrouiller par SHA et vérifier la provenance réduit le risque de dépendance compromise.

• Usage de latest
• Pas de vérification d’intégrité
• Dépendances transitives ignorées

Vos pipelines CI/CD sont devenus le système nerveux du SI

Les pipelines ne sont plus de simples outils d’automatisation. Ils orchestrent la livraison de vos logiciels et concentrent des accès critiques (secrets, droits d’écriture, publication). Leur compromission crée un effet de levier : un seul point de contrôle permet de toucher code, artefacts et déploiements.

Ils relient trois zones clés. En amont, les dépôts Git, les développeurs et les outils de collaboration alimentent le pipeline en code et en changements. Dans le pipeline, les runners exécutent les jobs, les registres d’artefacts stockent les livrables, les scans SAST, SCA et DAST vérifient la sécurité, et des outils de provenance et de signature assurent l’intégrité. En aval, les déploiements visent les clusters Kubernetes et les environnements cloud, avec accès aux bases de données et aux systèmes de distribution.

Cette position centrale transforme le pipeline en cible stratégique : toute compromission se propage très vite.

Êtes-vous sûr que vos pipelines respectent les bonnes pratiques ?

Piloter des centaines de pipelines répartis sur plusieurs dépôts, équipes et plateformes est un véritable défi de conformité et de maturité. Même avec des contrôles en place, des dérives apparaissent vite : retour de tags mutables, élargissement des permissions, runners non éphémères, dépendances non épinglées.

Ce problème est avant tout un enjeu de gouvernance: définir des règles, les appliquer partout, et vérifier en continu qu’elles sont respectées.

Avec R2Devops, vous centralisez vos bonnes pratiques et les appliquez de façon homogène à l’échelle. La solution vous aide à :

• Auditer automatiquement vos pipelines pour détecter les écarts (références immuables, permissions minimales, runners éphémères, provenance et signature d’artefacts).
• Normaliser les workflows via des modèles conformes pour éviter les variantes dangereuses.
• Suivre la conformité dans le temps et déclencher des actions correctives.

Résultat: vous réduisez les risques de supply chain liés aux erreurs de configuration et aux dérives opérationnelles, sans ralentir la livraison. À l’échelle de dizaines ou centaines de pipelines, c’est la seule approche viable pour garder un niveau de sécurité homogène.

Découvrir R2Devops

Pour en savoir plus et tester la plateforme, rendez-vous sur R2Devops :

• Site officiel : r2devops.io ↗
• Documentation : docs.r2devops.io ↗

Avec R2Devops, vous industrialisez vos bonnes pratiques CI/CD et suivez la conformité de vos pipelines dans le temps.