Sécurité supply chain : pourquoi vos dépendances npm sont plus dangereuses que vous ne pensez

En mai 2021, l'attaque SolarWinds a infecté 18 000 organisations via une mise à jour logicielle. En 2022, des millions de packages npm ont été empoisonnés via la bibliothèque node-ipc. En 2024, une backdoor s'est nichée dans xz-utils qui allait atterrir dans toutes les grandes distributions Linux.

Les attaques supply chain sont efficaces parce qu'elles contournent le périmètre sécurité via du logiciel que vous installez et faites confiance vous-même. Et le problème grandit : l'application Node.js moyenne a 1 000+ dépendances transitives. Savez-vous lesquelles sont vulnérables maintenant ?

Le problème d'échelle

Dans un environnement de production récemment monitoré (PME belge, ~10 serveurs avec services Node.js et Go), l'agent monsys a compté :

• 10 854 dépendances sur quatre écosystèmes (npm, Go, Packagist, PyPI)
• 1 998 matches CVE après scan contre OSV.dev
• 14 CRITICAL que personne ne connaissait

Ce ne sont pas des chiffres hypothétiques — c'est ce qui a été trouvé en 90 secondes après activation de l'agent.

Le problème n'est pas que les développeurs sont mauvais en sécurité. C'est que personne ne peut suivre manuellement 10 000+ dépendances. Vous avez besoin d'automatisation qui scanne en continu, pas d'un pentest annuel qui donne un snapshot.

Trois couches de risque supply chain

monsys couvre trois couches différentes :

Couche 1 : Packages OS

L'agent lit dpkg -l, rpm -qa, winget list sur chaque hôte. Le hub compare quotidiennement à NVD + EPSS. EPSS est crucial : une CVE avec CVSS 9.8 mais EPSS 0.001 est moins urgente qu'une CVE avec CVSS 7.5 et EPSS 0.34.

Les processus Internet-exposed (nginx, Apache, Node.js port 443) reçoivent un facteur de risque 1.5× au-dessus de leur score CVE.

Les recommandations montrent ce qu'il faut faire aujourd'hui — priorisé par CVSS × exposition × EPSS, pas seulement par le score CVSS.

Couche 2 : Images conteneur

L'agent rapporte docker ps — juste les noms d'images, pas d'accès root nécessaire. Le hub lance Trivy server-side contre chaque image unique. Pas d'install Trivy sur la machine client, pas de software supplémentaire, pas de privilèges additionnels.

Couche 3 : Dépendances applicatives

C'est la couche que la plupart des équipes manquent : les dépendances transitives de votre code applicatif.

L'agent scanne les lockfiles sur l'hôte : package-lock.json / yarn.lock (npm), requirements.txt / Pipfile.lock (pip), composer.lock (PHP/Packagist), Gemfile.lock (Ruby), go.sum (Go). Depuis chaque lockfile, les tuples (package, version) sont extraits. Le hub batch-query OSV.dev par écosystème.

Important : l'agent n'envoie pas le contenu des lockfiles au hub. Seulement les tuples (package, version) parsés — la même information que npm ls donne à quiconque a accès shell. Le code source de votre application ne quitte pas l'hôte.

La page inventaire agrège par hôte : packages OS, dépendances app, services, utilisateurs, clés SSH, ports ouverts. Directement cliquable vers le statut CVE.

À quoi ressemble la timeline en pratique

L'argument le plus convaincant pour le scan continu est la timeline :

• T+0s — Agent installé sur dix serveurs de production
• T+45s — Premier batch query OSV.dev retourné : 1 998 matches
• T+5min — 10 854 dépendances mappées sur quatre écosystèmes, liées au chemin projet + score risque
• T+13min — L'opérateur a passé en revue les 14 CRITICAL, versions de correction à côté de chaque CVE
• T+17min — Premier go get -u + redeploy lancé pour trois des quatorze

Comparez à l'approche traditionnelle : pentest qui prend trois semaines, rapport de 80 pages qui arrive trois semaines plus tard, et discussion de priorisation qui prend encore deux semaines. La vulnérabilité existe depuis deux mois entre-temps.

Corrélation blast-radius : toutes les CVE ne sont pas aussi urgentes

Une CVE Critical sur un serveur de test interne est moins urgente qu'une CVE Medium sur votre load balancer. La priorisation CVE blast-radius le gère automatiquement.

Le hub fait un Breadth-First Search sur le graphe topologique pour déterminer la distance en hops de chaque serveur à Internet. Les recommandations CVE sont triées sur cvss_base × exposure_score × epss_probability.

Blast Radius par serveur : combien d'autres systèmes sont touchés si celui-ci est compromis ? Ce même score pèse dans la priorisation CVE.

Résultat : les cinq CVE que vous devez corriger aujourd'hui sont en haut, pas les cinq avec le plus haut score CVSS.

Process DNA comme couche additionnelle : détecter les binary-swaps

Un scan CVE détecte les vulnérabilités connues dans des logiciels connus. Mais que faire si un attaquant remplace une binaire sans introduire de CVE ?

Le fingerprinting Process DNA calcule un hash SHA256 de chaque binaire en cours d'exécution. Si /usr/bin/node a soudainement un autre hash sans mise à jour de package correspondante, c'est une alerte Critical — qu'il y ait une CVE associée ou non.

La page intégrité montre par hôte quelles binaires dévient de la baseline ou d'un manifest connu.

Les deux couches sont complémentaires :

• CVE matching : détecte les vulnérabilités connues dans les logiciels installés
• Process DNA : détecte les changements inconnus aux binaires en exécution

Ce que vous pouvez démontrer à un auditeur

L'article 21(2)(d) NIS2 exige la sécurité dans l'acquisition, le développement et la maintenance des systèmes. La sécurité supply chain en fait directement partie.

La page audit agrège ce que demandent les auditeurs : timelines CVE par hôte, evidence packs, signing chain.

Avec un evidence pack signé par-dessus, c'est vérifiable offline. Pas reconstruit manuellement à partir de commits Git et logs de déploiement, mais généré automatiquement à partir de données de monitoring live.

Honnête sur les limites

La sécurité supply chain n'a pas de solution parfaite. Ce que monsys détecte :

• ✓ CVE connues dans packages OS, images conteneur et dépendances applicatives
• ✓ Changements de binaires via process DNA
• ✓ Zero-day qui remplacent une binaire connue

Ce que monsys ne détecte pas :

• ✗ Attaques supply chain qui n'ont pas encore de CVE
• ✗ Attaques via écosystèmes non scannés (Rust cargo, .NET NuGet — roadmap Q3 2026)
• ✗ Attaques qui opèrent entièrement en mémoire sans changement disque

Pour la dernière catégorie, les canaries honeypot sont la couche complémentaire : un attaquant qui lit un fichier canary en mémoire déclenche tout de même une alerte Critical.

Pour commencer

Installez l'agent sur un serveur de production et attendez 90 secondes. Vous obtiendrez une vue CVE de vos dépendances que vous n'avez probablement jamais vue auparavant. La probabilité qu'il y ait une Critical que vous ne connaissiez pas : significative.

Cinq premiers serveurs gratuits. Pas de carte bancaire.

---

La sécurité supply chain est documentée dans docs.monsys.ai/fr/security/supply-chain. Installation en 30 secondes : monsys.ai/fr/signup.