Comment securiser sa supply chain npm en 9 etapes en 2026

En aout 2026, un ver npm a compromis 400+ paquets en 48 heures, touchant 2 500 organisations et 434 000 pipelines CI/CD. L’attaque sur keyv et cacheable a demontre que les mecanismes de protection traditionnels — lockfiles, audit, provenance — ne suffisent plus individuellement. La securite de la supply chain npm est desormais un probleme de defense en profondeur : chaque couche de protection doit etre deployee, car aucune n’est suffisante seule. Ce guide vous donne 9 etapes actionnables, avec des exemples de code et des fichiers de configuration prets a copier-coller.

Ce guide s’adresse aux developpeurs JavaScript/TypeScript individuels comme aux tech leads responsables de la securite d’une equipe. Chaque etape est independante — vous pouvez les implementer dans l’ordre ou sauter directement a celles qui manquent dans votre configuration actuelle. Prevoyez 4 a 6 heures pour l’implementation complete.

Etape 1 : Verrouiller strictement chaque dependance avec le lockfile

Le lockfile (package-lock.json) est votre premiere ligne de defense. Il enregistre la version exacte de chaque dependance — directe et transitive — avec son hash d’integrite. Mais beaucoup d’equipes ne l’utilisent pas correctement : elles executent npm install au lieu de npm ci, ce qui permet a npm de modifier le lockfile et d’installer des versions plus recentes.

Actions concretes :

1. Utilisez toujours npm ci en CI/CD et sur les postes developpeur quand vous voulez un build reproductible. npm ci refuse de modifier le lockfile — il echoue si le lockfile est desynchronise du package.json.
2. Commitez package-lock.json dans votre depot Git. Ne l’ajoutez jamais dans .gitignore.
3. Ajoutez des versions exactes dans package.json au lieu de ranges : "keyv": "5.2.3" au lieu de "^5.2.3".
4. Configurez save-exact=true dans votre .npmrc pour que chaque npm install <paquet> ajoute automatiquement la version exacte.

# .npmrc - Configuration de securite
save-exact=true
package-lock=true

# Forcer npm ci dans les scripts CI/CD
# Jenkinsfile / GitHub Actions / GitLab CI :
# npm ci --prefer-offline

# Verifier l'integrite du lockfile
npm ci --audit=false  # audit separe en etape 3

Etape 2 : Desactiver les scripts d’installation par defaut

Les scripts preinstall, install et postinstall de npm s’executent automatiquement lors de chaque npm install. C’est exactement le vecteur exploite par l’attaque keyv : le hook preinstall executait setup.mjs qui telechargeait et lancait le payload de 728 Ko. La desactivation par defaut de ces scripts bloque ce vecteur d’attaque a la source.

Actions concretes :

1. Ajoutez ignore-scripts=true dans votre .npmrc projet et global.
2. Creez un script postinstall-safe.sh pour les paquets qui necessitent des scripts d’installation legitimes (sharp, bcrypt, sqlite3).
3. Ajoutez ce script dans votre package.json : "postinstall": "bash postinstall-safe.sh".

# .npmrc - Ajouter a la configuration existante
ignore-scripts=true

# postinstall-safe.sh - Allowlist de paquets de confiance
#!/bin/bash
# Seuls ces paquets sont autorises a executer des scripts
ALLOWED_PACKAGES=("sharp" "bcrypt" "sqlite3" "canvas")

for pkg in "${ALLOWED_PACKAGES[@]}"; do
  if [ -d "node_modules/$pkg" ]; then
    echo "Running install script for trusted package: $pkg"
    cd "node_modules/$pkg" && npm run install --if-present && cd ../..
  fi
done

Cette approche offre le meilleur compromis : blocage par defaut avec exceptions explicites et auditables. Chaque paquet ajoute a l’allowlist doit etre justifie et documente. C’est la difference entre une politique de securite permissive (tout est autorise sauf ce qui est interdit) et restrictive (tout est interdit sauf ce qui est autorise).

Etape 3 : Auditer les dependances en continu

L’audit des dependances doit etre automatise et continu — pas un exercice ponctuel. Combinez npm audit pour les CVE connues avec des outils specialises dans la detection d’attaques supply chain.

Actions concretes :

1. Executez npm audit --audit-level=moderate dans chaque build CI/CD. Faites echouer le build si des vulnerabilites moderees ou superieures sont detectees.
2. Installez Socket.dev (gratuit pour open source) pour detecter les paquets avec des comportements suspects : scripts d’installation, acces reseau, acces au systeme de fichiers hors du repertoire du paquet.
3. Configurez Dependabot ou Renovate pour les mises a jour automatiques avec review obligatoire.
4. Ajoutez npx lockfile-lint dans votre CI pour detecter les modifications non autorisees du lockfile.

# .github/workflows/security-audit.yml
name: Security Audit
on:
  push:
    paths: ['package-lock.json', 'package.json']
  schedule:
    - cron: '0 8 * * 1'  # Chaque lundi 8h

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm audit --audit-level=moderate
      - run: npx lockfile-lint --path package-lock.json \
              --type npm --allowed-hosts npm \
              --validate-https --validate-integrity

