Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Méthodologie de Pentesting CI/CD
+# Méthodologie Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS signifie **système de gestion de versions**, ce système permet aux développeurs de **gérer leur code source**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur l'une des **plateformes** suivantes :
+VCS signifie **Version Control System**, ce système permet aux développeurs de **gérer leur code source**. Le plus courant est **git** et vous trouverez généralement des entreprises l’utilisant sur l’une des **plateformes** suivantes :
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (ils proposent leurs propres plateformes VCS)
 
 
 ## CI/CD Pipelines
 
-Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** pour divers usages, notamment la compilation, les tests et le déploiement des applications. Ces workflows automatisés sont **déclenchés par des actions spécifiques**, comme des pushes de code, des pull requests, ou des tâches planifiées. Ils servent à rationaliser le processus du développement à la production.
+Les CI/CD pipelines permettent aux développeurs d’**automatiser l’exécution du code** à diverses fins, notamment la compilation, les tests et le déploiement des applications. Ces workflows automatisés sont **déclenchés par des actions spécifiques**, telles que des pushs de code, des pull requests ou des tâches planifiées. Ils sont utiles pour simplifier le processus du développement à la production.
 
 Cependant, ces systèmes doivent être **exécutés quelque part** et généralement avec des **identifiants privilégiés pour déployer du code ou accéder à des informations sensibles**.
 
-## Méthodologie de Pentesting VCS
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Même si certaines plateformes VCS permettent de créer des pipelines, pour cette section nous allons analyser uniquement les attaques potentielles visant le contrôle du code source.
+> Même si certaines plateformes VCS permettent de créer des pipelines, dans cette section nous allons analyser uniquement les attaques potentielles sur le contrôle du code source.
 
-Les plateformes qui contiennent le code source de votre projet hébergent des informations sensibles et il faut être très prudent quant aux permissions accordées au sein de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que des attaquants pourraient exploiter :
+Les plateformes qui contiennent le code source de votre projet contiennent des informations sensibles et les personnes doivent être très prudentes avec les permissions accordées dans cette plateforme. Voici quelques problèmes courants sur les plateformes VCS qu’un attaquant pourrait exploiter :
 
