Confusion de Dépendances et Empoisonnement d’Artefacts : Techniques d’Attaque et Défenses

Introduction

Les attaques contre la chaîne d’approvisionnement logicielle ont connu une augmentation considérable, tant en fréquence qu’en sophistication, au cours des dernières années. Plutôt que d’attaquer directement les applications, les adversaires ciblent de plus en plus les couches de résolution de dépendances et de distribution d’artefacts qui sous-tendent le développement logiciel moderne. Deux des techniques les plus efficaces dans cette catégorie sont la dependency confusion (confusion de dépendances) et l’artifact poisoning (empoisonnement d’artefacts).

Ces attaques exploitent une vérité fondamentale : les logiciels modernes sont assemblés, et non écrits à partir de zéro. Une application typique peut intégrer des centaines, voire des milliers de packages tiers, d’images de conteneurs, de templates CI et de plugins de build — chacun représentant un maillon d’une chaîne de confiance. Lorsqu’un seul maillon est compromis, c’est toute la chaîne qui s’effondre.

Ce qui rend ces attaques particulièrement dangereuses, c’est que de nombreuses organisations restent vulnérables malgré des programmes de sécurité matures. Les tests de sécurité applicatifs traditionnels ne détectent pas une dépendance malveillante installée lors du build. Les firewalls et les WAF sont sans effet lorsque le code de l’attaquant s’exécute à l’intérieur de votre pipeline CI/CD avec un accès réseau complet et des identifiants de production.

Ce guide fournit un examen approfondi du fonctionnement de la dependency confusion et de l’artifact poisoning, explique pourquoi les pipelines CI/CD sont des cibles privilégiées et — surtout — quelles défenses pratiques vous pouvez mettre en œuvre dès aujourd’hui.

La Dependency Confusion expliquée

Comment les gestionnaires de packages résolvent les noms

La plupart des gestionnaires de packages modernes — npm, pip, RubyGems, NuGet, Maven — suivent un processus de résolution qui consulte un ou plusieurs registres lorsqu’un package est demandé. Lorsqu’une organisation utilise à la fois un registre privé/interne (pour les packages propriétaires) et le registre public (pour les packages open source), le gestionnaire de packages doit décider quel registre a la priorité lorsque les deux contiennent un package portant le même nom.

Le comportement par défaut varie selon l’écosystème, mais un schéma courant est préoccupant : de nombreux gestionnaires de packages préfèrent le numéro de version le plus élevé, quel que soit le registre d’origine. Ce choix de conception apparemment anodin constitue le fondement de l’attaque par dependency confusion.

La recherche originale : Alex Birsan (2021)

En février 2021, le chercheur en sécurité Alex Birsan a publié une recherche révolutionnaire démontrant comment ce comportement de résolution pouvait être utilisé comme arme. En examinant des noms de packages internes ayant fuité publiquement auprès d’entreprises comme Apple, Microsoft et Tesla — trouvés dans des fichiers JavaScript, des manifestes de packages et des messages d’erreur — il a enregistré des packages portant des noms identiques sur les registres publics npm, PyPI et RubyGems, avec des numéros de version artificiellement gonflés.

Le résultat fut dévastateur. Lorsque les systèmes de build de ces entreprises résolvaient les dépendances, les gestionnaires de packages récupéraient les packages publics de Birsan au lieu des packages internes légitimes. Ses packages de preuve de concept incluaient des callbacks bénins qui transmettaient des informations, confirmant l’exécution de code à l’intérieur des réseaux d’entreprise. Birsan a gagné plus de 130 000 $ en primes de bug bounty auprès de plusieurs organisations.

Les mécanismes de l’attaque

L’attaque par dependency confusion suit une séquence simple :

1. Reconnaissance : L’attaquant identifie les noms de packages internes/privés utilisés par l’organisation cible. Ceux-ci peuvent être trouvés dans des fichiers package.json ayant fuité, des source maps JavaScript, des messages d’erreur, des offres d’emploi ou des dépôts open source qui référencent des dépendances internes.
2. Enregistrement : L’attaquant enregistre un package portant un nom identique sur le registre public correspondant (npm, PyPI, etc.), en lui attribuant un numéro de version très élevé (par exemple, 99.0.0).
3. Charge utile : Le package public contient du code malveillant dans des scripts d’installation ou des hooks post-installation — du code qui s’exécute automatiquement lors de l’installation du package.
4. Exécution : Lorsque le système de build de l’organisation cible exécute npm install, pip install ou une commande équivalente, le gestionnaire de packages résout la dépendance vers le package public de l’attaquant en raison du numéro de version plus élevé.
5. Compromission : Le script d’installation malveillant s’exécute avec les privilèges du processus de build, obtenant généralement l’accès aux variables d’environnement (y compris les secrets), aux ressources réseau et au code source.