Pour les equipes francaises soumises a NIS2, l’audit continu des dependances est un prerequis de conformite. Notre guide sur la securisation des dependances npm detaille les procedures d’audit avancees.

Etape 4 : Verifier la provenance des paquets

La provenance npm, basee sur Sigstore, atteste que le paquet a ete construit par un workflow CI/CD identifie a partir d’un depot source specifique. C’est une couche de securite importante, mais attention : l’attaque keyv a demontre que la provenance ne protege pas contre un code source corrompu commite par un compte compromis. Elle reste cependant necessaire comme element de tracabilite.

Actions concretes :

1. Executez npm audit signatures pour verifier que les paquets installes ont une provenance valide.
2. Ajoutez la verification de provenance dans votre CI/CD.
3. Si vous publiez des paquets npm, activez la provenance dans votre workflow de publication avec --provenance.

# Verifier les signatures de provenance
npm audit signatures

# Publier avec provenance (dans votre workflow CI/CD)
npm publish --provenance --access public

# .github/workflows/publish.yml - Ajouter les permissions
permissions:
  id-token: write  # Necessaire pour la provenance Sigstore
  contents: read

Etape 5 : Generer et archiver un SBOM a chaque build

Le Software Bill of Materials (SBOM) est un inventaire complet de toutes les dependances de votre application. La directive NIS2, transposee en droit francais, impose aux entites essentielles de maintenir un inventaire a jour de leurs composants logiciels. Au-dela de la conformite, le SBOM est un outil operationnel precieux lors d’un incident : il permet d’identifier en quelques secondes si un paquet compromis est present dans vos applications.

Actions concretes :

1. Generez un SBOM CycloneDX a chaque build de production.
2. Archivez le SBOM avec le numero de build et la date.
3. Ajoutez une etape de scan du SBOM contre les bases de vulnerabilites connues.

# Generer un SBOM CycloneDX
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Archiver avec le build
BUILD_ID=$(git rev-parse --short HEAD)
cp sbom.cdx.json "artifacts/sbom-$BUILD_ID-$(date +%Y%m%d).cdx.json"

# Scanner le SBOM contre les vulnerabilites (optionnel, avec grype)
grype sbom:sbom.cdx.json --fail-on medium

Le format CycloneDX est recommande par l’ANSSI et l’OWASP. Il est plus riche que le format SPDX pour les dependances npm et supporte les informations de provenance et de vulnerabilites. Notre article sur la conformite NIS2 pour les PME detaille les obligations specifiques concernant l’inventaire logiciel.

Etape 6 : Configurer les branch protection rules et les environnements de deploiement

L’attaque keyv a exploite un workflow GitHub Actions qui publiait automatiquement sur npm lors d’un tag push, sans aucune revue humaine. La solution est double : branch protection rules pour empecher les commits non revus sur la branche principale, et environnements de deploiement pour ajouter une approbation manuelle avant toute publication.

Actions concretes :

1. Activez les branch protection rules sur la branche main : required reviews (minimum 1), required status checks, dismiss stale reviews.
2. Creez un environnement de deploiement npm-publish dans les parametres du depot GitHub avec required reviewers.
3. Modifiez votre workflow de publication pour utiliser cet environnement.
4. Activez signed commits si possible (GPG ou SSH signing).

# .github/workflows/publish.yml - Avec environnement de deploiement
name: Publish to npm
on:
  push:
    tags: ['v*']

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: npm-publish  # Requiert approbation manuelle
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm test
      - run: npm publish --provenance --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

L’ajout de l’environnement npm-publish avec des reviewers requis signifie qu’un humain doit approuver chaque publication dans l’interface GitHub avant que le workflow ne s’execute. C’est un compromis minime en termes de velocite — quelques minutes de delai — pour un gain de securite considerable. Consultez notre guide sur la securisation des pipelines CI/CD pour une configuration detaillee.

Etape 7 : Utiliser des secrets a duree de vie courte

Le payload de l’attaque keyv ciblait les credentials a longue duree de vie : tokens npm permanents, cles SSH sans expiration, credentials AWS statiques. La parade est structurelle : remplacer ces secrets permanents par des secrets ephemeres qui expirent automatiquement.

Actions concretes :

1. Tokens npm : utilisez des tokens granulaires (scoped) avec expiration. Creez un token dedie par pipeline CI/CD avec les permissions minimales.
2. AWS : utilisez AWS SSO ou IAM Identity Center pour des sessions temporaires au lieu de credentials statiques. Duree de vie recommandee : 1 heure.
3. Kubernetes : configurez des kubeconfigs avec des tokens OIDC a courte duree de vie. Ne stockez jamais un kubeconfig permanent sur un poste de developpement.
4. SSH : utilisez des certificats SSH avec expiration (SSH Certificate Authority) au lieu de cles SSH permanentes.

# Creer un token npm granulaire avec expiration (via CLI)
npm token create --cidr=0.0.0.0/0 --read-only

