Bonnes pratiques de sécurité npm : protéger vos packages après l’attaque Shai Hulud de 2025

Les attaques comme Shai-Hulud, Nx, event-stream, colors, node-ipc et d’autres montrent que les gestionnaires de packages sont des moteurs d’exécution, et pas de simples outils de téléchargement de bibliothèques. Nous devons rester vigilants dans la gestion des dépendances tierces et veiller à mettre en place les contrôles de sécurité appropriés.

Voici une liste pratique et sélectionnée de recommandations pour renforcer la sécurité du gestionnaire de packages npm, à destination du développement local sécurisé et des processus des mainteneurs de logiciels open source. Gardez-la ouverte à côté de votre terminal.

Voici les principaux points des pratiques, outils et domaines de sécurité pour lesquels nous recommandons une utilisation responsable, aussi bien aux développeurs qu’aux mainteneurs open source :

• Options CLI sécurisées par défaut pour npm, pnpm, Bun, Yarn et Deno

• Renforcement de la chaîne d’approvisionnement et installations déterministes

• Hygiène des fichiers de verrouillage et des dépendances

• Vérification des vulnérabilités et de l’état des packages

• Gestion des secrets et isolation de l’environnement de développement

• Pratiques des mainteneurs : 2FA, provenance, OIDC et réduction des dépendances

À propos de Shai-Hulud et des malwares de la chaîne d’approvisionnement

La famille d’attaques Shai-Hulud marque un tournant pour les développeurs JavaScript : npm install est désormais clairement un mécanisme d’exécution de code à distance, et non une simple commodité sans danger. En septembre 2025, la campagne Shai-Hulud d’origine a utilisé des versions altérées de packages comme ngx-bootstrap, ng2-file-upload et @ctrl/tinycolor pour diffuser une charge utile de type ver par le biais des scripts du cycle de vie npm. Des hooks malveillants postinstall ont récupéré un fichier bundle.js obfusqué, exécuté sur les machines des développeurs et les agents CI, afin de voler des identifiants npm, GitHub et cloud et de les exfiltrer via des webhooks et des workflows GitHub. Des centaines de packages ont finalement été concernés.

Le 24 novembre 2025, SHA1-Hulud est apparu comme une deuxième vague fondée sur le même principe, montrant à quelle vitesse les adversaires innovent. Cette variante se propage par le biais de packages npm trojanisés qui dissimulent des charges utiles dans des scripts preinstall. Une fois le package installé, le ver tente de transformer la victime en runner GitHub Actions auto-hébergé contrôlé par l’attaquant, injecte des workflows malveillants dans les dépôts et s’en sert pour exécuter des commandes arbitraires et dérober des secrets npm et GitHub. Il recherche activement des identifiants AWS, Azure et GCP et, dans certains cas, tente même de s’échapper du conteneur, d’élever ses privilèges sur l’hôte et d’effacer le répertoire personnel de l’utilisateur. À la date de rédaction, plus de 600 packages, dont des packages populaires de fournisseurs comme Zapier, PostHog et Postman, ont été identifiés dans cette campagne, et le nombre continue d’augmenter.

Ensemble, Shai-Hulud et SHA1-Hulud dessinent un mode opératoire clair pour les malwares modernes de la chaîne d’approvisionnement. Ils détournent les hooks du cycle de vie npm pour exécuter du code, utilisent les postes de travail des développeurs et les infrastructures CI/CD comme relais, et ciblent avant tout les identifiants, jetons et secrets cloud. Les détails de chaque incident continuent d’évoluer, mais la tendance est suffisamment claire pour en tirer des pratiques durables, que chaque développeur JavaScript devrait adopter comme des réflexes.

Cette fiche pratique transforme ces enseignements en mesures concrètes à appliquer dès aujourd’hui : configurer des paramètres de gestionnaire de packages sécurisés par défaut, se protéger contre les attaques de la chaîne d’approvisionnement, garantir une résolution des dépendances déterministe et sécurisée, intégrer des contrôles continus des vulnérabilités et de l’état des packages, et appliquer ces mesures à npm, pnpm, Bun et au reste de votre chaîne d’outils. L’objectif n’est pas de réagir spécifiquement à Shai-Hulud, mais de rendre votre utilisation quotidienne de npm résistante à la catégorie d’attaques qu’il représente.

Sommaire

1. Désactiver les scripts post-installation

2. Installer après un délai de sécurité

3. Renforcer les installations avec npq