-- **Leaks** : Si votre code contient des leaks dans les commits et que l'attaquant peut accéder au dépôt (parce qu'il est public ou parce qu'il a accès), il pourrait découvrir les leaks.
-- **Access** : Si un attaquant peut **accéder à un compte au sein de la plateforme VCS** il pourrait obtenir **plus de visibilité et de permissions**.
-- **Inscription** : Certaines plateformes permettent simplement aux utilisateurs externes de créer un compte.
-- **SSO** : Certaines plateformes n'autorisent pas l'inscription, mais permettent à quiconque de se connecter avec un SSO valide (donc un attaquant pourrait utiliser par exemple son compte github pour entrer).
-- **Credentials** : Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... il existe plusieurs types de tokens qu'un utilisateur pourrait voler pour accéder d'une manière ou d'une autre à un dépôt.
-- **Webhooks** : Les plateformes VCS permettent de générer des webhooks. S'ils ne sont **pas protégés** par des secrets non visibles, un **attaquant pourrait en abuser**.
-- Si aucun secret n'est en place, l'attaquant pourrait abuser du webhook de la plateforme tierce.
-- Si le secret est dans l'URL, il en va de même et l'attaquant possède aussi le secret.
-- **Code compromise :** Si un acteur malveillant dispose d'une forme d'accès en **écriture** sur les dépôts, il pourrait tenter d'**injecter du code malveillant**. Pour réussir, il pourrait devoir **contourner les protections de branche**. Ces actions peuvent être réalisées avec différents objectifs en tête :
-  - Compromettre la branche principale pour **compromettre la production**.
-  - Compromettre la branche principale (ou d'autres branches) pour **compromettre les machines des développeurs** (car ils exécutent souvent des tests, terraform ou d'autres choses depuis le dépôt sur leurs machines).
-  - **Compromettre le pipeline** (voir section suivante)
+- **Leaks** : Si votre code contient des leaks dans les commits et que l’attaquant peut accéder au repo (parce qu’il est public ou parce qu’il y a accès), il pourrait découvrir les leaks.
+- **Access** : Si un attaquant peut **accéder à un compte au sein de la plateforme VCS**, il pourrait obtenir **plus de visibilité et de permissions**.
+- **Register** : Certaines plateformes permettent simplement aux utilisateurs externes de créer un compte.
+- **SSO** : Certaines plateformes ne permettront pas aux utilisateurs de s’enregistrer, mais permettront à n’importe qui d’accéder avec un SSO valide (donc un attaquant pourrait par exemple utiliser son compte github pour entrer).
+- **Credentials** : Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... il existe plusieurs types de tokens qu’un utilisateur pourrait voler pour accéder d’une manière ou d’une autre à un repo.
+- **Webhooks** : Les plateformes VCS permettent de générer des webhooks. S’ils ne sont **pas protégés** par des secrets invisibles, un **attaquant pourrait les exploiter**.
+- Si aucun secret n’est en place, l’attaquant pourrait exploiter le webhook de la plateforme tierce
+- Si le secret est dans l’URL, la même chose se produit et l’attaquant a aussi le secret
+- **Code compromise:** Si un acteur malveillant dispose d’un certain type d’accès **write** sur les repos, il pourrait essayer d’**injecter du code malveillant**. Pour réussir, il pourrait avoir besoin de **bypasser les branch protections**. Ces actions peuvent être réalisées avec différents objectifs en tête :
+- Compromettre la branche principale pour **compromettre la production**.
+- Compromettre la branche principale (ou d’autres branches) pour **compromettre les machines des développeurs** (car ils exécutent généralement des tests, terraform ou d’autres choses dans le repo sur leurs machines).
+- **Compromise the pipeline** (check next section)
 
 ## Pipelines Pentesting Methodology
 
-La façon la plus courante de définir un pipeline est d'utiliser un **fichier de configuration CI hébergé dans le dépôt** que le pipeline construit. Ce fichier décrit l'ordre des jobs exécutés, les conditions qui affectent le flux, et les paramètres de l'environnement de build.\
-Ces fichiers portent généralement un nom et un format constants, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le job du pipeline **récupère le code** depuis la source sélectionnée (par ex. commit / branch), et **exécute les commandes spécifiées dans le fichier de configuration CI** contre ce code.
+La façon la plus courante de définir un pipeline est d’utiliser un **fichier de configuration CI hébergé dans le repository** que le pipeline compile. Ce fichier décrit l’ordre des jobs exécutés, les conditions qui affectent le flux, ainsi que les paramètres de l’environnement de build.\
+Ces fichiers ont généralement un nom et un format cohérents, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML GitHub Actions situés sous .github/workflows. Lorsqu’il est déclenché, le job du pipeline **récupère le code** depuis la source sélectionnée (par ex. commit / branch), et **exécute les commandes spécifiées dans le fichier de configuration CI** sur ce code.
 
-Ainsi, l'objectif ultime de l'attaquant est en quelque sorte de **compro­mettre ces fichiers de configuration** ou les **commandes qu'ils exécutent**.
+Par conséquent, l’objectif ultime de l’attaquant est d’une manière ou d’une autre de **compromettre ces fichiers de configuration** ou les **commandes qu’ils exécutent**.
 
 > [!TIP]
-> Certains builders hébergés laissent les contributeurs choisir le Docker build context et le chemin du Dockerfile. Si le context est contrôlé par l'attaquant, vous pouvez le définir en dehors du repo (par exemple "..") pour ingérer des fichiers de l'hôte pendant le build et exfiltrer des secrets. Voir :
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ Ainsi, l'objectif ultime de l'attaquant est en quelque sorte de **compro­mettre
 
 ### PPE - Poisoned Pipeline Execution
 