# AWS : configurer des sessions temporaires
aws sso login --profile dev
# Le token expire automatiquement apres 1h

# Kubernetes : utiliser un kubeconfig OIDC
# Dans ~/.kube/config, remplacer les tokens statiques par :
# user:
#   exec:
#     apiVersion: client.authentication.k8s.io/v1beta1
#     command: aws
#     args: ["eks", "get-token", "--cluster-name", "my-cluster"]

La regle d’or : si un secret peut etre vole et utilise indefiniment, il est trop puissant. Chaque secret devrait avoir une duree de vie la plus courte possible, des permissions les plus restreintes possibles, et un perimetre d’utilisation le plus etroit possible.

Etape 8 : Mettre en place un monitoring en temps reel

La detection precoce est critique. L’attaque keyv a eu une fenetre d’exposition de plus de 19 heures avant la premiere alerte publique. Un monitoring proactif aurait pu reduire cette fenetre a quelques minutes.

Actions concretes :

1. Configurez des alertes Socket.dev ou Snyk sur vos depots pour etre notifie en temps reel de toute nouvelle vulnerabilite ou publication suspecte dans vos dependances.
2. Surveillez les publications npm de vos propres paquets : un npm publish non declenche par votre equipe est un indicateur de compromission immediat.
3. Ajoutez un monitoring reseau sur vos serveurs de build pour detecter les connexions sortantes suspectes (vers des noeuds RPC Ethereum, des domaines inconnus, etc.).
4. Configurez des alertes GitHub pour les connexions suspectes sur les comptes mainteneurs.

Le monitoring doit couvrir trois niveaux : les dependances directes (celles que vous listez dans package.json), les dependances transitives (celles que vos dependances installent), et les publications de vos propres paquets. L’attaque keyv a demontre que le danger vient souvent des dependances transitives — flat-cache et file-entry-cache sont des dependances transitives d’ESLint que la plupart des developpeurs ne connaissent meme pas.

Etape 9 : Formaliser une politique de securite d’equipe

Les 8 etapes precedentes sont techniques. Cette derniere etape est organisationnelle — et c’est souvent celle qui fait la difference entre une equipe resiliente et une equipe vulnerable. Une politique formalisee garantit que les pratiques sont maintenues dans le temps, meme quand les personnes changent.

Elements de la politique :

1. Processus d’ajout de dependance : chaque nouvelle dependance npm doit etre revue par au moins un membre de l’equipe securite. Verifications : mainteneur actif, nombre de dependances, presence de scripts d’installation, provenance, licence.
2. Processus de mise a jour : les mises a jour de securite sont appliquees dans les 48 heures. Les mises a jour fonctionnelles suivent le cycle de release normal.
3. Procedure d’incident supply chain : qui fait quoi quand un paquet compromis est detecte. Roles, responsabilites, canaux de communication, checklist d’actions immediates.
4. Formation continue : session trimestrielle de 1 heure sur les derniers incidents supply chain et les bonnes pratiques. Les articles de ce blog peuvent servir de support.
5. Audit periodique : audit trimestriel de l’ensemble de l’arbre de dependances, de la configuration CI/CD et des acces mainteneur.

# Exemple de checklist d'ajout de dependance
## Nouvelle dependance : [nom-du-paquet]

- [ ] Mainteneur actif (dernier commit < 6 mois)
- [ ] Nombre de dependances raisonnable (< 20 directes)
- [ ] Pas de scripts preinstall/install/postinstall
- [ ] Provenance npm verifiable (npm audit signatures)
- [ ] Licence compatible (MIT, Apache-2.0, ISC)
- [ ] Pas d'alternative deja presente dans le projet
- [ ] Review par un pair
- [ ] Date d'ajout : ___
- [ ] Responsable : ___

Documentez cette politique dans un fichier SECURITY.md a la racine de chaque depot. Rendez-la accessible et revoyez-la apres chaque incident majeur. L’attaque keyv d’aout 2026 est un bon declencheur pour une revue complete.

Conclusion : la securite supply chain est un investissement continu

Les 9 etapes de ce guide ne sont pas un exercice ponctuel — c’est un changement de posture. En 2026, la supply chain npm est un vecteur d’attaque de premier ordre. L’attaque sur keyv a demontre que les protections individuelles (lockfile, provenance, audit) sont insuffisantes isolement. Seule la superposition de 9 couches de defense offre une resilience reelle.

Le cout d’implementation est modeste : 4 a 6 heures pour un projet, une journee pour une equipe. Le cout d’un incident supply chain — rotation de tous les secrets, notification NIS2, audit forensique, perte de confiance des clients — est incomparablement plus eleve. L’investissement est justifie par le premier incident qu’il previent.

Commencez aujourd’hui par les trois premieres etapes : lockfile strict, ignore-scripts et audit des dependances. Elles prennent moins d’une heure et offrent un gain de securite immediat. Puis planifiez les six suivantes sur les deux prochaines semaines.

Questions frequentes

Articles connexes