Les briques tierces du pipeline (actions, images) sont autant de code exécuté en confiance. Cette famille (I4, domaine Intégration) impose les actions/steps tiers épinglés par commit SHA depuis une liste autorisée, et les images CI épinglées par digest (jamais de tag mutable). L'incident tj-actions (2025) illustre le danger d'une action non épinglée.
Une action référencée par tag peut être réécrite par son mainteneur ou un
attaquant : l'épingler par commit SHA depuis une liste validée garantit que
le code tiers exécuté est exactement celui qu'on a revu, pas une version repoussée
après coup. De même, un tag mutable d'image (:latest) peut pointer demain
vers une image piégée : l'épinglage par digest (@sha256:) fige le socle
d'exécution du build. Et un job au jeton trop large ouvre tout le dépôt s'il
est compromis : permissions minimales et analyse statique des workflows
(zizmor) ferment ces angles d'attaque.
Concrètement, ces exigences parent : l'action CI réécrite par tag, le jeton trop large qui ouvre le dépôt si le job est compromis, l'injection via un workflow mal écrit, et l'outil détourné de la chaîne. Des fondamentales (R1) aux renforcées (R2).
Un workflow trop permissif ou injectable exfiltre des secrets (PPE, injection).
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 »permissions minimales des jobs CI (jeton scopé en lecture par défaut).#
Un job CI au jeton trop large offre, s'il est compromis, un accès en écriture à tout le dépôt et aux secrets. Des permissions minimales (lecture par défaut, écriture explicite au cas par cas) limitent ce qu'un job détourné peut faire : c'est le moindre privilège appliqué au pipeline (CICD-SEC-5).
- Preuve attendue
- Configuration des permissions de jobs CI (jeton en lecture par défaut).
- Outillage
- zizmor poutine
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. Pendant un job, l'attaquant lit en mémoire le jeton OIDC court ou les identifiants fédérés pour s'authentifier auprès de services en aval. L'éphémérité du jeton ne protège pas si le job lui-même est compromis CICD-SEC-6.
analyse statique des workflows CI (détection de schémas dangereux).#
Un workflow CI mal écrit (injection via titre de PR, pull_request_target risqué) est exploitable sans qu'on le voie à la relecture. L'analyse statique des workflows (zizmor, actionlint) détecte ces schémas dangereux automatiquement, avant qu'un attaquant ne les transforme en exécution de code dans votre CI.
- Preuve attendue
- Rapport d'analyse statique des workflows CI.
- Outillage
- zizmor poutine
Correspondances & menaces parées 2 standards · 1 menace
Une donnée contrôlée par l'attaquant (titre de PR, nom de branche, message de commit) est interpolée sans échappement dans un script de workflow, provoquant une exécution de commande dans le pipeline. C'est l'injection classique portée au CI CICD-SEC-4.