Écosystèmes affectés

La dependency confusion ne se limite pas à un seul langage ou écosystème. Les écosystèmes suivants sont tous vulnérables :

• npm (Node.js) : Le comportement par défaut peut favoriser les packages publics par rapport aux packages privés lorsque le scoping n’est pas utilisé.
• PyPI (Python) : Le flag --extra-index-url de pip vérifie à la fois les index privé et public, en préférant la version la plus élevée.
• RubyGems (Ruby) : Comportement de résolution similaire lorsque plusieurs sources sont configurées.
• NuGet (.NET) : Vérifie plusieurs flux configurés et peut favoriser la galerie publique.
• Maven (Java) : Résout à partir de plusieurs dépôts ; les attaquants peuvent publier sur Maven Central avec des identifiants group/artifact correspondants.

Les scripts d’installation comme vecteur de charge utile

La raison pour laquelle la dependency confusion est si dangereuse est que les gestionnaires de packages prennent en charge l’exécution automatique de code lors de l’installation. Dans npm, cela se produit via les scripts preinstall, install et postinstall définis dans package.json. En Python, setup.py peut exécuter du code arbitraire pendant pip install. Ces hooks ont été conçus pour des tâches de build légitimes, mais fournissent aux attaquants un vecteur d’exécution idéal — le code s’exécute avant même que l’application ne soit construite, souvent avec des privilèges élevés.

Artifact Poisoning : au-delà des packages

Alors que la dependency confusion cible spécifiquement les registres de packages, l’artifact poisoning est une catégorie plus large d’attaques sur la chaîne d’approvisionnement qui peut cibler tout artefact externe consommé durant le cycle de vie du développement logiciel. La surface d’attaque s’étend bien au-delà des gestionnaires de packages.

Images de base de conteneurs compromises

Les images de conteneurs extraites de Docker Hub ou d’autres registres publics sont un vecteur d’attaque courant. Un attaquant peut publier une image malveillante avec un nom similaire à une image de base populaire, ou compromettre une image existante en accédant au compte du mainteneur. Si votre Dockerfile spécifie FROM python:3.11 en utilisant un tag mutable, une image compromise poussée vers ce tag sera intégrée dans chaque build ultérieur.

Templates CI/CD altérés

Les templates GitHub Actions et GitLab CI référencés depuis des dépôts publics représentent une autre surface d’attaque significative. Lorsqu’un workflow référence uses: some-org/some-action@main, le code exécuté dans votre pipeline est contrôlé par quiconque possède un accès en écriture à ce dépôt. Si le dépôt de l’action est compromis, chaque pipeline qui le référence devient également compromis.

Typosquatting

Les attaques par typosquatting exploitent les fautes d’orthographe courantes et les similarités visuelles dans les noms de packages. Par exemple, enregistrer co1ors (avec le chiffre un) au lieu de colors, lodahs au lieu de lodash, ou reqeusts au lieu de requests. Ces packages contiennent du code malveillant et comptent sur les erreurs typographiques des développeurs lors de l’ajout de dépendances. Des outils automatisés ont détecté des milliers de packages de typosquatting sur npm et PyPI.

Comptes de mainteneurs piratés

Lorsqu’un attaquant accède au compte d’un mainteneur de package légitime — par le biais de credential stuffing, de phishing ou d’ingénierie sociale — il peut publier des versions contenant des portes dérobées de packages largement utilisés. Comme le nom du package et le mainteneur sont légitimes, ces versions compromises sont extrêmement difficiles à détecter par des moyens automatisés.

Plugins d’outils de build

Les systèmes de build comme Gradle, Maven et webpack prennent en charge des plugins qui s’exécutent pendant le processus de build. Des plugins malveillants ou compromis dans ces écosystèmes peuvent modifier les résultats du build, exfiltrer des secrets ou injecter des portes dérobées dans les artefacts compilés. Comme les plugins de build sont souvent moins scrutés que les dépendances applicatives, ils représentent une cible à haute valeur.