4. Empêcher l’injection dans les fichiers de verrouillage

5. Utiliser des installations déterministes (npm ci, etc.)

6. Éviter les mises à niveau à l’aveugle

7. Ne pas stocker de secrets en clair dans .env

8. Développer dans des conteneurs

9. Activer la 2FA npm

10. Publier avec des attestations de provenance

11. Publier avec OIDC (publication de confiance)

12. Réduire l’arbre de dépendances

1. Désactiver les scripts post-installation

Votre objectif : empêcher l’exécution de code arbitraire pendant install.

Risque

Les scripts post-installation (et autres scripts du cycle de vie) constituent un vecteur d’attaque majeur de la chaîne d’approvisionnement (Shai-Hulud, Nx, event-stream). Toute dépendance ou dépendance transitive peut exécuter du code arbitraire au moment de l’installation.

Renforcement de la sécurité npm

Globalement : désactiver tous les scripts du cycle de vie (recommandé) :

# Safe-by-default on your machine
npm config set ignore-scripts true

Pour une installation donnée :

# One-off installs without running lifecycle scripts
npm install --ignore-scripts <package-name>

pnpm

Depuis la version 10, pnpm désactive les scripts postinstall par défaut et prend en charge une liste d’autorisations ou leur réactivation. Nous vous recommandons de consulter la documentation de pnpm sur la sécurité de la chaîne d’approvisionnement pour découvrir les différentes options de configuration.

Bun

Bun désactive les scripts postinstall par défaut et gère une liste d’autorisations interne. Vous pouvez accorder explicitement votre confiance à certaines dépendances via trustedDependencies dans package.json :

{
  "trustedDependencies": [
    "some-package",
    "another-package"
  ]
}

N’exécutez que les scripts dont vous avez réellement besoin

Utilisez une liste d’autorisations plutôt que de faire aveuglément confiance au contenu de package.json :

1# Use LavaMoat's allow-scripts to define where scripts may run
2npm install --save-dev @lavamoat/allow-scripts
3npx allow-scripts

Le package npm allow-scripts de LavaMoat vous permet d’activer sélectivement des scripts à des emplacements précis dans votre graphe de dépendances pour les packages npm de confiance qui ont réellement besoin de scripts preinstall ou postinstall, comme bcrypt, playwright et d’autres.

2. Installer après un délai de sécurité

Votre objectif : éviter les nouvelles versions malveillantes et les pièges du typosquattage.

Risque

Les attaquants exploitent SemVer et la résolution de « latest » en publiant de nouvelles versions, rapidement repérées puis retirées. Si vous installez immédiatement, vous êtes exposé à leurs effets.

npm : installations en fonction de la date

Limitez-vous aux versions publiées avant une date donnée :

# Install only if published before 2025-01-01
npm install express --before=2025-01-01

Délai dynamique de 7 jours (exemple avec la commande date de type BSD) :

npm install express --before="$(date -v -7d)"

Remarque : cette méthode est manuelle et peu fiable pour l’automatisation, mais constitue une mesure de sécurité explicite utile.

2.1 minimumReleaseAge de pnpm

Dans pnpm-workspace.yaml :

minimumReleaseAge: 20160  # minutes; here: 2 weeks

pnpm refusera les versions publiées depuis moins longtemps, laissant à l’écosystème le temps de repérer les versions malveillantes ou défectueuses.

2.2 Délai de sécurité Snyk pour les PR automatiques

Les PR automatiques de mise à niveau des dépendances de Snyk ignorent les versions publiées depuis moins d’environ 21 jours, ce qui réduit :

• Les mises à niveau vers des versions défectueuses rapidement retirées

• Les mises à niveau vers des packages publiés depuis des comptes compromis

Il s’agit d’un « délai de sécurité intégré à l’automatisation ».

3. Renforcer les installations avec npq

Votre objectif : ne pas installer un package avant qu’il ait passé des contrôles de sécurité et de cohérence de base.

Problème

Vous exécutez :

npm install some-package

sans savoir si :

• Le package est une faute de frappe d’un package populaire

• Il a été publié hier et n’a aucun utilisateur

• Il présente des vulnérabilités connues

• Il embarque des scripts pre/post-installation dangereux

Stratégie : faire précéder vos installations de npq

npq est un outil d’audit de sécurité avant installation (il utilise des « marshalls » pour effectuer des contrôles).

Installation :

npm install -g npq

Utilisez-le à la place de npm :

npq install express

Définissez-le comme outil par défaut :

