Comment auditer vos dependances npm et securiser votre supply chain open source en 7 etapes

Etape 1.Inventorier toutes les dependances, directes et transitives

Avant d'auditer quoi que ce soit, vous avez besoin d'une vision complete de ce que votre projet embarque. La commande npm list --all --json genere l'arbre complet de toutes les dependances resolues, y compris les transitives.

# Arbre complet en JSON
npm list --all --json > deps-tree.json

# Nombre total de dependances
npm list --all | wc -l

# Uniquement les dependances directes
npm list --depth=0

Pour la plupart des projets React ou Node.js de taille moyenne, vous decouvrirez entre 500 et 2 000 packages transitifs. C'est normal — et c'est exactement pourquoi l'audit manuel est impossible sans outils.

Etape 2.Lancer npm audit et comprendre les resultats

npm audit interroge la GitHub Advisory Database et le registre npm pour identifier les vulnerabilites connues dans votre arbre de dependances. La commande genere un rapport structure avec niveaux de criticite : info, low, moderate, high, critical.

# Audit complet avec rapport JSON
npm audit --json > audit-report.json

# Uniquement les vulnerabilites critiques et high
npm audit --audit-level=high

# Correction automatique quand possible
npm audit fix

# Voir les corrections sans les appliquer
npm audit fix --dry-run

Deux pièges classiques : (1) confondre « npm audit fix » avec « securite garantie » — npm audit ne couvre que les CVE publiees, pas les comportements malveillants non repertories ; (2) ignorer les vulnerabilites des devDependencies sous pretexte qu'elles ne vont pas en production — un plugin de build corrompu peut modifier votre bundle de production.

Integrez npm audit dans votre pipeline CI/CD comme etape obligatoire qui fait echouer le build si des vulnerabilites high ou critical sont detectees. Utilisez--audit-level=high plutot que critical pour ne pas laisser passer des vulnerabilites serieuses.

Etape 3.Analyser le comportement des packages avec Socket.dev

npm audit ne voit que les vulnerabilites deja connues et cataloguees. Il est aveugle aux packages malveillants nouveaux, aux typosquatters, aux packages qui ont ete compromis entre deux audits, ou aux scripts post-install qui exfiltrent des variables d'environnement.

Socket.dev analyse le comportement des packages avant qu'ils n'arrivent dans votre projet. Il detecte notamment : les acces reseau non declares dans les scripts d'installation, les lectures de fichiers sensibles (.env, ~/.ssh), les packages avec des auteurs recents qui ont pris le controle d'un package populaire (supply chain takeover), et les fichiers obfusques caches dans les artefacts publies.

# Installer la CLI Socket
npm install -g @socketsecurity/cli

# Scanner votre projet
socket scan create --org votre-org

# Verifier un package specifique avant installation
socket npm info lodash@4.17.21

L'integration GitHub de Socket ajoute un commentaire automatique sur chaque PR qui introduit une nouvelle dependance, avec un score de risque et les signaux detectes. C'est le moyen le plus efficace d'integrer l'analyse comportementale dans votre workflow sans friction.

Etape 4.Generer et maintenir un SBOM (Software Bill of Materials)

Un SBOM est l'inventaire exhaustif et lisible par machine de toutes les dependances de votre projet : nom, version, licence, hash de verification, et provenance. En 2026, le SBOM est devenu une exigence reglementaire dans plusieurs secteurs (Cyber Resilience Act europeen, obligations contractuelles avec les grandes entreprises et administrations publiques).

# Generer un SBOM au format CycloneDX (recommande)
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Generer un SBOM au format SPDX (norme ISO)
npx spdx-sbom-generator -p . -o ./sbom

# Utiliser syft (supporte npm, yarn, pnpm)
syft . -o cyclonedx-json > sbom.cyclonedx.json

Publichez votre SBOM dans votre depot (dossier sbom/ a la racine) et mettez-le a jour a chaque release. Ajoutez la generation du SBOM comme etape de votre pipeline de release, pas comme processus manuel.