Incidents réels

Plusieurs incidents majeurs illustrent l’impact réel de l’artifact poisoning :

• event-stream (2018) : Un nouveau mainteneur a obtenu les droits de publication sur le package npm populaire event-stream (1,5 million de téléchargements hebdomadaires). Il a ajouté une dépendance vers un package malveillant, flatmap-stream, qui contenait du code chiffré ciblant le portefeuille Bitcoin Copay, tentant de voler des cryptomonnaies.
• ua-parser-js (2021) : Le package npm ua-parser-js (7 millions de téléchargements hebdomadaires) a été détourné lorsque le compte du mainteneur a été compromis. Des versions malveillantes ont été publiées, installant des cryptomineurs et des malwares de vol d’identifiants sur les systèmes Linux et Windows.
• node-ipc (2022) : Le mainteneur du package node-ipc a délibérément ajouté du code qui effaçait les fichiers sur les systèmes ayant des adresses IP russes ou biélorusses, démontrant que même des mainteneurs de confiance peuvent devenir un vecteur de menace (parfois appelé « protestware »).

Comment ces attaques exploitent le CI/CD

Les pipelines CI/CD sont particulièrement vulnérables à la dependency confusion et à l’artifact poisoning en raison de leur mode de fonctionnement. Comprendre pourquoi les pipelines sont des cibles privilégiées est essentiel pour construire des défenses efficaces.

Exécution automatique de code pendant les builds

Chaque fois qu’un pipeline CI exécute npm install, pip install -r requirements.txt ou docker build, il exécute du code provenant de sources externes. Cela se produit automatiquement à chaque commit, pull request ou build planifié. Il n’y a aucun humain dans la boucle pour vérifier quel code est réellement récupéré et exécuté.

Les environnements de build ont accès aux identifiants

Les environnements CI/CD sont généralement configurés avec les secrets nécessaires au déploiement : identifiants de fournisseurs cloud, tokens API, mots de passe de bases de données, clés de signature et identifiants de registre. Une dépendance malveillante qui s’exécute pendant la phase de build peut accéder à ces secrets via les variables d’environnement ou les magasins de secrets montés. Cela fait des pipelines CI/CD des cibles bien plus précieuses que les ordinateurs portables des développeurs.

Les dépendances récupérées au moment du build ne sont pas pré-auditées

Dans la plupart des organisations, les versions de dépendances sont spécifiées dans des fichiers manifestes (package.json, requirements.txt) mais le code réel est récupéré à neuf depuis les registres au moment du build. Entre le moment où un développeur ajoute une dépendance et celui où le système CI l’installe, le contenu du package peut changer — ou un package de dependency confusion peut apparaître sur le registre public. Il n’y a généralement aucune étape de vérification entre la résolution et l’exécution.

Les dépendances transitives élargissent la surface d’attaque

Votre application peut déclarer 50 dépendances directes, mais ces dépendances ont leurs propres dépendances, créant un arbre qui peut inclure des milliers de packages transitifs. Vous n’avez aucun contrôle direct sur les dépendances de vos dépendances. Lorsqu’une dépendance transitive est compromise — comme dans l’incident event-stream — l’attaque se propage à travers tout l’arbre de dépendances sans aucune modification de vos propres fichiers manifestes.

Se défendre contre la Dependency Confusion

Prévenir la dependency confusion nécessite de configurer vos gestionnaires de packages et vos registres pour éliminer l’ambiguïté entre les packages publics et privés. Voici les mesures d’atténuation les plus efficaces.

Nommez et scopez vos packages privés

La défense la plus efficace consiste à utiliser des noms de packages avec namespace ou scope pour tous les packages internes. Dans npm, cela signifie utiliser des packages scopés comme @yourcompany/package-name. Un attaquant ne peut pas enregistrer de packages sous le scope de votre organisation sur le registre public npm.

Configurez explicitement la priorité des registres

Ne vous fiez jamais au comportement de résolution par défaut. Configurez explicitement votre gestionnaire de packages pour récupérer les packages scopés depuis votre registre privé et tout le reste depuis le registre public.

Exemple de configuration .npmrc :

# Always fetch @yourcompany scoped packages from private registry
@yourcompany:registry=https://npm.yourcompany.com/

# All other packages come from the public npm registry
registry=https://registry.npmjs.org/

# Authentication for private registry
//npm.yourcompany.com/:_authToken=${NPM_PRIVATE_TOKEN}