alias npm='npq-hero'

# Persist the alias
echo "alias npm='npq-hero'" >> ~/.zshrc  # or ~/.bashrc
source ~/.zshrc

Le package npq installe npq et npq-hero ; ce dernier sert de remplacement direct à npm.

Contrôles effectués par npq (« marshalls »)

• Vulnérabilités via la base CVE de Snyk

• Détection des nouveaux packages (âge inférieur à 22 jours)

• Ancienneté de la version (moins de 7 jours)

• Packages ressemblants issus du typosquattage

• Vérification de la signature du registre npm

• Attestation de provenance de build

• Présence de scripts pre/post-installation

• État du package : README, LICENCE, URL du dépôt, téléchargements

• Ajout de binaires (nouveaux outils CLI)

• Signaux de dépréciation

• Validité du domaine du mainteneur / domaines expirés

Intégration avec pnpm et Bun

# One-off
NPQ_PKG_MGR=pnpm npq install fastify
NPQ_PKG_MGR=bun   npq install fastify

# Make pnpm go through npq
alias pnpm="NPQ_PKG_MGR=pnpm npq-hero"

4. Empêcher l’injection dans le fichier de verrouillage npm

Votre objectif : empêcher package-lock.json / yarn.lock de vous rediriger discrètement vers des sources malveillantes.

Risque

Un contributeur (ou un attaquant via une PR) peut :

• Ajouter un package malveillant au fichier de verrouillage.

• Modifier l’URL resolved pour pointer vers un hôte sous son contrôle (dépôt Git, archive tarball, gist).

• Modifier le hachage d’intégrité pour le faire paraître « valide ».

Ainsi, votre prochain install récupère un malware, même si package.json semble inoffensif.

Mesure d’atténuation : lockfile-lint

Installation :

npm install --save-dev lockfile-lint

Validez le fichier de verrouillage en autorisant certains hôtes et HTTPS :

npx lockfile-lint \
  --path package-lock.json \
  --type npm \
  --allowed-hosts npm yarn \
  --validate-https

Principales options de validation

• Validation de l’hôte – uniquement npm, yarn, verdaccio, etc.

• Obligation d’utiliser HTTPS – rejeter les schémas d’URL non sécurisés

• Validation du schéma – autoriser uniquement https:, git+https: et git+ssh:

• Validation du nom du package – l’URL résolue correspond au nom du package

• Validation de l’intégrité – imposer des hachages d’intégrité SHA-512 sécurisés

Intégration CI/CD

Ajoutez une étape de vérification du fichier de verrouillage avant l’installation :

{
  "scripts": {
    "lint:lockfile": "lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https",
    "preinstall": "npm run lint:lockfile"
  }
}

pnpm et l’injection dans les fichiers de verrouillage

Le fichier pnpm-lock.yaml de pnpm résiste mieux aux attaques, car :

• Il ne dépend pas de la même manière d’URL de tarball arbitraires

• Il n’installe pas un package présent dans le fichier de verrouillage mais absent de package.json

• Son format évite plusieurs vecteurs d’injection observés avec npm et yarn

Traitez malgré tout les fichiers de verrouillage comme des éléments critiques pour la sécurité.

5. Utiliser des installations déterministes (npm ci)

Votre objectif : garantir que les builds et les environnements de production utilisent exactement les versions consignées dans le fichier de verrouillage.

Risque

npm install tente de « corriger » les divergences entre package.json et le fichier de verrouillage, ce qui peut :

• Récupérer des versions différentes de celles qui sont consignées

• Rompre le caractère déterministe dans les environnements CI et de production

• Introduire des versions inattendues, vulnérables ou malveillantes

npm : utiliser ci plutôt que install

En local et en CI :

# Deterministic install based on package-lock.json
npm ci

Dépendances de production uniquement en CI/CD :

npm ci --only=production

Veillez à valider les fichiers de verrouillage dans le dépôt et à les tenir à jour.

Commandes déterministes pour les différents gestionnaires de packages

Yarn :

yarn install --immutable --immutable-cache

pnpm :

pnpm install --frozen-lockfile

Bun :

bun install --frozen-lockfile

Deno :

deno install --frozen

Les fichiers de verrouillage font partie de votre contrat de chaîne d’approvisionnement ; ce ne sont pas des artefacts de build à ignorer.

6. Éviter les mises à niveau npm à l’aveugle

Votre objectif : effectuer les mises à niveau après vérification et en tenant compte des signaux, plutôt que de tout passer à la dernière version.

