Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Sécurité Gitblit
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Qu'est-ce que Gitblit
+
+Gitblit est un serveur Git auto-hébergé écrit en Java. Il peut fonctionner comme un JAR autonome ou dans des conteneurs de servlet et inclut un service SSH intégré (Apache MINA SSHD) pour Git over SSH.
+
+## Sujets
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Références
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Résumé
+
+CVE-2024-28080 est un contournement d'authentification dans le service SSH embarqué de Gitblit dû à une gestion incorrecte de l'état de session lors de l'intégration avec Apache MINA SSHD. Si un compte utilisateur a au moins une clé publique SSH enregistrée, un attaquant qui connaît le nom d'utilisateur et l'une des clés publiques de cet utilisateur peut s'authentifier sans la clé privée et sans le mot de passe.
+
+- Affectés : Gitblit < 1.10.0 (observé sur 1.9.3)
+- Corrigé : 1.10.0
+- Conditions requises pour l'exploitation :
+- Git over SSH activé sur l'instance
+- Le compte victime a au moins une clé publique SSH enregistrée dans Gitblit
+- L'attaquant connaît le nom d'utilisateur de la victime et l'une de ses clés publiques (souvent découvrable, par ex. https://github.com/<username>.keys)
+
+## Cause principale (state leaks between SSH methods)
+
+Dans le RFC 4252, l'authentification par clé publique se déroule en deux phases : le serveur vérifie d'abord si une clé publique fournie est acceptable pour un nom d'utilisateur, et ce n'est qu'après un challenge/response avec une signature qu'il authentifie l'utilisateur. Dans MINA SSHD, le PublickeyAuthenticator est invoqué deux fois : lors de l'acceptation de la clé (pas encore de signature) et plus tard après que le client renvoie une signature.
+
+Le PublickeyAuthenticator de Gitblit modifiait le contexte de session lors du premier appel pré‑signature en liant le UserModel authentifié à la session et en renvoyant true ("key acceptable"). Lorsque l'authentification revenait ensuite au mot de passe, le PasswordAuthenticator faisait confiance à cet état de session muté et court‑circuitait, renvoyant true sans valider le mot de passe. En conséquence, tout mot de passe (y compris vide) était accepté après une précédente "acceptance" par clé publique pour le même utilisateur.
+
+Flux général défaillant :
+
+1) Le client propose le nom d'utilisateur + la clé publique (pas encore de signature)  
+2) Le serveur reconnaît que la clé appartient à l'utilisateur et attache prématurément l'utilisateur à la session, renvoie true ("acceptable")  
+3) Le client ne peut pas signer (pas de clé privée), donc l'authentification bascule sur le mot de passe  
+4) L'authentification par mot de passe voit un utilisateur déjà présent dans la session et renvoie le succès sans condition
+
+## Exploitation pas à pas
+
+- Récupérer le nom d'utilisateur de la victime et l'une de ses clés publiques :
+- GitHub expose les clés publiques à https://github.com/<username>.keys
+- Les serveurs publics exposent souvent authorized_keys
+- Configurer OpenSSH pour ne présenter que la partie publique afin que la génération de signature échoue, forçant un repli sur le mot de passe tout en déclenchant néanmoins le chemin d'acceptation par clé publique sur le serveur.
+
+Exemple de configuration client SSH (pas de clé privée disponible) :
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Connectez-vous et appuyez sur Entrée à l'invite du mot de passe (ou tapez n'importe quelle chaîne) :
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+Remarque : Si ControlMaster multiplexing est activé dans votre SSH config, les commandes Git suivantes peuvent réutiliser la connexion authentifiée, augmentant l'impact.
+
+## Impact
+
+- Usurpation complète de n'importe quel utilisateur Gitblit disposant d'au moins une public key SSH enregistrée
+- Accès en lecture/écriture aux repositories selon les permissions de la victime (exfiltration de source, pushes non autorisés, risques pour la supply‑chain)
+- Impact administratif potentiel si l'on cible un admin user
+- Exploit purement réseau ; aucun brute force ni private key requis
+
+## Detection ideas
+
+- Examinez les logs SSH pour des séquences où une tentative publickey est suivie d'une authentification password réussie avec un mot de passe vide ou très court
+- Recherchez des flux : méthode publickey offrant du key material non supporté/non correspondant suivie d'un succès password immédiat pour le même username
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Until upgraded:
+- Disable Git over SSH on Gitblit, or
+- Restrict network access to the SSH service, and
+- Monitor for suspicious patterns described above
+- Rotate affected user credentials if compromise is suspected
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: Si l'authentificateur public‑key d'un serveur modifie l'état user/session durant la phase pré‑signature "key acceptable" et que d'autres authenticators (par ex., password) font confiance à cet état, vous pouvez bypass l'authentification en :
+
+- Présentant une public key légitime pour l'utilisateur cible (sans private key)
+- Forçant le client à échouer la signature pour que le serveur retombe sur password
+- Fournissant n'importe quel password pendant que le password authenticator court‑circuite sur l'état leak
+
+Practical tips:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
+- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS signifie **Système de Contrôle de Version**, 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 stands for **Version Control System**, ce système permet aux développeurs de **gérer leur source code**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur une des **platforms** suivantes :
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Fournisseurs de cloud (ils offrent leurs propres plateformes VCS)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## Pipelines CI/CD
 
-Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** à diverses fins, y compris la construction, les tests et le déploiement d'applications. Ces flux de travail automatisés sont **déclenchés par des actions spécifiques**, telles que des envois de code, des demandes de tirage ou des tâches planifiées. Ils sont utiles pour rationaliser le processus du développement à la production.
+## CI/CD Pipelines
 
-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**.
+Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** pour différents objectifs, notamment la construction, 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 vers la production.
 
-## Méthodologie de Pentesting VCS
+Cependant, ces systèmes doivent être **exécutés quelque part** et généralement avec des **identifiants privilégiés pour déployer le code ou accéder à des informations sensibles**.
+
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> 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.
+> 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 source code.
 
-Les plateformes contenant le code source de votre projet contiennent des informations sensibles et les gens doivent être très prudents avec les autorisations accordées à l'intérieur de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que les attaquants pourraient exploiter :
+Les platforms qui contiennent le source code de votre projet renferment des informations sensibles et il faut être très prudent avec les permissions accordées sur cette platform. Voici quelques problèmes courants sur les platforms VCS que des attaquants pourraient exploiter :
 
-- **Fuites** : Si votre code contient des fuites 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 fuites.
-- **Accès** : Si un attaquant peut **accéder à un compte à l'intérieur de la plateforme VCS**, il pourrait obtenir **plus de visibilité et d'autorisations**.
-- **Enregistrement** : Certaines plateformes ne permettront qu'aux utilisateurs externes de créer un compte.
-- **SSO** : Certaines plateformes ne permettront pas aux utilisateurs de s'inscrire, mais permettront à quiconque d'accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
-- **Identifiants** : Nom d'utilisateur + Mot de passe, jetons personnels, clés ssh, jetons Oauth, cookies... il existe plusieurs types de jetons 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 a également le secret.
-- **Compromission de code :** Si un acteur malveillant a un certain type d'accès **en écriture** sur les dépôts, il pourrait essayer d'**injecter du code malveillant**. Pour réussir, il pourrait avoir besoin de **contourner les protections de branche**. Ces actions peuvent être effectuées avec différents objectifs en tête :
-- Compromettre la branche principale pour **compromettre la production**.
-- Compromettre la 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 à l'intérieur du dépôt sur leurs machines).
-- **Compromettre le pipeline** (voir la 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 a accès), il pourrait découvrir ces leaks.
+- **Access** : Si un attaquant peut **accéder à un compte sur la platform VCS** il pourrait obtenir **plus de visibilité et de permissions**.
+- **Register** : Certaines platforms permettent simplement à des utilisateurs externes de créer un compte.
+- **SSO** : Certaines platforms n'autoriseront pas les enregistrements, mais permettront à quiconque d'accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
+- **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 platforms 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 third party platform
+- Si le secret est dans l'URL, il en va de même et l'attaquant possède aussi le secret
+- **Compromission du code :** Si un acteur malveillant a un certain type d'**accès en écriture** sur les repos, il pourrait tenter **d'injecter du code malveillant**. Pour réussir, il pourrait devoir **bypasser les branch protections**. Ces actions peuvent être réalisées dans différents objectifs :
+  - 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 autres choses dans le repo sur leurs machines).
+  - **Compromettre le pipeline** (voir section suivante)
 