Exemple pip.conf pour Python :

# IMPORTANT: Use --index-url (NOT --extra-index-url) for your private registry
# --extra-index-url checks BOTH registries and picks the higher version (vulnerable!)
# --index-url uses ONLY your private registry as the primary source

[global]
index-url = https://pypi.yourcompany.com/simple/

# If you need public PyPI packages, configure your private registry
# (Artifactory, Nexus) to proxy public PyPI — do NOT use --extra-index-url

Exemple .yarnrc.yml pour Yarn Berry :

npmScopes:
  yourcompany:
    npmRegistryServer: "https://npm.yourcompany.com"
    npmAuthToken: "${NPM_PRIVATE_TOKEN}"

npmRegistryServer: "https://registry.yarnpkg.com"

Utilisez des proxys de registres privés

Déployez un proxy de registre tel que JFrog Artifactory, Sonatype Nexus ou GitHub Packages qui s’interpose entre vos systèmes de build et les registres publics. Configurez le proxy pour :

• Servir les packages internes depuis votre dépôt privé.
• Faire le proxy des packages publics depuis le registre en amont.
• Bloquer tout package public qui partage un nom avec un package interne.
• Appliquer des politiques de sécurité (analyse de vulnérabilités, conformité des licences) avant d’autoriser le passage des packages.

Cela crée une source unique de vérité pour toutes les dépendances et élimine entièrement l’ambiguïté public/privé.

Enregistrement défensif

Enregistrez vos noms de packages internes sur les registres publics en tant que packages de remplacement. Ces packages ne doivent contenir aucun code réel — juste un README expliquant que le nom est réservé. Cela empêche les attaquants de revendiquer ces noms. Bien qu’il ne s’agisse pas d’une défense principale, cela ajoute une couche de protection supplémentaire.

Épinglez les dépendances par hash

L’épinglage des dépendances par hash cryptographique garantit que l’artefact exact que vous avez audité est bien celui installé pendant les builds. Même si un attaquant publie une version malveillante, le hash ne correspondra pas et l’installation échouera.

Pour pip (Python) :

# Generate hashes for your requirements
pip-compile --generate-hashes requirements.in -o requirements.txt

# Install with hash verification
pip install --require-hashes -r requirements.txt

Pour npm :

npm enregistre automatiquement les hashes d’intégrité dans package-lock.json. Assurez-vous de commiter le fichier de verrouillage et d’utiliser npm ci (et non npm install) en CI pour appliquer la vérification d’intégrité :

# In CI, always use npm ci — it strictly follows the lockfile
# and verifies integrity hashes for every package
npm ci

Se défendre contre l’Artifact Poisoning

Parce que l’artifact poisoning englobe un éventail plus large de vecteurs d’attaque, la défense nécessite des contrôles en couches sur les images de conteneurs, les templates CI, les dépendances et les processus de build.

Épinglez les images de conteneurs par digest

Ne référencez jamais les images de conteneurs par des tags mutables comme latest ou même 3.11. Épinglez plutôt au digest SHA256 immuable :

# Vulnerable: tag can be overwritten with a compromised image
FROM python:3.11-slim

# Secure: digest is immutable — this exact image or nothing
FROM python:3.11-slim@sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

Épinglez les GitHub Actions par SHA

Référencez les GitHub Actions par leur SHA de commit complet plutôt que par un tag mutable :

# Vulnerable: v3 tag can be moved to point to compromised code
- uses: actions/checkout@v3

# Secure: pinned to specific commit SHA
- uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2

Vérifiez les signatures des dépendances

Lorsque c’est possible, vérifiez les signatures cryptographiques pour confirmer que les artefacts ont été publiés par leurs mainteneurs attendus :

• npm : Utilisez npm audit signatures pour vérifier les signatures du registre sur les packages.
• Images de conteneurs : Utilisez Sigstore/cosign pour vérifier les signatures des images de conteneurs.
• Python : La PEP 740 et des outils comme sigstore-python apportent la vérification de signatures à PyPI.

Générez et suivez les SBOMs

Un Software Bill of Materials (SBOM) inventorie chaque composant de votre application. En générant des SBOMs pour chaque build et en les comparant, vous pouvez détecter des ajouts ou modifications inattendus dans votre arbre de dépendances. Des outils comme Syft, Trivy et CycloneDX peuvent générer des SBOMs dans des formats standards (SPDX, CycloneDX).

