Comment sécuriser vos dépendances npm contre les attaques supply chain en 7 étapes

L'attaque contre Injective Labs en juillet 2026 — 18 packages npm compromis, des milliers de clés privées exfiltrées — a rappelé brutalement que la supply chain JavaScript reste le maillon faible de l'écosystème open source. Pourtant, les outils pour s'en protéger existent, sont gratuits et s'intègrent en quelques minutes. Ce guide vous accompagne, étape par étape, pour construire une défense en profondeur autour de vos dépendances npm.

Pour une analyse détaillée de l'incident Injective Labs, consultez notre article dédié à l'attaque.

Étape 1 : Verrouiller votre lockfile et activer l'intégrité

Le fichier package-lock.json constitue votre première ligne de défense. Il fige les versions exactes de chaque dépendance et stocke les hashs d'intégrité (SHA-512) qui garantissent que le tarball téléchargé correspond au contenu attendu. Sans ce verrou, un attaquant peut publier une version malveillante sous le même numéro de version.

La règle d'or : en CI, utilisez toujours npm ci plutôt que npm install. La différence est fondamentale : npm ci supprime node_modules, installe uniquement depuis le lockfile et échoue si le lockfile ne correspond pas à package.json. Aucune mise à jour silencieuse n'est possible.

Pour aller plus loin, installez lockfile-lint qui vérifie que votre lockfile ne référence que des registres autorisés et utilise bien le protocole HTTPS :

# Installation
npm install --save-dev lockfile-lint

# Configuration dans package.json
{
  "lockfile-lint": {
    "path": "package-lock.json",
    "type": "npm",
    "allowed-hosts": ["npm"],
    "allowed-schemes": ["https:"],
    "allowed-urls": [],
    "empty-hostname": false,
    "validate-https": true,
    "validate-integrity": true
  }
}

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

Cette configuration bloque toute dépendance provenant d'un registre tiers non autorisé — une technique courante dans les attaques par confusion de dépendances (dependency confusion).

Étape 2 : Activer la vérification des signatures npm

Depuis npm v9, chaque package publié sur le registre public est signé avec une attestation de provenance via Sigstore. Cette signature cryptographique lie un package à son code source exact et au workflow CI qui l'a construit. En vérifiant ces signatures, vous confirmez que le package n'a pas été altéré entre la publication et l'installation.

# Vérifier les signatures de toutes vos dépendances
npm audit signatures

# Résultat attendu :
# 847 packages have verified registry signatures
# 12 packages have verified attestations

En CI, ajoutez cette commande comme étape obligatoire. Si un package échoue la vérification, le pipeline doit s'arrêter. Voici comment vérifier la provenance d'un package spécifique :

# Vérifier la provenance d'un package particulier
npm audit signatures --package=express

# Inspecter les détails de provenance
npm view express attestations

Attention : tous les packages ne fournissent pas encore d'attestation de provenance. En juillet 2026, environ 65% des 1000 packages les plus téléchargés incluent des attestations. L'étape suivante consiste à compléter cette vérification avec une analyse comportementale.

Étape 3 : Intégrer Socket.dev pour la détection en temps réel

Les scanners de vulnérabilités traditionnels détectent les CVE connues — des failles déjà documentées. Le problème : dans une attaque supply chain, le code malveillant est inséré intentionnellement et ne correspond à aucune CVE existante. Socket.dev adopte une approche radicalement différente en analysant le comportement du code.

Socket examine chaque mise à jour de dépendance et détecte les signaux suspects : accès réseau inattendu, lecture de variables d'environnement, exécution de scripts post-install, installation de binaires, obfuscation de code. C'est précisément ce type d'analyse qui aurait signalé les packages Injective Labs compromis dès leur publication.

Installation via GitHub App

L'intégration la plus simple passe par l'application GitHub de Socket. Elle analyse automatiquement chaque pull request qui modifie package.json ou package-lock.json :

1. Rendez-vous sur github.com/apps/socket-security
2. Installez l'application sur vos dépôts concernés
3. Socket commentera automatiquement les PR avec des alertes

Utilisation en ligne de commande

# Installation globale
npm install -g @socketsecurity/cli

# Scanner le projet courant
socket npm audit