Risque

Évitez les mises à niveau aveugles de dépendances tierces comme celle-ci :

npm update
npx npm-check-updates -u

Lorsque vous exécutez ces commandes, en CI ou dans votre environnement de développement local, vous risquez de :

• Récupérer des versions malveillantes publiées depuis les comptes de mainteneurs compromis

• Introduire des bugs bloquants et des versions retirées

• Déclencher des attaques par confusion de dépendances ou détournement d’espace de noms

De meilleures pratiques

1. Mises à niveau interactives :

npx npm-check-updates --interactive

2. Examinez chaque dépendance avant de la mettre à niveau.

3. Bots sensibles à la sécurité :

• PR de mise à niveau automatiques de Snyk

• PR de Dependabot GitHub

4. Ces outils créent des PR pouvant être examinées et accompagnées de contexte (journaux des modifications, CVE), au lieu de modifier silencieusement votre fichier de verrouillage.

7. Aucun secret en clair dans les fichiers .env

Votre objectif : empêcher l’exfiltration facile des secrets de votre environnement de développement.

Risque

Les fichiers .env et variables d’environnement en clair :

• Sont des cibles faciles pour les packages malveillants et les malwares de développement.

• Se retrouvent souvent dans les journaux, les vidages mémoire après incident, l’historique du terminal, etc.

• Sont accessibles via process.env ou par lecture directe des fichiers lors d’attaques de la chaîne d’approvisionnement.

Voici un exemple à éviter :

DATABASE_PASSWORD=my-secret-password
API_KEY=sk-1234567890abcdef

Schéma : références aux secrets et injection juste à temps

Étape 1 – Placez des références (et non les valeurs) dans .env :

DATABASE_PASSWORD=op://vault/database/password
API_KEY=infisical://project/env/api-key

Étape 2 – Utilisez l’interface CLI du gestionnaire de secrets à l’exécution. Exemple avec l’interface CLI de 1Password :

# Run app with secrets injected into process.env
op run -- npm start

# More explicit example with env-file
op run --env-file="./.env" -- node --env-file="./.env" server.js

Autres options : interface CLI d’Infisical, gestionnaires de secrets cloud, etc. Principe essentiel : la variable d’environnement contient une référence, pas le secret.

8. Travailler dans des conteneurs de développement

Votre objectif : isoler votre environnement de développement pour empêcher les malwares npm de prendre le contrôle de votre machine hôte.

Risque

Exécuter npm install sur votre machine hôte signifie que :

• Les packages malveillants peuvent lire les fichiers de vos autres dépôts

• Ils peuvent analyser les clés SSH, les profils de navigateur, les jetons d’IA/agent, etc.

• Ils partagent l’espace de noms du système d’exploitation avec tout le reste de vos activités

Modèle de conteneur de développement

Utilisez VS Code Dev Containers (ou un outil similaire) pour isoler l’environnement, par exemple avec le fichier de configuration DevContainer suivant .devcontainer/devcontainer.json :

{
  "name": "Node.js Dev Container",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:18",
  "features": {
    "ghcr.io/devcontainers/features/1password:1": {}
  },
  "postCreateCommand": "npm ci"
}

Ensuite :

1. Ouvrez le dossier dans VS Code

2. « Rouvrir dans un conteneur »

3. Toutes les installations et exécutions ont lieu dans le conteneur.

Renforcer la sécurité du conteneur de développement

Ajoutez des options de sécurité Docker et des indicateurs Node sécurisés :

"runArgs": [
  "--security-opt=no-new-privileges:true",
  "--cap-drop=ALL",
  "--cap-add=CHOWN",
  "--cap-add=SETUID",
  "--cap-add=SETGID"
],
"containerEnv": {
  "NODE_OPTIONS": "--disable-proto=delete"
}

Pour renforcer encore le contrôle, utilisez un Dockerfile personnalisé avec des images de base minimales, un utilisateur non root et un environnement d’exécution renforcé.

9. Activer la 2FA pour les comptes npm

Votre objectif : empêcher la prise de contrôle d’un compte de déboucher sur la publication de versions malveillantes par des comptes compromis.

Risque

Des incidents comme celui d’eslint-scope ont montré qu’une fois qu’un attaquant obtient des identifiants, il peut publier des versions compromises à des millions d’utilisateurs. L’authentification par mot de passe seul ne suffit pas.

Commandes

2FA pour la connexion, la publication et les modifications du profil :

npm profile enable-2fa auth-and-writes

