Supply Chain : Detecter les Dependances Malveillantes

En 2025, plus de 512 000 packages malveillants ont été détectés sur les registres npm et PyPI, soit une augmentation de 156 % par rapport à 2023. Chaque dépendance que vous installez représente un vecteur d'attaque potentiel : une bibliothèque compromise, un package sosie ou un pipeline de build infiltré peuvent exposer vos systèmes à des attaquants sans que vous n'ayez jamais écrit une ligne de code vulnérable. La supply chain dépendances malveillantes détection est devenue un pilier incontournable de la sécurité logicielle moderne, au même titre que les tests d'intrusion ou la gestion des identités. Des incidents majeurs comme SolarWinds en 2020, l'attaque XZ Utils en 2024 ou le sabotage délibéré de colors.js en 2022 ont démontré que les menaces ne viennent plus seulement de l'extérieur — elles se glissent dans vos package.json et vos requirements.txt. Ce guide technique présente les techniques d'attaque, les exemples documentés, les outils de détection et les pratiques pour sécuriser l'intégralité de votre pipeline de développement logiciel. Il s'adresse aux équipes DevSecOps, aux RSSI et aux développeurs souhaitant comprendre et réduire leur surface d'exposition dans la chaîne d'approvisionnement logicielle.

Typosquatting npm et PyPI : la menace des packages sosies

Le typosquatting consiste à publier sur un registre public un package dont le nom est très proche d'une bibliothèque populaire, en espérant que des développeurs distraits ou des pipelines automatisés l'installent à la place de l'original. La technique est simple, difficile à détecter à l'œil nu, et redoutablement efficace.

Les exemples documentés sont nombreux : lodahs vs lodash, requestes vs requests, cross-fetch vs cross.fetch, colourama vs colorama. En 2023, des chercheurs de Checkmarx ont identifié une campagne ciblant spécifiquement les packages Python les plus téléchargés (boto3, urllib3, requests) avec des variantes typosquattées contenant des stealers de credentials AWS. En 2025, le rapport de socket.dev recense 512 000 packages suspects retirés des registres npm et PyPI, dont une majorité exploitaient le typosquatting.

La dangerosité de ces packages tient à leur comportement lors de l'installation : ils exécutent des scripts postinstall (npm) ou des hooks setup.py (Python) qui s'activent dès npm install ou pip install, avant même que le développeur ait importé la bibliothèque. Le code malveillant peut alors exfiltrer les variables d'environnement, les tokens AWS/GCP ou les clés SSH présents sur la machine du développeur ou dans le runner CI/CD.

Dependency confusion : quand les packages internes deviennent une cible

En février 2021, le chercheur en sécurité Alex Birsan publie une technique d'attaque qui va ébranler des dizaines d'entreprises du Fortune 500 : la dependency confusion (ou namespace confusion). Le principe est élégant dans sa perversité.

Lorsqu'une organisation utilise un gestionnaire de packages comme npm, pip ou nuget avec un registre privé, les packages internes ont généralement des noms qui n'existent pas sur les registres publics. Birsan a découvert que lorsqu'un résolveur de packages cherche d'abord sur le registre public avant de vérifier le privé — ou lorsqu'il consulte les deux et prend la version au numéro le plus élevé — il suffit de publier sur npm ou PyPI un package portant le même nom qu'un package interne, avec un numéro de version supérieur (par exemple 99.0.0), pour que les builds d'une organisation téléchargent automatiquement le package public malveillant à la place du package interne légitime.

Birsan a utilisé cette technique dans un cadre de bug bounty et a réussi à exécuter du code sur les systèmes internes d'Apple, Microsoft, Netflix, Shopify, Tesla et une trentaine d'autres entreprises. Il a reçu plus de 130 000 dollars de récompenses. La technique a depuis été exploitée dans la nature par des acteurs malveillants.

Pour tester si votre organisation est vulnérable, vous pouvez vérifier si des packages internes sont mentionnés dans des fichiers package.json ou requirements.txt publiés accidentellement sur GitHub, puis rechercher si ces noms existent sur les registres publics. Des outils comme confused automatisent cette vérification.

La parade la plus robuste est d'utiliser des scopes npm privés (ex : @monentreprise/mon-package), de configurer un registre Artifactory ou Nexus avec une politique stricte de résolution interne-first, et de ne jamais exposer les noms de packages internes dans des dépôts publics.

Incidents célèbres : quand les mainteneurs deviennent la menace

Si le typosquatting et la dependency confusion impliquent des attaquants externes, certains incidents parmi les plus notables de ces dernières années ont été causés par les mainteneurs légitimes eux-mêmes.

