La plupart des équipes perçoivent une vulnérabilité d'élévation de privilèges comme un bug du noyau ou une utilisation abusive. sudo sur un serveur de production. En 2026, la version la plus dangereuse se trouve ailleurs : dans le pipeline qui compile et déploie votre code. Un CI/CD Ce processus détient régulièrement un accès en écriture à vos dépôts, aux jetons de vos registres de paquets et aux identifiants de votre cloud. Un attaquant qui parvient à exécuter du code au sein de ce processus n'a pas besoin d'obtenir beaucoup de privilèges. pipeline l'a déjà fait pour eux.
Ce guide explique à quoi ressemble une vulnérabilité d'élévation de privilèges dans CI/CD pipelineIl décrit les méthodes d'attaque les plus courantes utilisées par les attaquants, notamment la fermeture des conteneurs et des portes, et explique comment les bloquer.
En bref : vulnérabilité d’élévation de privilèges dans CI/CD pipelines
Dans une pipeline, l'attaquant n'a souvent pas besoin d'élever ses privilèges. pipeline Il les possède déjà. Une vulnérabilité d'élévation de privilèges dans CI/CD Il s'agit généralement d'une autorisation plus large que nécessaire, permettant l'exécution de code non fiable à l'intérieur.
- PipelineLes s sont privilégiés par conception. Ils lisent le code source, détiennent des secrets, publient des artefacts et déploient en production, ce qui en fait l'une des cibles d'escalade les plus précieuses de votre organisation.
- La plupart des failles de sécurité sont dues à des erreurs de configuration, et non à des exploits. jetons par défaut généraux,
pull_request_targetLes flux de travail qui exécutent du code dérivé et les clés cloud à longue durée de vie causent plus de dégâts que n'importe quelle faille zero-day. - L'élévation de privilèges du conteneur transforme une tâche en l'ensemble du processus d'exécution. Les conteneurs privilégiés, les utilisateurs root et un socket Docker monté font du conteneur de construction une porte d'entrée, et non une frontière.
- Cela se produit déjà à grande échelle. Le ver CHAINDROP utilisait des privilèges élevés sur les exécuteurs GitHub Actions pour lire les identifiants directement depuis la mémoire de l'exécuteur.
- La solution consiste à appliquer le principe du moindre privilège de manière continue. Contrôlez chaque jeton, renforcez la sécurité de chaque conteneur et détectez les dérives d'autorisation avant qu'un attaquant ne les découvre.
Qu'est-ce qu'une vulnérabilité ?
Une vulnérabilité d'élévation de privilèges est toute faille permettant à un utilisateur, un processus ou un fragment de code d'obtenir des autorisations supérieures à celles qui lui sont prévues. MITRE ATT&CK la surveille comme une tactique à part entière. TA0004 : Élévation de privilèges, car c'est cette étape qui transforme un petit point d'appui en véritables dégâts.
Il existe deux formes classiques :
- Escalade verticale : passer à un niveau supérieur, par exemple d'un utilisateur normal à root, ou d'un jeton en lecture seule à un jeton permettant l'écriture.
- Escalade horizontale : se déplacer latéralement, par exemple en utilisant l'accès d'un poste pour accéder au référentiel, aux secrets ou à l'environnement d'une autre équipe.
Les attaquants exploitent une vulnérabilité d'élévation de privilèges via trois types de failles : les bogues logiciels, les erreurs de configuration et les permissions excessives. Sur les serveurs, les bogues retiennent le plus l'attention. CI/CD pipelineLes erreurs de configuration et les permissions excessives font presque tout le travail.
Pourquoi est-ce si dangereux dans CI/CD pipelines
A pipeline Ce n'est pas qu'un simple outil de construction. C'est une identité automatisée offrant un accès parmi les plus étendus de votre entreprise. Un poste type peut :
- Consulter et modifier le code source
- Lire les secrets stockés dans les variables d'environnement, les coffres-forts et les services de métadonnées cloud
- Publier les paquets, les images et les artefacts de version
- Déploiement en environnement de test et de production
Le OWASP Top 10 CI/CD Risques de sécurité désigne directement ce problème. Son risque CICD-SEC-5 : Insuffisant Pipeline-Contrôles d'accès basés sur décrit comment les attaquants qui exécutent du code malveillant dans un pipeline abuser des permissions qui lui sont accordées de se déplacer latéralement, à l'intérieur ou à l'extérieur de CI/CD système.
Il ne s'agit pas d'une hypothèse. Lors de la campagne CHAINDROP en août 2026, le logiciel malveillant Les informations d'identification temporaires ont été extraites de la mémoire du runner GitHub Actions. et ont utilisé des jetons de publication volés pour infecter d'autres paquets. Sur les exécuteurs Linux, la charge utile a exécuté son collecteur via sudo lire la mémoire du processus d'exécution. Il s'agit d'une élévation de privilèges. CI/CD pipelineLe « s » dans sa forme la plus pure : une dépendance toxique, un accès privilégié au « runner » et à tous les secrets que le travail peut révéler. C’est le même schéma que nous observons dans nos conclusions hebdomadaires sur paquets npm malveillants.
Où se cache une vulnérabilité d'élévation de privilèges dans un pipeline?
Six voies d'accès communes, ce que chacune débloque pour un attaquant et le mécanisme de contrôle qui la bloque.
| Chemin d'escalade | Comment ça se passe | Ce que l'attaquant obtient | Comment le fermer |
|---|---|---|---|
| Surprivilégié pipeline jeton | Les flux de travail s'exécutent avec des étendues de jetons par défaut larges car aucun permissions le bloc est défini | Accès en écriture au code, aux versions et autres flux de travail | Définissez des droits par défaut en lecture seule et accordez un accès en écriture par tâche, uniquement lorsque cela est nécessaire. |
| Empoisonné pipeline efficace | pull_request_target ou des déclencheurs similaires extraient et exécutent du code provenant d'une branche non fiable | Secrets du dépôt et jeton d'écriture, à partir d'un seul pull request | N’exécutez jamais de code fork dans un contexte privilégié ; séparez les tâches de confiance et celles qui ne le sont pas. |
| Élévation de privilèges du conteneur | Créez des conteneurs exécutés en tant que root, en mode privilégié ou avec le socket Docker monté. | Accès root sur le serveur d'exécution et accès à toutes les tâches qu'il exécute. | Exécuter en tant qu'utilisateur non root, supprimer les capacités et bloquer l'élévation de privilèges dans la spécification du conteneur |
| Identifiants cloud à longue durée de vie | Clés cloud statiques stockées en tant que secrets ou variables d'environnement | Accès persistant aux comptes cloud, longtemps après la fin du travail | Utilisez des identifiants fédérés à durée de vie limitée et révoquer automatiquement les secrets divulgués |
| Coureurs auto-hébergés persistants | Les exécuteurs sont réutilisés entre les tâches et les dépôts sans être reconstruits. | Persistance et capacité à modifier les configurations des autres équipes | Utilisez des runners éphémères et isolez-les en fonction du niveau de confiance. |
| récits humains surprivilégiés | Les administrateurs inactifs, les collaborateurs externes et les modifications d'autorisations non vérifiées s'accumulent. | Un compte valide qui peut être modifié pipelineprotections des succursales et des succursales | Surveillez les accès en permanence et signalez toute modification anormale des autorisations. |
Élévation de privilèges du conteneur : lorsque le conteneur de construction n’est pas une limite
Les conteneurs donnent l'impression d'être isolés, c'est pourquoi les équipes les considèrent souvent comme une barrière de sécurité. CI/CD, bien souvent, ce n'est pas le cas. L'élévation de privilèges dans un conteneur se produit lorsque du code à l'intérieur d'un conteneur de compilation prend le contrôle de l'hôte, et par conséquent de toutes les autres tâches qui s'y exécutent.
Trois configurations expliquent la plupart des cas :
- Exécuter en tant que root. Si le processus à l'intérieur du conteneur est racine, toute tentative d'intrusion commence à partir de la position la plus forte possible.
- Mode privilégié. Un conteneur privilégié dispose d'un accès à l'hôte quasiment identique à celui d'un processus s'exécutant directement sur celui-ci.
- Une prise Docker montée. Montage
/var/run/docker.sockdans une tâche afin qu'elle puisse créer des images, elle confère efficacement à cette tâche les droits root sur l'hôte, car elle peut démarrer de nouveaux conteneurs privilégiés.
Des chercheurs en sécurité ont démontré comment cela se manifeste dans des systèmes d'intégration continue réels. Dans un cas bien documenté, des chercheurs sont passés de scripts de compilation exécutés dans un conteneur d'intégration continue à un Échappement complet du conteneur sur les hôtes de build de Cloudflare Pages, préciscar le conteneur était considéré comme la limite de sécurité.
Voici à quoi ressemble une spécification de tâche Kubernetes renforcée. Le paramètre clé est allowPrivilegeEscalation: false, Qui empêche un processus d'acquérir plus de privilèges que son parent, par exemple via des binaires setuid.
# Pod de construction renforcé : bloque les voies d’élévation de privilèges les plus courantes pour les conteneurs VersionAPI: v1 mots: Cosse métadonnées: Le nom: construction ci spec: contexte de sécurité: exécuterAsNonRoot: oui exécuterEnTantQueL'Utilisateur: 10001 profil seccomp: type: Exécution par défaut conteneurs: - Le nom: construire image: registry.example.com/build-image@sha256 : contexte de sécurité: autoriser l'élévation de privilèges: non privilégié: non système de fichiers racine en lecture seule: oui capacités:
Le même principe s'applique au Dockerfile lui-même. Ajoutez un utilisateur non root et connectez-vous avec cet utilisateur avant le point d'entrée :
# Exécuter le conteneur en tant qu'utilisateur non root De nœud:22-slim COURT useradd --uid 10001 --créer-maison constructeur RÉP TRAVAIL / app COPY --chown=constructeur : constructeur . . UTILISATEUR constructeur CMD ["nœud", "index.js"]
La documentation Kubernetes sur configurer un contexte de sécurité décrit chacun de ces paramètres en détail.
GitHub Actions : une vulnérabilité d’escalade de niveau pourtant bien visible.
GitHub Actions est l'endroit où de nombreuses équipes découvrent pour la première fois l'élévation de privilèges. CI/CD pipelineEn effet, les schémas dangereux semblent tout à fait ordinaires. Deux d'entre eux méritent d'être vérifiés dans chaque dépôt dès aujourd'hui.
Portée du jeton. Chaque flux de travail reçoit un GITHUB_TOKEN. Les propres directives de GitHub sur authentification automatique par jeton Il est clair qu'une action peut accéder à ce jeton même si vous ne le transmettez pas explicitement ; vous devez donc toujours limiter ses autorisations au minimum. Définir des autorisations en lecture seule en haut du flux de travail et accorder un accès en écriture pour chaque tâche permet d'éliminer d'emblée le chemin d'escalade le plus courant.
Le nom: construire on: [pousser] # Valeur par défaut pour chaque tâche : lecture seule autorisations: contenu: lire emplois: tester: continue à fonctionner: Ubuntu - dernière version mesures: # Épingler les actions tierces à un bloc complet commit SHA, étiquette non modifiable - Usages: actions/checkout@commit-sha> - courir: npm ci && npm test libérer: besoin: tester continue à fonctionner: Ubuntu - dernière version # Seul ce travail peut écrire, et seulement ce dont il a besoin autorisations: contenu: écrire mesures: - Usages: actions/checkout@commit-sha> - courir: ./scripts/release.sh
Déclencheurs non fiables. Flux de travail déclenchés par pull_request_target exécuter avec les secrets du dépôt cible et un jeton autorisant l'écriture, même lorsque le pull request provient d'une branche dérivée. Si ce flux de travail récupère et exécute ensuite le code de la branche dérivée, n'importe qui peut ouvrir un pull request et exécuter du code avec vos privilèges. Il s'agit d'une vulnérabilité d'élévation de privilèges qui ne nécessite aucune exploitation, juste une pull request. Conservez les étapes privilégiées sur le code de confiance et exécutez le code non fiable dans un flux de travail distinct sans secrets.
Si vous souhaitez observer ces modèles dans un endroit sûr, le chèvre xygeni dépôt collecte délibérément non sécurisé pipeline et IaC Configurations pour l'entraînement. Pour une analyse plus complète de votre configuration GitHub, consultez notre guide sur Comment savoir si une application ou un dépôt GitHub est sûr ?.
Comment prévenir une vulnérabilité d'élévation de privilèges dans CI/CD pipelines
Fermeture de l'élévation de privilèges dans CI/CD pipelineTout se résume à un principe : le moindre privilège, appliqué à tous les niveaux et vérifié en continu plutôt qu'une seule fois. Liste de contrôle pratique :
- Portée de chaque jeton. Accès en lecture seule par défaut, accès en écriture par tâche et aucun jeton à l'échelle de l'organisation dans les flux de travail du référentiel.
- Séparer le code de confiance et le code non fiable. N’exécutez jamais de code provenant de forks ou de contributeurs externes dans un travail qui contient des secrets.
- Renforcez la sécurité de chaque conteneur de construction. Utilisateurs non root, pas de mode privilégié, pas de socket Docker, fonctionnalités supprimées.
allowPrivilegeEscalation: false. - Remplacez les secrets bien gardés. Privilégiez les identifiants fédérés à courte durée de vie et révoquez immédiatement tout identifiant divulgué.
- Épinglez ce que vous utilisez. Actions et images de tiers de référence par commit SHA ou digest, donc une balise compromise ne peut pas modifier votre pipeline.
- Attention à la dérive. Les autorisations s'étendent au fil du temps. Alerte en cas de nouveaux administrateurs, d'affaiblissement des protections des branches et de modifications inattendues des flux de travail.
- Porte la pipeline. Faire échouer la compilation en cas d'erreur de configuration critique, avant la fusion.
Le plus difficile n'est pas de connaître ces règles, mais de les appliquer à des centaines de référentiels et de flux de travail qui évoluent quotidiennement.
Comment Xygeni bloque-t-il une vulnérabilité d'élévation de privilèges dans CI/CD?
Chaque voie d'escalade est associée à la capacité Xygeni qui la détecte ou la bloque.
| Analyse | Que fait Xygeni ? |
|---|---|
| Pipeline erreurs de configuration | Détecteurs de mauvaise configuration Analyser les définitions de tâches d'intégration continue, les scripts de compilation et les fichiers de configuration sur GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI et Jenkins, et signaler les autorisations plus étendues que celles recommandées. |
| Élévation de privilèges du conteneur | IaC et les contrôles des conteneurs Ce document couvre les fichiers Dockerfile, les fichiers docker-compose, les manifestes Kubernetes et les charts Helm, y compris les conteneurs exécutés en tant que root. |
| Utilisateurs surprivilégiés et inactifs | L'analyse du moindre privilège identifie les utilisateurs inactifs et surprivilégiés, et Health Check transforme chaque découverte en billet |
| Dérive des permissions | La détection d'anomalies alerte en cas de modifications d'autorisations inhabituelles, de fusions anormales et d'installations de plugins inattendues. |
| Identifiants divulgués | La détection des secrets couvre le code, pipelineimages et conteneurs, avec révocation automatique pour les types de secrets pris en charge |
| Code malveillant dans le pipeline | Bloque les shells inversés et les téléchargements de logiciels malveillants dans pipelineen temps réel, et MEW détecte les paquets malveillants avant même qu'une signature ne soit disponible |
| Toujours vérifier | Pre-commit hooks et CI guardrails Échouez la compilation en cas de problèmes critiques, avec des politiques YAML personnalisées pour vos propres règles. |
Les contrôles sont conformes aux OWASP Top 10 CI/CD Risques de sécurité et standards telle que CIS, NIST et OpenSSFChaque découverte se déverse dans Xygeni ASPM, où elle est traitée en priorité au même titre que les découvertes concernant le code, les dépendances et les secrets, afin que la vulnérabilité d'élévation de privilèges qui atteint réellement la production soit corrigée en premier.
La plupart des escalades de privilèges dans CI/CD pipelineLe script « s » est déjà présent dans vos fichiers de flux de travail, en attente d'exécution de code non fiable.
QFP
Qu'est-ce qu'une vulnérabilité d'élévation de privilèges dans CI/CD?
Il s'agit de toute faiblesse qui permet à du code de s'exécuter dans un pipeline obtenir un accès plus étendu que celui requis par la tâche, comme un jeton surprivilégié, un flux de travail exécutant du code non fiable contenant des secrets, ou un conteneur de construction pouvant atteindre l'hôte.
Qu'est-ce que l'élévation de privilèges de conteneur ?
L'élévation de privilèges dans un conteneur se produit lorsqu'un processus à l'intérieur d'un conteneur obtient des privilèges plus élevés, souvent les privilèges root sur l'hôte. Les causes fréquentes sont l'exécution en tant que root, le mode privilégié et un socket Docker monté.
Le allowPrivilegeEscalation: false Empêcher les évasions de conteneurs ?
Il bloque un mécanisme important : l’obtention par un processus de privilèges supérieurs à ceux de son parent, par exemple via des binaires setuid. Son efficacité est optimale lorsqu’il est utilisé avec un utilisateur non root, des capacités restreintes et sans mode privilégié.
Is pull_request_target toujours dangereux ?
Pas en soi. Cela devient une vulnérabilité d'élévation de privilèges lorsque le flux de travail extrait et exécute du code provenant de pull request, car ce code s'exécute alors avec vos secrets et un jeton permettant l'écriture.
Comment puis-je identifier les voies d'élévation de privilèges dans de nombreux dépôts ?
Les revues manuelles ne sont pas adaptables à grande échelle. Une solution automatisée CI/CD L'outil de sécurité analyse en continu chaque flux de travail, spécification de conteneur et ensemble d'autorisations, et alerte en cas d'extension anormale.