2FA pour la connexion et les modifications du profil uniquement (moins strict) :

npm profile enable-2fa auth-only

Appliquez l’auth-and-writes à tous les comptes autorisés à publier ou à ajouter des responsables de maintenance.

Configurer la publication OIDC approuvée

En plus de configurer votre compte npm avec des contrôles de mot de passe adaptés, comme la 2FA et les Passkeys, utilisez également la nouvelle méthode Trusted OIDC Publishing comme seul moyen de publier de nouveaux packages npm, en établissant un lien direct avec votre dépôt GitHub et des workflows spécifiques. Consultez la section qui lui est consacrée plus loin.

10. Publier avec des attestations de provenance

Votre objectif est de permettre aux consommateurs de vérifier où et comment votre package a été créé.

Problème

Sans provenance, les consommateurs ne peuvent pas facilement savoir :

• Cette archive tar a-t-elle été créée à partir de la source A sur GitHub ou sur une machine malveillante ?

• Un pipeline CI compromis a-t-il injecté du code ?

Solution : npm publish --provenance

Dans GitHub Actions :

permissions:
  id-token: write

steps:
  - run: npm publish --provenance

Prérequis :

• npm CLI 9.5.0+

• GitHub Actions (ou GitLab CI/CD) avec des runners hébergés dans le cloud et la prise en charge d’OIDC

Cette méthode produit des métadonnées de build vérifiables par cryptographie et conformes aux normes émergentes de la chaîne d’approvisionnement (par exemple, OpenSSF).

11. Publier avec OIDC (publication approuvée)

Votre objectif est d’éliminer les jetons npm à longue durée de vie de vos pipelines CI/CD.

Risque

Les jetons à longue durée de vie :

• Peuvent être consignés ou ajoutés à un dépôt par accident

• Restent valides après une fuite

• Offrent un accès étendu et durable à votre organisation et à vos packages

Modèle de publication approuvée

1. Configurez le package comme éditeur approuvé sur npmjs.com (GitHub ou GitLab).

2. Utilisez OIDC dans votre workflow :

Exemple avec GitHub Actions :

permissions:
  id-token: write

steps:
  - run: npm publish

Aucun NPM_TOKEN n’est stocké où que ce soit. npm vérifie le jeton OIDC de votre CI et n’autorise la publication qu’à partir de vos workflows approuvés. Les attestations de provenance sont générées automatiquement.

12. Réduire l’arbre des dépendances de vos packages

Votre objectif est de réduire le graphe des dépendances afin de limiter la surface d’attaque susceptible de vous exposer à des risques.

Risque

Chaque dépendance :

• Ajoute ses propres dépendances transitives

• Implique des responsables de maintenance, des comptes et les risques de compromission associés

• Accroît votre exposition aux vulnérabilités et aux risques liés aux licences

Stratégie

Privilégiez une conception sans dépendances ou avec peu de dépendances. Utilisez JavaScript moderne plutôt que d’ajouter une bibliothèque utilitaire pour des tâches simples.

Exemples :

// Instead of lodash uniq
const unique = [...new Set(array)];

// Instead of axios for simple HTTP GET
const response = await fetch(url);

// Instead of utility libs for trivial checks
const isEmpty = obj => Object.keys(obj).length === 0;

Avant d’ajouter une dépendance, demandez-vous (ou demandez à votre équipe) :

• Cette fonctionnalité est-elle complexe ?

• Justifie-t-elle le coût en matière de sécurité et de maintenance ?

• Existe-t-il désormais une API standard pour cela ?

Perspectives en matière de sécurité des développeurs et de malwares de la chaîne d’approvisionnement

Ce guide reprend certaines bonnes pratiques de sécurité npm publiées pour la première fois en 2019, et les renforce et les complète en y intégrant les pratiques modernes et les leçons tirées des attaques de la chaîne d’approvisionnement observées en 2025.

Tout d’abord, les développeurs doivent considérer le gestionnaire de packages comme un moteur d’exécution non fiable et le configurer avec des options sécurisées par défaut. Cela signifie désactiver les scripts de cycle de vie dans la mesure du possible, utiliser des listes d’autorisation explicites lorsque ces scripts sont vraiment nécessaires et mettre en place des mécanismes comme des périodes de mise en attente et des audits avant installation, afin que « l’installation d’un nouveau package » soit un acte délibéré plutôt qu’un réflexe. Ces contrôles doivent s’étendre au-delà de npm à pnpm, Bun et aux autres gestionnaires de packages modernes, pour garantir des paramètres par défaut cohérents dans tous les outils de l’espace de travail.