colors.js et faker.js — janvier 2022

Le 6 janvier 2022, Marak Squires, auteur de deux bibliothèques npm parmi les plus utilisées — colors.js (plus de 25 millions de téléchargements hebdomadaires) et faker.js (plus de 2,5 millions) — publie délibérément des versions corrompues. colors.js version 1.4.44-liberty-2 affiche une boucle infinie de caractères ASCII non-sens, rendant les applications dépendantes inutilisables. faker.js version 6.6.6 efface son propre contenu, remplaçant les exports par des valeurs nulles.

Marak Squires avait annoncé publiquement son intention de ne plus maintenir ces bibliothèques gratuitement pour les grandes entreprises. L'acte de sabotage a affecté des milliers d'applications en production, notamment celles d'Amazon Web Services. La réponse de la communauté a été de geler les versions précédentes et de créer des forks.

event-stream — novembre 2018

L'attaque event-stream est considérée comme l'un des premiers cas documentés d'attaque supply chain via le transfert de propriété d'un package npm. Le mainteneur originel a cédé le contrôle du package à un inconnu qui a ajouté une dépendance à flatmap-stream, un package contenant du code chiffré ciblant les portefeuilles Bitcoin de l'application Copay de BitPay. Le code malveillant volait les clés privées et les envoyait à un serveur distant, mais uniquement lorsque la taille du portefeuille dépassait 100 BTC (environ 750 000 dollars à l'époque). La subtilité du ciblage a retardé la détection de plusieurs semaines.

node-ipc — mars 2022

En mars 2022, Brandon Nozaki Miller, mainteneur de node-ipc (bibliothèque de communication inter-processus), a ajouté un payload antiwar dans les versions 10.1.1 et 10.1.2. Le code vérifiait l'adresse IP de la machine et, si celle-ci était localisée en Russie ou en Biélorussie, effaçait silencieusement des fichiers du système. Cette attaque a particulièrement touché des projets utilisant Vue CLI qui avait node-ipc comme dépendance transitive. L'incident a relancé le débat sur la fiabilité du modèle open source et la sécurité des dépendances transitives.

SolarWinds et les leçons du build pipeline compromise

En décembre 2020, la découverte de la campagne SolarWinds a représenté un tournant dans la perception des attaques supply chain. Les attaquants — attribués au groupe russe Cozy Bear — avaient compromis le pipeline de build d'Orion, le logiciel de monitoring réseau de SolarWinds, et injecté le malware SUNBURST directement dans les mises à jour signées numériquement. Entre mars et juin 2020, environ 18 000 clients avaient installé des mises à jour contenant le backdoor, parmi lesquels le Département du Trésor américain, le Pentagone et des centaines d'entreprises Fortune 500.

Les leçons tirées de SolarWinds sont fondamentales pour toute organisation gérant un pipeline CI/CD :

• La signature de code ne suffit pas si le système de signature lui-même est compromis. Les binaires malveillants de SolarWinds étaient légitimement signés avec le certificat de l'entreprise.
• L'isolation des environnements de build est critique : les serveurs de compilation doivent être segmentés et leur accès strictement contrôlé.
• La reproductibilité des builds (reproducible builds) permet de vérifier qu'un binaire distribué correspond exactement au code source — une propriété qu'un pipeline compromis ne peut pas préserver.
• Le SBOM (Software Bill of Materials) aurait permis de tracer rapidement quelles versions contenaient le code malveillant et quels clients étaient exposés.

En réponse directe à SolarWinds, le président Biden a signé l'Executive Order 14028 en mai 2021, imposant aux fournisseurs de logiciels de l'administration fédérale américaine de produire des SBOM, d'adopter des pratiques de développement sécurisé et de renforcer la traçabilité de leur chaîne logicielle. Le NIST SP 800-161 Rev.1 (Cybersecurity Supply Chain Risk Management Practices) fournit le cadre normatif détaillé.

XZ Utils CVE-2024-3094 : la backdoor invisible

Le 29 mars 2024, Andres Freund, ingénieur Microsoft, publie sur la liste de diffusion oss-security@openwall un message qui va déclencher une alerte mondiale dans la communauté de sécurité open source. En enquêtant sur une légère dégradation de performance de SSH sur sa machine Debian testing, il a découvert que liblzma, la bibliothèque de compression faisant partie de XZ Utils, avait été intentionnellement modifiée pour introduire une backdoor dans sshd.

La timeline de cette attaque est remarquable par sa sophistication et sa patience :