-La Poisoned Pipeline Execution (PPE) exploite des permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes malveillantes. Les utilisateurs disposant des permissions nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le job du pipeline pour y inclure des commandes malicieuses. Cela « empoisonne » le pipeline CI, entraînant l'exécution de ces commandes malveillantes.
+Le chemin Poisoned Pipeline Execution (PPE) exploite les permissions dans un repository SCM pour manipuler un pipeline CI et exécuter des commandes malveillantes. Les utilisateurs disposant des permissions nécessaires peuvent modifier les fichiers de configuration CI ou d’autres fichiers utilisés par le job du pipeline pour inclure des commandes malveillantes. Cela "poisonne" le pipeline CI, ce qui conduit à l’exécution de ces commandes malveillantes.
 
-Pour qu'un acteur malveillant réussisse une attaque PPE, il doit être capable de :
+Pour qu’un acteur malveillant réussisse une attaque PPE, il doit être capable de :
 
-- Avoir **un accès en écriture à la plateforme VCS**, car généralement les pipelines sont déclenchés lors d'un push ou d'une pull request. (Voir la méthodologie VCS pour un résumé des moyens d'obtenir un accès).
-- Noter que parfois une **PR externe compte comme un "accès en écriture"**.
-- Même s'il dispose de permissions en écriture, il doit s'assurer qu'il peut **modifier le fichier de config CI ou d'autres fichiers sur lesquels le config s'appuie**.
-- Pour cela, il pourrait devoir être capable de **contourner les protections de branche**.
+- Avoir un **write access à la plateforme VCS**, car généralement les pipelines sont déclenchés lors d’un push ou d’une pull request. (Consultez la méthodologie pentesting VCS pour un résumé des moyens d’obtenir l’accès).
+- Notez que parfois une **external PR count as "write access"**.
+- Même s’il a des permissions d’écriture, il doit s’assurer qu’il peut **modifier le fichier de config CI ou d’autres fichiers sur lesquels la config s’appuie**.
+- Pour cela, il pourrait devoir être capable de **bypasser les branch protections**.
 
 Il existe 3 variantes de PPE :
 
-- **D-PPE** : Une attaque **Direct PPE** se produit lorsque l'acteur **modifie le fichier de config CI** qui va être exécuté.
-- **I-DDE** : Une attaque **Indirect PPE** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le fichier de config CI qui va être exécuté **se repose** (comme un makefile ou une config terraform).
-- **Public PPE or 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n'ont pas d'accès en écriture au dépôt** (et qui peuvent même ne pas faire partie de l'organisation) parce qu'ils peuvent envoyer une PR.
-- **3PE Command Injection** : Habituellement, les pipelines CI/CD vont **définir des variables d'environnement** avec **des informations sur la PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre de la PR) et est **utilisée** dans un **endroit dangereux** (par exemple pour exécuter des commandes sh), un attaquant peut **injecter des commandes**.
+- **D-PPE** : Une attaque **Direct PPE** se produit lorsque l’acteur **modifie** le fichier de config CI qui va être exécuté.
+- **I-DDE** : Une attaque **Indirect PPE** se produit lorsque l’acteur **modifie** un **fichier** sur lequel le fichier de config CI qui va être exécuté **s’appuie** (comme un make file ou une config terraform).
+- **Public PPE or 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n’ont pas de write access dans le repo** (et qui ne font peut-être même pas partie de l’org) parce qu’ils peuvent envoyer une PR.
+- **3PE Command Injection** : En général, les CI/CD pipelines vont **définir des variables d’environnement** avec des **informations sur la PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre de la PR) et qu’elle est **utilisée** à un **endroit dangereux** (comme l’exécution de **sh commands**), un attaquant pourrait **y injecter des commandes**.
 
 ### Exploitation Benefits
 
-Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant peut obtenir après une exploitation réussie :
+Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu’un attaquant pourrait obtenir après une exploitation réussie :
 
-- **Secrets** : Comme mentionné précédemment, les pipelines nécessitent des **privilèges** pour leurs jobs (récupérer le code, le builder, le déployer...) et ces privilèges sont généralement **fourni via des secrets**. Ces secrets sont souvent accessibles via des **env variables ou des fichiers à l'intérieur du système**. Par conséquent, un attaquant cherchera toujours à exfiltrer autant de secrets que possible.
-- Selon la plateforme de pipeline, l'attaquant **pourrait devoir spécifier les secrets dans la config**. Cela signifie que si l'attaquant ne peut pas modifier la configuration du pipeline (**I-PPE** par exemple), il pourrait **ne pouvoir exfiltrer que les secrets que ce pipeline possède**.
-- **Computation** : Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant peut être en mesure de pivoter plus loin.
-- **On-Premises** : Si les pipelines s'exécutent on-premises, un attaquant pourrait se retrouver dans un **réseau interne avec accès à plus de ressources**.
-- **Cloud** : L'attaquant pourrait accéder à **d'autres machines dans le cloud** mais aussi pourrait **exfiltrer** des tokens de rôles IAM / service accounts pour obtenir **un accès plus large dans le cloud**.
-- **Machines de la plateforme** : Parfois les jobs seront exécutés à l'intérieur des **machines de la plateforme de pipelines**, qui sont généralement dans un cloud sans accès supplémentaire.
-- **Sélectionner la cible :** Parfois la **plateforme de pipelines proposera plusieurs machines** et si vous pouvez **modifier le fichier de config CI** vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans ce cas, un attaquant lancera probablement un reverse shell sur chaque machine possible pour tenter de l'exploiter davantage.
-- **Compromettre la production** : Si vous êtes à l'intérieur du pipeline et que la version finale est buildée et déployée à partir de celui-ci, vous pourriez **compromettre le code qui sera exécuté en production**.
+- **Secrets** : Comme mentionné précédemment, les pipelines nécessitent des **privilèges** pour leurs jobs (récupérer le code, le compiler, le déployer...) et ces privilèges sont généralement **accordés via des secrets**. Ces secrets sont généralement accessibles via des **env variables ou des fichiers dans le système**. Par conséquent, un attaquant essaiera toujours d’exfiltrer autant de secrets que possible.
+- Selon la plateforme du pipeline, l’attaquant **pourrait devoir spécifier les secrets dans la config**. Cela signifie que si l’attaquant ne peut pas modifier le pipeline de configuration CI (**I-PPE** par exemple), il pourrait **uniquement exfiltrer les secrets que ce pipeline possède**.
+- **Computation** : Le code est exécuté quelque part, selon l’endroit où il est exécuté, un attaquant pourrait être capable de pivoter davantage.
+- **On-Premises** : Si les pipelines sont exécutés on premises, un attaquant pourrait se retrouver dans un **réseau interne avec accès à plus de ressources**.
+- **Cloud** : L’attaquant pourrait accéder à **d’autres machines dans le cloud** mais pourrait aussi **exfiltrer** les **tokens** des rôles IAM/service accounts pour obtenir **un accès supplémentaire dans le cloud**.
+- **Platforms machine** : Parfois, les jobs seront exécutés à l’intérieur des **machines de la plateforme de pipelines**, qui sont généralement dans un cloud avec **pas plus d’accès**.
+- **Select it:** Parfois, la **plateforme de pipelines aura configuré plusieurs machines** et si vous pouvez **modifier le fichier de configuration CI**, vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans cette situation, un attaquant lancera probablement un reverse shell sur chaque machine possible pour essayer d’aller plus loin.
+- **Compromise production** : Si vous étiez dans le pipeline et que la version finale est compilée et déployée depuis celui-ci, vous pourriez **compromettre le code qui va finir par s’exécuter en production**.
+
+### Dependency & Registry Supply-Chain Abuse
+
+Compromettre un CI/CD pipeline ou y voler des identifiants peut permettre à un attaquant de passer de **pipeline execution** à **ecosystem-wide code execution** en backdoorant des dépendances ou des outils de release :
+
+- **Install-time code execution via package hooks** : publier une version de package qui ajoute des hooks `preinstall`, `postinstall`, `prepare`, ou similaires afin que le payload s’exécute automatiquement sur les postes des développeurs et les runners CI pendant l’installation des dépendances.
+- **Secondary execution paths** : même si les cibles installent avec `--ignore-scripts`, un package malveillant peut toujours enregistrer un **common CLI name** dans le champ `bin` afin que le wrapper contrôlé par l’attaquant soit symlinked dans `PATH` et s’exécute plus tard lorsque la commande est utilisée.
+- **Runtime bootstrapping** : un petit installer peut télécharger un second runtime ou toolchain pendant l’installation (par exemple Bun ou un interpreter packé) puis lancer avec lui le payload principal, en évitant les dépendances locales requises.
+- **Credential harvesting from build environments** : une fois que du code s’exécute dans CI, vérifiez les variables d’environnement, `~/.npmrc`, `~/.git-credentials`, les clés SSH, les configs de cloud CLI, et les outils locaux tels que `gh auth token`. Sur GitHub Actions, cherchez aussi les secrets et artifacts spécifiques au runner.
+- **Workflow injection with stolen GitHub tokens** : un token avec les permissions **`repo` + `workflow`** suffit pour créer une branch, committer un fichier malveillant dans `.github/workflows/`, le déclencher, collecter les artifacts/logs produits, puis supprimer la branch temporaire/l’exécution du workflow pour réduire les traces.
+- **Wormable registry propagation** : les tokens npm volés doivent être validés pour les permissions **publish** et pour savoir s’ils contournent la 2FA. Si c’est le cas, énumérez les packages inscriptibles, téléchargez leurs tarballs, injectez un loader tel que `setup.mjs`, définissez `preinstall` pour l’exécuter, augmentez la version patch, puis republiez. Cela transforme une compromission CI en auto-exécution en aval dans d’autres environnements.
+
+#### Practical checks during an assessment
+
+- Passez en revue l’automatisation de release pour détecter les hooks du package manager ajoutés à `package.json`, les entrées `bin` inattendues, ou les changements de version qui ne modifient que l’artefact de release.
+- Vérifiez si CI stocke des identifiants de registry longue durée en clair dans des fichiers comme `~/.npmrc` au lieu d’utiliser OIDC à durée de vie courte ou trusted publishing.
+- Vérifiez si les tokens GitHub disponibles dans CI peuvent écrire des fichiers de workflow ou créer des branches/tags.
+- Si un package compromis est suspecté, inspectez le tarball publié et pas seulement le Git repository, car le loader/runtime malveillant peut n’exister que dans l’artefact publié.
+- Cherchez une exécution inattendue du package manager dans CI, par exemple `npm install` au lieu de `npm ci`, des téléchargements/exécutions Bun inattendus, ou de nouveaux artifacts de workflow générés à partir de branches transitoires.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre stack de software supply chain en matière de conformité sécurité, basé sur un nouveau [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques depuis le temps du code jusqu'au déploiement.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer la sécurité de votre software supply chain stack en fonction d’un nouveau [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L’audit se concentre sur l’ensemble du processus SDLC, où il peut révéler des risques du code time au deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Consultez cet article intéressant sur les top 10 risques CI/CD selon Cider : [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Consultez cet article intéressant sur les 10 principaux risques CI/CD selon Cider : [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer en local afin de la configurer comme vous le souhaitez pour la tester
+- Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin de pouvoir la configurer comme vous voulez pour la tester
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** est un outil d'analyse statique pour infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** est un outil d’analyse statique de code pour l’infrastructure-as-code.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}