Ensuite, la résolution des dépendances doit être déterministe et défendable. Les campagnes Shai-Hulud ont exploité le fait qu’une seule mise à jour de version passée inaperçue ou modification d’un fichier de verrouillage pouvait introduire une archive tar malveillante dans des milliers de projets. Pour y remédier, les équipes doivent fonder leurs workflows sur des fichiers de verrouillage stricts et figés, imposer cette pratique dans la CI et protéger ces fichiers à l’aide d’outils qui valident l’origine des packages. Les installations déterministes ne servent pas uniquement à garantir la reproductibilité : elles permettent aussi de répondre à la question « Quel code avons-nous exécuté, et d’où venait-il ? » lorsqu’un incident survient.

Troisièmement, les vulnérabilités et les indicateurs de santé des dépendances doivent être considérés comme un flux continu de données, et non comme un rapport ponctuel. Ces incidents évoluent plus vite que la publication traditionnelle des CVE. Vos défenses doivent donc combiner bases de données de vulnérabilités, alertes sur les malwares, attestations de provenance, indicateurs d’ancienneté et de popularité des packages, ainsi que des règles automatisées de mise à niveau intégrant des périodes de mise en attente. Les barrières de sécurité à l’installation, les PR automatisées qui évitent les versions très récentes et les outils capables de distinguer un correctif mineur d’une version de package non fiable et encore jamais observée sont des éléments essentiels.

Enfin, une sécurité npm efficace ne se limite pas à l’installation de dépendances. Elle dépend de la structure de votre environnement de développement local, de la gestion de vos secrets et de la manière dont vous publiez et maintenez vos propres packages. Travailler dans des conteneurs de développement renforcés limite l’impact lorsqu’un package malveillant est détecté. Je vous recommande de ne pas utiliser de secrets en texte brut dans vos variables d’environnement et de délaisser les fichiers .env en texte brut au profit de l’injection de secrets juste à temps, afin de réduire ce qu’un attaquant peut voler, même s’il parvient à exécuter du code. L’activation de la 2FA, de la publication approuvée avec OIDC et des attestations de provenance pour vos propres packages npm complique toute tentative d’usurpation de votre identité dans l’écosystème.

Restez en sécurité avec Snyk

Snyk suit de près la situation de Shai-Hulud et publie régulièrement des mises à jour sur sa plateforme. À la date d’hier (24 novembre), nous avions déjà recensé plus de 800 packages malveillants.

Nous avons réuni ci-dessous plusieurs ressources pour vous aider à mieux maîtriser l’incident actuel et à vous préparer au prochain.

Liste des packages compromis par Shai-Hulud

Snyk tient à jour une liste publique en ligne des packages malveillants Shai-Hulud associés à la campagne de malwares :

Rapports Zero-Day de Snyk

Lorsque vous connectez vos dépôts à Snyk ou les surveillez d’une autre manière, vous disposez d’un inventaire qui vous permet de suivre facilement différents aspects de vos dépendances, notamment de vérifier à l’échelle de toute votre organisation R&D si vous êtes touché par le malware Shai-Hulud.

Pour savoir si vous êtes concerné par cet événement, consultez Rapports > Rapport Zero-Day à la une. Pour en savoir plus sur cette fonctionnalité, consultez notre User Docs.

Les captures d’écran suivantes montrent où trouver cette option dans l’interface de Snyk (elles présentent la précédente attaque de la chaîne d’approvisionnement npm Shai-Hulud de septembre 2025). Le nouveau rapport s’intitule SHA1-Hulud npm Supply Chain Attack - Nov 2025 :

Surveillez vos dépendances avec Snyk

L’utilisation de bibliothèques open source exige une surveillance continue et une mise à jour régulière pour suivre les correctifs de sécurité, qu’il s’agisse de vulnérabilités CVE ou de campagnes de malwares, dans l’ensemble de votre arbre de dépendances, directes ou indirectes, et de votre organisation.

Avec Snyk, vous pouvez connecter vos dépôts Git et gérer proactivement les risques liés à l’open source dans vos projets JavaScript avec Snyk Open Source, notre outil SCA. Vous pouvez aussi — et devriez — tenir à jour une SBOM, une fonctionnalité fournie par défaut par Snyk.

Nous vous recommandons également de vous préparer dès aujourd’hui aux vulnérabilités Zero-Day de demain.