# Scanner avant d'installer une nouvelle dépendance
socket npm install suspicious-package --dry-run

# Rapport détaillé au format SARIF (pour CI)
socket report create --output=sarif ./package-lock.json

Le plan gratuit de Socket couvre les dépôts publics sans limite. Pour les dépôts privés, un plan payant existe mais l'utilisation CLI reste gratuite pour l'audit ponctuel.

Étape 4 : Scanner les CVE avec npm audit et osv-scanner

Même si l'analyse comportementale de Socket détecte les attaques nouvelles, le scan de CVE connues reste indispensable. Une vulnérabilité publiée dans une dépendance transitive peut être exploitée sans que vous le sachiez. Deux outils complémentaires couvrent ce besoin.

npm audit avec filtrage

# Scanner uniquement les vulnérabilités high et critical
npm audit --audit-level=high

# Format JSON pour parsing en CI
npm audit --json --audit-level=high | jq '.vulnerabilities | length'

# Corriger automatiquement les vulnérabilités compatibles SemVer
npm audit fix

# ATTENTION : ne pas utiliser --force en production
# npm audit fix --force  # Peut casser des dépendances

osv-scanner pour une couverture élargie

Le scanner de vulnérabilités de Google, osv-scanner, interroge la base OSV qui agrège les vulnérabilités de multiples sources (GitHub Advisory Database, NVD, npm). Il offre une couverture plus large que npm audit seul :

# Installation
go install github.com/google/osv-scanner/cmd/osv-scanner@latest
# ou via npm
npx osv-scanner --lockfile=package-lock.json

# Scanner le projet
osv-scanner --lockfile=package-lock.json

# Exclure des CVE confirmées comme faux positifs
osv-scanner --lockfile=package-lock.json --config=osv-scanner.toml

Pour gérer les faux positifs, créez un fichier osv-scanner.toml qui documente chaque exclusion avec une justification. Cette approche assure la traçabilité des décisions de sécurité au fil du temps.

Étape 5 : Générer et maintenir un SBOM

Un SBOM (Software Bill of Materials) est l'inventaire complet de tous les composants logiciels de votre application, incluant les dépendances directes et transitives avec leurs versions exactes et licences. En 2026, deux réglementations européennes rendent le SBOM quasi-obligatoire : la directive NIS2 (réseaux et systèmes d'information) et le Cyber Resilience Act (CRA).

Format CycloneDX

# Installation
npm install --save-dev @cyclonedx/cyclonedx-npm

# Génération du SBOM au format CycloneDX JSON
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Format XML si requis par votre compliance
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.xml --output-reproducible

# Valider le SBOM généré
npx @cyclonedx/cyclonedx-npm --validate

Alternative SPDX avec syft