-## Méthodologie de Pentesting des Pipelines
+## Pipelines Pentesting Methodology
 
-La manière 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 travaux exécutés, les conditions qui affectent le flux et les paramètres de l'environnement de construction.\
-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 des GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le travail du pipeline **tire le code** de la source sélectionnée (par exemple, commit / branche), 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 **CI configuration file hébergé dans le repository** 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 ont typiquement un nom et un format constants, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML de 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 (p.ex. commit / branch), et **exécute les commandes spécifiées dans le CI configuration file** contre ce code.
 
-Par conséquent, l'objectif ultime de l'attaquant est de **compromettre d'une manière ou d'une autre 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**.
 
-### PPE - Exécution de Pipeline Empoisonné
+### PPE - Poisoned Pipeline Execution
 
-Le chemin d'Exécution de Pipeline Empoisonné (PPE) exploite les autorisations dans un dépôt SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs ayant les autorisations nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le travail du pipeline pour inclure des commandes malveillantes. 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. Des utilisateurs disposant des permissions nécessaires peuvent modifier les CI configuration files ou d'autres fichiers utilisés par le job du pipeline pour inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, conduisant à l'exécution de ces commandes malveillantes.
 
-Pour qu'un acteur malveillant réussisse à effectuer 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 lorsqu'un envoi ou une demande de tirage est effectuée. (Consultez la méthodologie de pentesting VCS pour un résumé des moyens d'obtenir un accès).
-- Notez que parfois une **PR externe compte comme "accès en écriture"**.
-- Même s'il a des autorisations d'écriture, il doit s'assurer qu'il peut **modifier le fichier de configuration CI ou d'autres fichiers sur lesquels la configuration repose**.
-- Pour cela, il pourrait avoir besoin de **contourner les protections de branche**.
+- Avoir **un accès en écriture sur la platform VCS**, car généralement les pipelines sont déclenchés lorsqu'un push ou une pull request est effectué. (Consultez la VCS pentesting methodology pour un résumé des façons d'obtenir cet accès).
+- Notez que parfois un **PR externe compte comme un "accès en écriture"**.
+- Même s'il a des permissions d'écriture, il doit s'assurer qu'il peut **modifier le CI config file ou d'autres fichiers dont le config dépend**.
+- Pour cela, il pourrait devoir **contourner les branch protections**.
 
 Il existe 3 variantes de PPE :
 
