Sécuriser ses dépendances Composer et npm en 2026 : la checklist anti-supply chain

Votre code n'est qu'une petite partie de ce que vous déployez. Un projet Laravel avec Vite embarque facilement des centaines de dépendances Composer et npm, écrites par des milliers de contributeurs. Les attaques supply chain — compromettre un package pour atteindre tous ses utilisateurs — se sont multipliées, comme l'a montré l'incident autour d'Axios et npm. Voici une checklist en dix points pour réduire ce risque.

Bloc 1 : savoir ce que vous installez

1. Versionner les fichiers de verrouillage

composer.lock et package-lock.json doivent être commités. Ils figent les versions exactes et leurs empreintes. En production et en CI, installez uniquement depuis le lockfile :

composer install --no-dev --prefer-dist --no-interaction
npm ci

npm ci échoue si package.json et le lockfile divergent, au lieu de résoudre silencieusement de nouvelles versions comme npm install.

2. Auditer les vulnérabilités connues

composer audit
npm audit --omit=dev

composer audit interroge la base d'avis de sécurité de Packagist ; Composer peut aussi bloquer l'installation de versions vulnérables connues. Lancez ces commandes en CI et faites échouer le build sur les vulnérabilités hautes et critiques.

3. Limiter le nombre de dépendances

Avant d'ajouter un package pour une fonction de dix lignes, posez la question. Chaque dépendance supplémentaire est un mainteneur de plus à qui vous faites confiance. Faites régulièrement le ménage avec composer why et npm ls.

Bloc 2 : réduire la surface d'attaque à l'installation

4. Se méfier des scripts d'installation npm

Les scripts postinstall s'exécutent automatiquement sur votre machine et en CI : c'est le vecteur favori des packages malveillants. En CI, envisagez npm ci --ignore-scripts, puis exécutez explicitement les seuls scripts nécessaires.

5. Contrôler les plugins Composer

Depuis Composer 2.2, les plugins doivent être explicitement autorisés dans config.allow-plugins. Ne répondez pas « oui » machinalement : n'autorisez que les plugins que vous connaissez.

6. Attention au typosquatting

Vérifiez le nom exact du package, son éditeur, son nombre de téléchargements et la date de sa dernière version. laravel/sanctum n'est pas laravell/sanctum. Méfiez-vous aussi des packages suggérés par une IA : vérifiez qu'ils existent et sont maintenus avant de les installer.

Bloc 3 : automatiser la vigilance

7. Activer Dependabot ou Renovate

Ces outils ouvrent automatiquement des pull requests de mise à jour et signalent les failles. Exemple de configuration Dependabot :

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      dev-dependencies:
        dependency-type: "development"

8. Ajouter un délai avant d'adopter une nouvelle version

La plupart des versions malveillantes sont détectées et retirées en quelques jours. Ne pas installer une version publiée il y a quelques heures — sauf correctif de sécurité urgent — réduit nettement le risque. Renovate propose une option minimumReleaseAge pour cela.

9. Protéger les secrets de la CI

Un package compromis cherche d'abord vos variables d'environnement. Dans GitHub Actions, limitez les permissions du GITHUB_TOKEN (permissions: contents: read), n'exposez les secrets de déploiement qu'au job de déploiement et épinglez les actions tierces sur un SHA de commit. Notre guide de déploiement Laravel avec GitHub Actions détaille cette séparation.

10. Surveiller ce qui tourne en production

Une faille découverte demain touchera du code déjà déployé. Tenez un inventaire des versions en production (le lockfile suffit) et abonnez-vous aux avis de sécurité de vos dépendances critiques : framework, authentification, upload de fichiers, PHP lui-même — comme l'ont rappelé les failles PHP récemment ajoutées au catalogue CISA KEV.

Le job CI minimal

- name: Dépendances PHP
  run: composer install --no-interaction --prefer-dist
- name: Audit PHP
  run: composer audit --no-dev
- name: Dépendances JS
  run: npm ci --ignore-scripts
- name: Audit JS
  run: npm audit --omit=dev --audit-level=high

Conclusion

La sécurité des dépendances ne demande pas d'outil coûteux : des lockfiles respectés, des audits automatiques, des mises à jour régulières mais pas précipitées, et une CI qui protège ses secrets. Mettez ces dix points en place une fois, et chaque projet en bénéficiera.