• Fin 2021 : un acteur sous le pseudonyme "Jia Tan" (JiaT75) commence à contribuer régulièrement au projet XZ Utils, gagnant progressivement la confiance du mainteneur principal Lasse Collin.
• 2022-2023 : Jia Tan devient co-mainteneur, obtenant les droits de commit et de release. Des pressions sociales orchestrées poussent Lasse Collin à déléguer davantage.
• Février 2024 : les versions 5.6.0 et 5.6.1 de XZ Utils sont publiées avec la backdoor dissimulée dans les scripts de build, non dans le code C directement. La backdoor modifie le comportement de sshd via systemd pour permettre à un attaquant disposant d'une clé privée spécifique d'exécuter des commandes arbitraires sur le système.
• 29 mars 2024 : Andres Freund découvre la backdoor par accident — la latence inhabituelle de SSH l'a mis sur la piste.

Le CVE-2024-3094 a reçu un score CVSS de 10.0/10. Bien que la backdoor n'ait été présente que dans des versions de test (Debian unstable, Fedora Rawhide, openSUSE Tumbleweed) et n'ait pas atteint les distributions stables, l'incident démontre qu'une attaque supply chain contre un projet open source critique peut se développer sur plusieurs années, passant toutes les revues de code. Il souligne également l'importance de surveiller les comportements anormaux à l'exécution et pas seulement les vulnérabilités connues.

Outils de détection des dépendances malveillantes

Face à l'ampleur de la menace, plusieurs outils spécialisés permettent d'automatiser la détection et l'analyse des dépendances. Ils se distinguent par leur approche : base de données de vulnérabilités connues, analyse comportementale, ou traçabilité de la provenance.

npm audit, pip-audit et cargo audit

Les gestionnaires de packages intègrent des fonctions d'audit nativement. npm audit interroge la base GitHub Advisory Database pour identifier les CVE connues dans les dépendances npm. pip-audit fait de même pour Python en consultant PyPI Advisory Database et OSV (Open Source Vulnerabilities). cargo audit couvre l'écosystème Rust via RustSec.

# Audit des dépendances npm — filtrer les critiques
npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.severity == "critical")'

# pip-audit pour Python
pip install pip-audit
pip-audit -r requirements.txt --format json

# Vérification d'un package npm avant installation
npm pack lodash --dry-run
# Comparer le hash avec le registre officiel
npm view lodash dist.integrity

Dependabot (GitHub)

Dependabot est l'outil de gestion automatique des dépendances intégré à GitHub. Au-delà des simples alertes de sécurité, il peut créer automatiquement des Pull Requests de mise à jour lorsqu'une vulnérabilité est détectée ou qu'une nouvelle version est disponible. Sa configuration dans .github/dependabot.yml permet de cibler des écosystèmes spécifiques (npm, pip, Docker, Actions) et de définir des politiques de merge automatique pour les patches de sécurité.

Snyk

Snyk est une plateforme commerciale (avec un tier gratuit généreux) qui va plus loin que les outils natifs : elle scanne les vulnérabilités, les problèmes de licences, et propose des correctifs de code. L'intégration CI/CD de Snyk peut bloquer les builds dont le score de risque dépasse un seuil configuré. Sa base de données propriétaire est souvent plus rapide que les bases publiques pour identifier des packages malveillants émergents.

Socket.dev — analyse comportementale

Socket Security propose une approche différente et complémentaire : plutôt que de ne se fier qu'aux CVE connus, Socket analyse le comportement déclaré des packages npm et PyPI. Il détecte les packages qui accèdent au réseau, lisent des variables d'environnement, exécutent des binaires natifs ou installent des hooks postinstall — autant de signaux d'alarme pour des packages légitimes mais qui peuvent indiquer un comportement malveillant dans un typosquat. Socket s'intègre en tant que GitHub App et commente directement les PR qui introduisent des dépendances suspectes.

OWASP Dependency-Check

OWASP Dependency-Check est un outil open source qui supporte Java, .NET, JavaScript, Python, Ruby, PHP et d'autres écosystèmes. Il identifie les composants avec des vulnérabilités connues (CVE) en analysant les fichiers de dépendances et les binaires compilés. Son rapport HTML est particulièrement adapté pour les audits de conformité.

SBOM : le Software Bill of Materials comme pivot de traçabilité

Un Software Bill of Materials est l'équivalent d'une liste d'ingrédients pour les logiciels : il liste exhaustivement tous les composants, leurs versions, leurs licences et leurs dépendances transitives. En cas d'incident (comme SolarWinds ou Log4Shell), un SBOM à jour permet de répondre en quelques minutes à la question "sommes-nous exposés ?" au lieu de passer des jours à inventorier manuellement les dépendances.

Deux formats standard coexistent aujourd'hui :

