Un même parc de runners servant à la fois des dépôts publics et privés, ou des environnements de dev et de prod, transforme le moindre job hostile en pivot vers les autres. C'est le terrain des pwn requests et de l'empoisonnement de pipeline (PPE) : une pull request venue de l'extérieur s'exécute là où elle ne devrait pas, avec accès à des secrets ou des dépôts qui ne la concernent pas. Cette famille affecte les runners par niveau de confiance : jamais de runner auto-hébergé exposé à un dépôt public, pas de partage entre périmètres de confiance différents, une association des runners limitée aux seuls dépôts concernés (pas d'org-wide trop large), et un RBAC sur leur enregistrement et leur usage. C'est la gouvernance qui empêche qu'un runner devienne une passerelle entre deux mondes qui ne devraient pas se toucher.
Concrètement, ces exigences parent : le runner auto-hébergé exposé aux dépôts publics (exécution de PR hostiles), le partage de runners entre public et privé ou dev et prod, l'association org-wide trop large qui ouvre l'accès à des dépôts non concernés, et l'absence de RBAC sur l'enregistrement et l'usage des runners.
Mélanger public/privé ou dev/prod ouvre la porte aux PPE et pwn requests.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »les runners auto-hébergés ne sont JAMAIS utilisés avec des dépôts publics ni des workflows déclenchés par des forks non fiables.#
Un runner auto-hébergé branché sur un dépôt public exécute le code de n'importe quelle PR : une porte d'entrée massivement exploitée. L'exigence l'interdit pour les dépôts publics et les workflows déclenchés par des forks non fiables.
- Preuve attendue
- Vérification : aucun runner auto-hébergé sur dépôt public / workflow de fork non fiable.
- Outillage
- Cilium
Correspondances & menaces parées 3 standards · 4 menaces
Un workflow déclenché sur pull_request_target (ou équivalent) exécute le code d'un fork non fiable avec le contexte et les secrets du dépôt cible. Une simple pull request d'un inconnu obtient l'exécution privilégiée et les jetons du projet CICD-SEC-4. Poisoned Pipeline Execution directe : l'attaquant modifie la définition du pipeline (fichier de CI) pour y injecter des commandes exécutées avec les privilèges du build. Le contrôle du fichier de workflow donne le contrôle de l'exécution CICD-SEC-4. Un pipeline déclenché par une contribution publique exécute du code non fiable dans un contexte privilégié, exposant secrets et droits du projet. La surface vient de l'ouverture du pipeline aux contributions externes CICD-SEC-4. Un runner auto-hébergé non éphémère conserve un état entre jobs (fichiers, secrets, processus), permettant à un job compromis de piéger les suivants ou d'exfiltrer des données d'autres pipelines. La persistance du runner est l'angle mort CICD-SEC-7.
segmentation par tier de confiance via runner groups ; aucun partage public/privé ou dev/prod.#
Partager un pool de runners entre public et privé ou dev et prod laisse une charge non fiable côtoyer des secrets sensibles. Les runner groups segmentent par tier de confiance : aucun partage entre mondes de niveaux différents.
- Preuve attendue
- Configuration des runner groups par tier ; absence de partage public/privé, dev/prod.
- Outillage
- Cilium
Correspondances & menaces parées 4 standards · 1 menace
Poisoned Pipeline Execution directe : l'attaquant modifie la définition du pipeline (fichier de CI) pour y injecter des commandes exécutées avec les privilèges du build. Le contrôle du fichier de workflow donne le contrôle de l'exécution CICD-SEC-4.
affectation restreinte aux dépôts/workflows autorisés ; pas d'association org-wide par défaut.#
Un runner associé à toute l'organisation par défaut est accessible à des dépôts qui n'en ont pas besoin, élargissant la surface. L'exigence restreint l'affectation aux dépôts et workflows autorisés : pas d'association org-wide implicite.
- Preuve attendue
- Matrice d'affectation dépôts/workflows ; pas d'association org-wide par défaut.
- Outillage
- Cilium Plumber
Correspondances & menaces parées 2 standards · 2 menaces
Poisoned Pipeline Execution directe : l'attaquant modifie la définition du pipeline (fichier de CI) pour y injecter des commandes exécutées avec les privilèges du build. Le contrôle du fichier de workflow donne le contrôle de l'exécution CICD-SEC-4. Un pipeline déclenché par une contribution publique exécute du code non fiable dans un contexte privilégié, exposant secrets et droits du projet. La surface vient de l'ouverture du pipeline aux contributions externes CICD-SEC-4.
RBAC sur l'enregistrement et l'usage des runners ; séparation des privilèges de déploiement.#
Sans RBAC, n'importe qui peut enregistrer ou utiliser un runner, et le CI cumule les droits de déploiement. L'exigence impose un contrôle d'accès sur l'enregistrement et l'usage des runners, et une séparation des privilèges de déploiement.
- Preuve attendue
- Politique RBAC sur enregistrement/usage ; séparation des privilèges de déploiement.
- Outillage
- Cilium Plumber
Correspondances & menaces parées 3 standards · 2 menaces
Un runner auto-hébergé non éphémère conserve un état entre jobs (fichiers, secrets, processus), permettant à un job compromis de piéger les suivants ou d'exfiltrer des données d'autres pipelines. La persistance du runner est l'angle mort CICD-SEC-7. La plateforme d'orchestration CI/CD elle-même (serveur, contrôleur, base de secrets) est compromise, donnant le contrôle de tous les pipelines, secrets et déploiements. C'est le vecteur de plus haut impact : il rend caducs les contrôles en aval CNCF Publishing CICD-SEC-7.