-- **D-PPE** : Une attaque **D-PPE directe** se produit lorsque l'acteur **modifie le fichier de configuration CI** qui va être exécuté.
-- **I-DDE** : Une attaque **I-DDE indirecte** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le fichier de configuration CI qui va être exécuté **s'appuie** (comme un fichier make ou une configuration terraform).
-- **PPE Public ou 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n'ont pas d'accès en écriture dans le dépôt** (et qui pourraient même ne pas faire partie de l'organisation) car ils peuvent envoyer une PR.
-- **Injection de Commande 3PE** : En général, les pipelines CI/CD **définiront 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** (comme l'exécution de **commandes sh**), un attaquant pourrait **injecter des commandes là-dedans**.
+- **D-PPE** : Une attaque **Direct PPE** se produit lorsque l'acteur **modifie le CI config** file qui va être exécuté.
+- **I-DDE** : Une attaque **Indirect PPE** se produit lorsque l'acteur **modifie** un **fichier** sur lequel le CI config file qui va être exécuté **s'appuie** (comme un make file ou une configuration 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 dans le repo** (et qui peuvent ne pas faire partie de l'organisation) parce qu'ils peuvent envoyer un PR.
+- **3PE Command Injection** : D'habitude, les pipelines CI/CD vont **définir des variables d'environnement** avec **des informations sur le PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre du PR) et est **utilisée** dans un **endroit dangereux** (comme l'exécution de **sh commands**), un attaquant pourrait **y injecter des commandes**.
 
-### Avantages de l'Exploitation
+### Exploitation Benefits
 
 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 travaux (récupérer le code, le construire, le déployer...) et ces privilèges sont généralement **accordés dans des secrets**. Ces secrets sont généralement accessibles via **des variables d'environnement ou des fichiers à l'intérieur du système**. Par conséquent, un attaquant essaiera toujours d'exfiltrer autant de secrets que possible.
-- Selon la plateforme de pipeline, l'attaquant **pourrait avoir besoin de spécifier les secrets dans la configuration**. Cela signifie que si l'attaquant ne peut pas modifier le pipeline de configuration CI (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets que ce pipeline a**.
-- **Calcul** : Le code est exécuté quelque part, selon l'endroit où il est exécuté, un attaquant pourrait être en mesure de pivoter davantage.
+- **Secrets** : Comme mentionné précédemment, les pipelines requièrent 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 habituellement accessibles via des **env variables ou des fichiers dans le système**. Par conséquent, un attaquant tentera toujours d'exfiltrer autant de secrets que possible.
+- Selon la plateforme de pipeline, l'attaquant **pourrait devoir spécifier les secrets dans le config**. Cela signifie que si l'attaquant ne peut pas modifier la configuration du pipeline (**I-PPE** par exemple), il pourrait **seulement exfiltrer les secrets dont dispose ce pipeline**.
+- **Capacité de calcul** : Le code est exécuté quelque part ; selon l'endroit d'exécution, un attaquant pourrait être capable de pivoter plus loin.
 - **Sur site** : Si les pipelines sont exécutés sur site, 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 également **exfiltrer** des jetons de rôles IAM/comptes de service **pour obtenir un accès supplémentaire à l'intérieur du cloud**.
-- **Machines de plateforme** : Parfois, les travaux seront exécutés à l'intérieur des **machines de la plateforme des pipelines**, qui se trouvent généralement dans un cloud avec **aucun autre accès**.
-- **Sélectionnez-le :** Parfois, la **plateforme des pipelines aura configuré plusieurs machines** et si vous pouvez **modifier le fichier de configuration CI**, vous pouvez **indiquer où vous souhaitez exécuter le code malveillant**. Dans cette situation, un attaquant exécutera probablement un shell inversé sur chaque machine possible pour essayer de l'exploiter davantage.
-- **Compromettre la production** : Si vous êtes à l'intérieur du pipeline et que la version finale est construite et déployée à partir de celui-ci, vous pourriez **compromettre le code qui va finir par s'exécuter en production**.
+- **Cloud** : L'attaquant pourrait accéder **à d'autres machines dans le cloud** mais aussi pourrait **exfiltrer** des tokens d'IAM roles/service accounts **afin d'obtenir un accès additionnel dans le cloud**.
+- **Machines de la plateforme** : Parfois les jobs seront exécutés à l'intérieur des machines de la platform pipelines, qui sont généralement dans un cloud sans accès additionnel.
+- **Choisir la cible :** Parfois la **platform pipelines** aura configuré plusieurs machines et si vous pouvez **modifier le CI configuration file** vous pouvez **indiquer où vous voulez exécuter le code malveillant**. Dans cette situation, un attaquant exécutera 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 depuis celui-ci, vous pourriez **compromettre le code qui finira par tourner en production**.
 
-## Informations plus pertinentes
+## More relevant info
 
-### Outils & Benchmark CIS
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle pour la conformité en matière de sécurité basé sur un nouveau [**benchmark CIS Software Supply Chain**](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 de code jusqu'au temps de déploiement.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre stack de software supply chain pour la conformité de 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 temps du déploiement.
 
-### Top 10 des Risques de Sécurité CI/CD
+### Top 10 CI/CD Security Risk
 
-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/)
+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/)
 
-### Laboratoires
+### Labs
 
-- Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin que vous puissiez la configurer comme vous le souhaitez pour la tester.
-- Laboratoire Gitea + Jenkins : [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Sur chaque platform que vous pouvez exécuter localement vous trouverez comment le lancer localement afin de le configurer comme vous le souhaitez pour le tester
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Outils Automatiques
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse statique de code pour l'infrastructure-as-code.
 
-## Références
+## 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)
 
+
 {{#include ../banners/hacktricks-training.md}}