Si votre organisation préfère le format SPDX (plus répandu dans l'industrie automobile et aéronautique), l'outil syft d'Anchore génère des SBOM dans les deux formats :

# Installation de syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s

# Générer un SBOM SPDX depuis le répertoire projet
syft dir:. -o spdx-json=sbom.spdx.json

# Générer un SBOM CycloneDX
syft dir:. -o cyclonedx-json=sbom.cdx.json

Intégrez la génération du SBOM dans votre pipeline CI pour qu'il soit toujours à jour. Stockez-le comme artefact de build et associez-le à chaque release. En cas d'incident, vous saurez instantanément quels projets sont affectés par une dépendance compromise.

Étape 6 : Configurer les politiques de dépendances

Le fichier .npmrc permet de définir des politiques de sécurité qui s'appliquent à tous les développeurs du projet. Ces réglages préventifs empêchent les erreurs humaines et réduisent la surface d'attaque.

# .npmrc - Configuration sécurité projet
# Désactiver l'exécution automatique des scripts post-install
ignore-scripts=true

# Activer l'audit automatique à chaque installation
audit=true
audit-level=high

# Forcer le protocole HTTPS pour le registre
registry=https://registry.npmjs.org/
always-auth=true

# Restreindre les scopes autorisés (si vous utilisez des packages internes)
@votre-org:registry=https://npm.votre-org.com/
# Empêcher la confusion de dépendances
@votre-org:always-auth=true

# Exiger des versions exactes (pas de ^ ou ~)
save-exact=true

# Générer le lockfile de manière déterministe
package-lock=true

Le paramètre ignore-scripts=true est particulièrement important : la majorité des attaques supply chain npm s'exécutent via des scripts postinstall. En les désactivant par défaut, vous bloquez ce vecteur d'attaque. Lorsqu'un package légitime nécessite un script de compilation (comme node-gyp), autorisez-le explicitement dans un fichier .npmrc séparé ou via une liste blanche.

Complétez cette configuration avec une section overrides dans package.json pour forcer les versions des dépendances transitives vulnérables :

{
  "overrides": {
    "semver": ">=7.5.4",
    "tough-cookie": ">=4.1.3",
    "word-wrap": ">=1.2.4"
  }
}

Étape 7 : Automatiser en CI/CD

Chaque étape précédente n'a de valeur que si elle est exécutée systématiquement. L'automatisation en CI/CD transforme ces vérifications ponctuelles en portes de sécurité infranchissables. Voici un workflow GitHub Actions complet qui intègre les 6 étapes précédentes :

# .github/workflows/supply-chain-security.yml
name: Supply Chain Security

on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'
  push:
    branches: [main]
  schedule:
    - cron: '0 8 * * 1' # Chaque lundi à 8h

jobs:
  security-gates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      # Étape 1 : Vérification lockfile
      - name: Validate lockfile integrity
        run: |
          npm ci
          npx lockfile-lint --path package-lock.json \
            --type npm --allowed-hosts npm \
            --validate-https --validate-integrity

      # Étape 2 : Vérification signatures
      - name: Verify npm signatures
        run: npm audit signatures

      # Étape 3 : Analyse comportementale Socket
      - name: Socket security analysis
        uses: SocketDev/socket-security-action@v1
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

      # Étape 4 : Scan CVE
      - name: CVE scanning
        run: |
          npm audit --audit-level=high
          npx osv-scanner --lockfile=package-lock.json

      # Étape 5 : Génération SBOM
      - name: Generate SBOM
        run: |
          npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom.cdx.json

      # Notification en cas d'échec
      - name: Notify on failure
        if: failure()
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {"text": "⚠️ Security gate failed on ${{ github.repository }}"}
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Ce workflow s'exécute sur chaque pull request qui touche les dépendances, sur chaque push vers main, et chaque lundi matin pour détecter les nouvelles CVE publiées entre-temps. Si l'une des portes échoue, la PR ne peut pas être fusionnée.

La politique de notification est cruciale : ne vous contentez pas d'un badge rouge dans GitHub. Configurez une alerte Slack ou email immédiate pour que l'équipe sécurité puisse réagir dans l'heure.

Conclusion : la sécurité supply chain est un processus continu

Ces 7 étapes construisent une défense en profondeur qui aurait stoppé la majorité des attaques supply chain documentées en 2025-2026, y compris le compromis Injective Labs. Mais la sécurité n'est pas un état — c'est un processus. Mettez à jour vos outils régulièrement, surveillez les alertes Socket et osv-scanner, et revoyez vos politiques .npmrc trimestriellement.

La combinaison de ces approches — vérification d'intégrité, analyse comportementale, scan de vulnérabilités et traçabilité SBOM — représente l'état de l'art en matière de sécurité des dépendances JavaScript. Le coût d'implémentation est de 30 minutes. Le coût d'une attaque supply chain réussie se compte en centaines de milliers d'euros et en réputation détruite.

Pour aller plus loin, découvrez nos guides complémentaires sur l'audit approfondi des dépendances npm et la configuration d'un pare-feu de dépendances.

Questions fréquentes

Articles similaires

Sources

• • npm Documentation — npm audit signatures, provenance attestations (2024-2026)
• • Socket.dev — Documentation technique et analyse comportementale des packages
• • Sigstore — Keyless signing et provenance verification pour l'écosystème npm
• • CycloneDX — Spécification SBOM et outil @cyclonedx/cyclonedx-npm
• • OWASP Supply Chain Security — Top 10 CI/CD Security Risks (2025)
• • Google OSV — Open Source Vulnerability database et osv-scanner
• • European Commission — Cyber Resilience Act (CRA) et directive NIS2