• CycloneDX — poussé par OWASP, format JSON/XML, excellent support des outils DevSecOps, inclut la traçabilité de la provenance et les données de composition.
• SPDX — standard Linux Foundation / ISO, format plus verbeux, plus orienté conformité de licences, adopté par GitHub pour son export SBOM natif.

# Générer un SBOM CycloneDX pour Python
pip install cyclonedx-bom
cyclonedx-py requirements requirements.txt > sbom.json

# Générer un SBOM pour npm avec CycloneDX
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Vérification signature Cosign (SLSA provenance)
cosign verify ghcr.io/myorg/myimage:latest   --certificate-identity-regexp=https://github.com/myorg   --certificate-oidc-issuer=https://token.actions.githubusercontent.com

La CISA publie des ressources détaillées sur le SBOM, incluant les formats minimaux requis et les cas d'usage sectoriels. En Europe, la directive NIS 2 impose aux entités essentielles et importantes de gérer les risques de leur chaîne d'approvisionnement, ce qui inclut de facto la traçabilité des composants logiciels.

Pipeline CI/CD sécurisé : SLSA, Sigstore et hash pinning

Sécuriser les dépendances n'est qu'une partie du problème. Le pipeline CI/CD lui-même — les runners GitHub Actions, les serveurs Jenkins, les registres d'artefacts — représente une surface d'attaque que l'incident SolarWinds a rendue évidente. Le framework SLSA (Supply chain Levels for Software Artifacts) définit quatre niveaux de maturité pour sécuriser la provenance des artefacts logiciels.

Plusieurs pratiques concrètes peuvent être mises en œuvre immédiatement :

• Lockfiles stricts : utiliser npm ci plutôt que npm install en CI pour garantir l'utilisation exacte du package-lock.json. Équivalent : pip install --require-hashes -r requirements.txt.
• Hash pinning : dans les Actions GitHub, pointer vers des SHA de commits plutôt que des tags (actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 au lieu de @v4) — les tags peuvent être réassignés.
• Sigstore/Cosign : Cosign permet de signer et vérifier les images Docker et les artefacts via des certificats éphémères liés à une identité OIDC (GitHub Actions, Google Workload Identity). Cette signature sans gestion de clé long-terme réduit le risque SolarWinds.
• Registre d'artefacts privé : utiliser Artifactory, Nexus ou GitHub Packages comme proxy des registres publics, avec une politique d'approbation des nouveaux packages.

# GitHub Actions: SLSA provenance + audit sécurité
name: secure-build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # SHA pin
      - name: Install with lockfile
        run: npm ci  # respecte package-lock.json, pas npm install
      - name: Audit dependencies
        run: npm audit --audit-level=high
      - name: Socket Security check
        uses: nicowillis/socket-security-action@v1
      - name: Generate SBOM
        run: npx @cyclonedx/cyclonedx-npm --output-file sbom.json
      - name: Upload SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Incidents supply chain : tableau récapitulatif des cas majeurs

Comment vérifier un package avant installation ?

Avant d'ajouter une nouvelle dépendance à votre projet, une vérification manuelle prend cinq minutes et peut éviter bien des catastrophes. Voici une checklist pratique :

1. Vérifier l'ancienneté et l'activité du dépôt : un package créé il y a moins d'une semaine avec peu de commits doit alerter. Consulter les dates de création sur npm/PyPI.
2. Analyser le nombre de dépendances transitives : chaque dépendance ajoutée introduit ses propres dépendances. Préférer les packages avec peu de dépendances pour les fonctions critiques.
3. Examiner les scripts postinstall : dans npm, regarder la clé scripts du package.json. Un postinstall légitime est rare pour une bibliothèque utilitaire.
4. Contrôler la cohérence auteur/organisation : le package est-il maintenu par l'organisation attendue ? Les comptes de mainteneurs ont-ils un historique crédible ?
5. Tester dans un environnement isolé : utiliser Docker ou une VM éphémère pour installer et tester un nouveau package avant de l'intégrer en CI.

# Inspecter le contenu d'un package npm sans l'installer
npm pack lodash --dry-run

# Voir les scripts du package
npm show lodash scripts

# Comparer le hash de distribution avec le registre
npm view lodash dist.integrity

# Inspecter un package Python avant installation
pip download requests --no-deps -d /tmp/pkg-inspect
cd /tmp/pkg-inspect && tar -xzf requests-*.tar.gz && less requests-*/setup.py

Pour aller plus loin sur la sécurité des applications côté API et services, consultez notre guide sur les attaques API GraphQL et REST et sur la supply chain applicative. La thématique touche également à la sécurité des clusters, documentée dans notre article sur les erreurs de configuration RBAC Kubernetes.