Automatisez la revue des dépendances

Déployez des outils automatisés qui analysent continuellement vos dépendances à la recherche de vulnérabilités connues et de changements suspects :

• Dependabot / Renovate : Créent automatiquement des PR lorsque des mises à jour de dépendances sont disponibles, vous donnant l’occasion de les examiner avant de les fusionner.
• npm audit / pip-audit : Analysent les vulnérabilités connues dans votre arbre de dépendances.
• GitHub Dependency Review Action : Bloque les PR qui introduisent des dépendances avec des vulnérabilités connues.

Restreignez l’accès réseau pendant les builds (builds hermétiques)

Les builds hermétiques sont des builds qui ne peuvent pas accéder au réseau. Toutes les dépendances doivent être pré-récupérées et mises en cache avant le début du build. Cela empêche un build de récupérer un package malveillant nouvellement publié. Bazel prend nativement en charge les builds hermétiques, et une isolation similaire peut être obtenue avec le flag --network=none de Docker ou des politiques réseau spécifiques à la plateforme CI.

Pré-approuvez et établissez une liste d’autorisation des dépendances

Maintenez une liste approuvée de dépendances et de leurs versions. Tout nouveau changement de dépendance ou de version nécessite une approbation explicite via un processus de revue. Bien que cela ajoute de la friction, cela empêche les packages non autorisés d’entrer dans votre pipeline de build.

Détection et surveillance

Même avec des contrôles préventifs solides, les capacités de détection sont essentielles pour intercepter les attaques qui contournent vos défenses.

Surveillez les nouvelles dépendances inattendues

Implémentez des vérifications CI qui signalent les pull requests introduisant de nouvelles dépendances. Exigez une justification explicite et une revue pour tout ajout à votre manifeste de dépendances. C’est particulièrement important pour les dépendances transitives — une nouvelle dépendance directe peut en apporter des dizaines de transitives.

Alertez sur les sauts de version des dépendances

Une dépendance passant de la version 1.2.3 à 99.0.0 est un indicateur fort d’une attaque par dependency confusion. Implémentez une surveillance qui alerte sur les changements de version inhabituels, en particulier les sauts majeurs de version importants sur les packages internes.

Tirez parti des outils d’analyse de sécurité

• Socket.dev : Analyse le comportement des packages (accès réseau, accès au système de fichiers, scripts d’installation) plutôt que les seuls CVE connus, ce qui le rend efficace pour détecter les attaques sur la chaîne d’approvisionnement.
• Snyk : Fournit une analyse et une surveillance des vulnérabilités sur plusieurs écosystèmes.
• GitHub Dependency Graph et Dependabot Alerts : Suivent automatiquement les dépendances et alertent sur les vulnérabilités connues.

Analysez les scripts d’installation et les hooks post-installation

Implémentez des outils qui identifient spécifiquement les packages avec des scripts d’installation. Bien que les scripts d’installation aient des usages légitimes, ils sont le principal vecteur d’exécution des attaques par dependency confusion. Signalez et examinez tout package qui inclut des scripts preinstall, install ou postinstall dans npm, ou un setup.py avec du code exécutable en Python.

Comparez les SBOMs entre les builds

Effectuez régulièrement un diff des SBOMs entre des builds consécutifs. Les changements inattendus — nouveaux packages apparaissant, versions changeant sans mises à jour correspondantes du manifeste, ou packages provenant de registres inattendus — devraient déclencher des alertes et une investigation.

Durcissement spécifique au CI/CD

Au-delà de la gestion des dépendances, la configuration de votre pipeline CI/CD elle-même doit être durcie pour résister aux attaques sur la chaîne d’approvisionnement.

Commitez et vérifiez les fichiers de verrouillage en CI

Les fichiers de verrouillage (package-lock.json, yarn.lock, Pipfile.lock, poetry.lock) enregistrent les versions et hashes exacts de chaque dépendance. Votre pipeline CI devrait échouer si le fichier de verrouillage présente des changements inattendus.

Exemple GitHub Actions — vérification de l’intégrité du lockfile :