Un SBOM public permet egalement a vos utilisateurs et clients de verifier eux-memes l'empreinte de securite de votre projet — ce qui renforce la confiance et peut etre un avantage commercial significatif pour les projets ciblant les entreprises.

Etape 5.Automatiser les mises a jour avec Renovate (ou Dependabot)

Une dependance non mise a jour pendant 6 mois accumule statistiquement 3 a 8 vulnerabilites corrigees dans les versions superieures. L'automatisation des mises a jour est donc un outil de securite autant qu'un outil de maintenance.

Renovate (Mend) est preferable a Dependabot pour les projets complexes : il permet de regrouper les PRs de mises a jour par categorie (patch, minor, major), de configurer des regles de merge automatique pour les patchs de securite, et de partager des configurations entre plusieurs projets via des presets.

// renovate.json — configuration recommandee
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"],
    "automerge": true
  },
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["major-update"],
      "automerge": false
    }
  ],
  "schedule": ["every weekend"]
}

Cette configuration active l'automerge des patchs de securite, regroupe les mises a jour de patch pour reduire le bruit, et cree des PRs separees necessitant une revue humaine pour les mises a jour majeures. Renovate s'installe en 10 minutes via l'application GitHub et est gratuit pour l'open source.

Etape 6.Evaluer la sante des packages avec OpenSSF Scorecard

Toutes les dependances ne se valent pas en termes de posture de securite. Un package maintenu par une personne, sans tests, sans CI et avec des permissions de publication larges represente un risque de supply chain superieur a un package maintenu par une fondation avec une politique de release signeee.

OpenSSF Scorecard evalue les projets open source sur 18 criteres de securite : presence de tests, utilisation de dependances epinglees, politique de revue des PRs, activation du branch protection, detection des secrets, scoring SAST, etc. Le score va de 0 a 10.

# Installer scorecard
go install sigs.k8s.io/scorecard/v5/cmd/scorecard@latest

# Evaluer votre propre projet
scorecard --repo=github.com/votre-org/votre-projet

# Evaluer une dependance avant de l'adopter
scorecard --repo=github.com/expressjs/express

# Generer un rapport JSON
scorecard --repo=github.com/votre-org/projet --format=json > scorecard.json

Adoptez une politique simple : evitez d'introduire des dependances avec un score Scorecard inferieur a 5. Pour les packages existants en dessous de ce seuil, identifiez des alternatives ou planifiez un remplacement. Vous pouvez aussi utiliser deps.dev (Google) pour obtenir le score Scorecard directement dans votre navigateur.

Etape 7.Documenter et faire respecter votre politique de dependances

Les outils ne servent a rien si les contributeurs ne savent pas quelles regles appliquer. Une politique de dependances documentee est le ciment qui rend durables les 6 etapes precedentes.

Creez un fichier DEPENDENCIES.md (ou une section dans CONTRIBUTING.md) qui documente :

• ✓Les criteres d'acceptation d'une nouvelle dependance (score Scorecard minimum, licence compatible, activite recente du mainteneur)
• ✓Le processus d'evaluation avant d'ajouter une dependance (commande Socket a lancer, validation par un second mainteneur)
• ✓La politique de mises a jour (patch : automerge, minor : revue sous 2 semaines, major : revue planifiee)
• ✓La procedure en cas d'incident supply chain (comment revert, comment notifier les utilisateurs, comment patcher)
• ✓La liste des dependances critiques qui font l'objet d'une surveillance renforcee

Ajoutez une etape de revue de la politique dans vos checklists de PR : « Cette PR ajoute-t-elle une nouvelle dependance ? Si oui, les criteres de la politique sont-ils valides ? » Ce simple ajout transforme la politique d'un document statique en pratique vivante.

Recapitulatif : les 7 etapes et les outils

Questions frequentes