Conformité et cadre réglementaire : NIS 2, NIST, EO 14028

La sécurité de la supply chain logicielle n'est plus seulement une bonne pratique : elle est devenue une obligation réglementaire dans de nombreux secteurs.

L'Executive Order 14028 américain (mai 2021) impose aux fournisseurs de logiciels vendant à l'administration fédérale US de produire un SBOM pour chaque produit, d'implémenter des pratiques de développement sécurisé conformes au SSDF (Secure Software Development Framework, NIST SP 800-218) et de permettre des audits tiers de leurs pratiques de sécurité.

Le NIST SP 800-161 Révision 1 fournit un cadre complet de gestion des risques de la chaîne d'approvisionnement cyber (C-SCRM). Il organise les contrôles en familles (acquisition, développement, opérations, décommissionnement) et propose des niveaux de maturité adaptés à la criticité des systèmes.

En Europe, la directive NIS 2 (transposée en droit national avant octobre 2024) impose aux entités essentielles et importantes de "prendre des mesures appropriées pour gérer les risques liés à la sécurité de la chaîne d'approvisionnement pour chaque entité, y compris les aspects relatifs à la sécurité concernant les relations entre chaque entité et ses fournisseurs ou prestataires de services directs". Concrètement, cela signifie contractualiser des exigences de sécurité avec les fournisseurs de logiciels et composants, et vérifier leur conformité. Un RSSI externalisé peut vous accompagner dans la mise en conformité NIS 2 sur cet aspect spécifique.

Pour les organisations qui développent ou distribuent des IA, la menace s'étend aux modèles et aux datasets : consulter notre analyse des attaques supply chain sur les modèles IA HuggingFace pour comprendre comment cette surface d'attaque émergente se structure.

Questions fréquentes

Quelle est la différence entre typosquatting et dependency confusion dans une attaque supply chain ?

Le typosquatting consiste à publier un package dont le nom ressemble à une bibliothèque populaire (faute de frappe) pour piéger les développeurs inattentifs. La dependency confusion, elle, exploite la résolution automatique des packages : si un package interne porte le même nom qu'un package public avec un numéro de version supérieur, le gestionnaire de packages peut installer le package public malveillant à la place du package interne légitime, sans aucune faute de frappe. Les deux techniques nécessitent des contre-mesures différentes.

Comment un SBOM aide-t-il concrètement lors d'une crise comme Log4Shell ?

Lors de la divulgation de Log4Shell en décembre 2021, les organisations sans SBOM ont passé des jours à inventorier manuellement leurs applications pour identifier celles utilisant log4j. Les organisations disposant d'un SBOM à jour ont pu requêter leur inventaire en quelques minutes et identifier précisément quels systèmes étaient exposés, quelle version de log4j était utilisée, et prioriser les correctifs. Un SBOM est donc un outil de réponse à incident autant qu'un outil de conformité.

Les lockfiles garantissent-ils la sécurité des dépendances npm ou PyPI ?

Les lockfiles (package-lock.json, poetry.lock, requirements.txt avec hashes) garantissent la reproductibilité des builds en fixant les versions et les checksums des packages. Ils ne protègent pas contre une compromission du package lui-même à la source (si le package publié contient du code malveillant avant votre premier npm install). Ils protègent contre les substitutions ultérieures. Pour une protection complète, combinez lockfiles + audit régulier + vérification comportementale (socket.dev) + SBOM.

Comment détecter un package npm malveillant qui s'exécute lors de l'installation ?

L'approche la plus efficace est l'analyse comportementale en sandbox. Exécutez npm install dans un environnement isolé (container sans accès réseau sortant) et surveillez les appels système (strace sous Linux). Vérifiez systématiquement les champs scripts.postinstall, scripts.preinstall et scripts.install du package.json. Socket.dev automatise cette analyse pour les packages npm et PyPI. Enfin, comparez le hash du tarball téléchargé avec celui affiché sur le registre via npm view <package> dist.integrity.

Qu'est-ce que le framework SLSA et à partir de quel niveau faut-il viser pour une PME ?

SLSA (Supply chain Levels for Software Artifacts) définit quatre niveaux de sécurité pour la provenance des artefacts : L1 (documentation de la provenance), L2 (provenance hébergée, non falsifiable), L3 (build isolé et auditable), L4 (builds hermétiques reproductibles). Pour une PME, atteindre le niveau SLSA L2 est réaliste avec GitHub Actions en activant la génération de provenance SLSA (actions/attest-build-provenance). Le niveau L3 est recommandé pour les éditeurs de logiciels ou les organisations traitant des données sensibles.