name: Build
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2

      - name: Setup Node.js
        uses: actions/setup-node@1a4442cacd436585916f1b3aa94e4166f1a22160 # v3.8.2
        with:
          node-version: '20'

      - name: Verify lockfile has not been tampered with
        run: |
          # npm ci will fail if package-lock.json is out of sync
          # with package.json or if integrity hashes don't match
          npm ci

      - name: Check for lockfile modifications
        run: |
          if ! git diff --exit-code package-lock.json; then
            echo "ERROR: package-lock.json was modified during install."
            echo "This could indicate a dependency confusion attack."
            exit 1
          fi

      - name: Audit dependencies
        run: npm audit --audit-level=high

Exemple GitLab CI — vérification du lockfile avec pip :

stages:
  - verify
  - build
  - test

verify-dependencies:
  stage: verify
  image: python:3.11-slim@sha256:abc123...  # Pin by digest
  script:
    - pip install pip-tools pip-audit
    # Verify that requirements.txt hashes match actual packages
    - pip install --require-hashes --no-deps -r requirements.txt
    # Audit for known vulnerabilities
    - pip-audit -r requirements.txt
    # Ensure no unexpected changes to lockfile
    - pip-compile --generate-hashes requirements.in -o /tmp/requirements-check.txt
    - diff requirements.txt /tmp/requirements-check.txt
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

build:
  stage: build
  image: python:3.11-slim@sha256:abc123...
  script:
    - pip install --require-hashes --no-deps -r requirements.txt
    - python -m build
  needs: [verify-dependencies]

Séparez la résolution des dépendances de l’exécution du build

Utilisez un processus de build en deux phases : d’abord résolvez et téléchargez les dépendances dans un environnement isolé, puis exécutez le build réel avec l’accès réseau désactivé. Cela empêche une dépendance compromise d’exfiltrer des données ou de télécharger des charges utiles supplémentaires pendant le build.

Environnements de build isolés ou à accès réseau restreint

Pour les builds à haute sécurité, utilisez des environnements à accès réseau restreint qui ne peuvent accéder qu’à votre proxy de registre interne. Cela élimine la possibilité que des dépendances soient récupérées directement depuis les registres publics pendant le build.

# Docker-based hermetic build example
# Phase 1: Fetch dependencies (with network)
docker run --name dep-fetch my-builder:latest \
  npm ci --prefer-offline

# Phase 2: Build (without network)
docker run --network=none -v deps:/app/node_modules \
  my-builder:latest npm run build

Mettez en cache les dépendances dans un stockage interne de confiance

Au lieu de récupérer les dépendances depuis les registres publics à chaque build, mettez en cache les versions approuvées dans un stockage interne (Artifactory, Nexus, buckets de stockage cloud). Votre pipeline CI devrait puiser exclusivement dans ce cache de confiance. Mettez à jour le cache via un processus contrôlé et audité.

Conclusion

La dependency confusion et l’artifact poisoning exploitent des hypothèses de confiance profondément ancrées dans la chaîne d’approvisionnement logicielle. Chaque npm install, chaque docker pull, chaque directive uses: dans un workflow GitHub Actions est une décision de confiance — et les attaquants travaillent activement pour abuser de cette confiance.

Une défense efficace ne repose pas sur un seul outil ou changement de configuration. Elle nécessite des contrôles à chaque couche du cycle de vie des dépendances :

• Résolution : Scopez vos packages, configurez la priorité des registres, utilisez des proxys de registres pour éliminer l’ambiguïté public/privé.
• Installation : Épinglez par hash, utilisez les fichiers de verrouillage avec npm ci ou --require-hashes, désactivez les scripts d’installation lorsque c’est possible.
• Vérification : Vérifiez les signatures, comparez les SBOMs, auditez les dépendances avant qu’elles n’entrent dans votre build.
• Surveillance : Détectez les changements de dépendances inattendus, alertez sur les anomalies de version, analysez les comportements malveillants dans les packages.
• Durcissement du pipeline : Restreignez l’accès réseau pendant les builds, vérifiez l’intégrité des fichiers de verrouillage en CI, séparez la résolution des dépendances de l’exécution du build.

Les organisations les plus résilientes face aux attaques sur la chaîne d’approvisionnement seront celles qui traitent les dépendances avec la même rigueur qu’elles appliquent à leur propre code : revues, vérifiées, surveillées et jamais implicitement fiables. Commencez par implémenter les contrôles à plus fort impact — packages scopés, configuration des registres, vérification des fichiers de verrouillage en CI — et ajoutez progressivement des couches au fur et à mesure que votre programme de sécurité de la chaîne d’approvisionnement mûrit.