Auditer les dépendances Composer et npm d’un projet WordPress

Un projet client construit avec un thème sur mesure et quelques extensions maison compilait ses assets via un package.json vieux de deux ans, jamais retouché depuis la mise en production initiale. En creusant le package-lock.json, nous avons compté cent trente-quatre paquets npm, dont une bonne partie de dépendances transitives que personne dans l’équipe ne pouvait nommer. Une seule d’entre elles portait une vulnérabilité critique connue depuis plusieurs mois.

Un projet WordPress moderne ne se limite plus au cœur et aux extensions installées depuis le tableau de bord : dès qu’un thème ou une extension maison utilise Composer pour ses dépendances PHP, ou npm pour sa chaîne de build front-end, ces dépendances deviennent une surface d’attaque à part entière, souvent négligée car invisible depuis l’administration WordPress.

Pourquoi ces dépendances échappent souvent à la veille classique

Les outils de veille spécialisés WordPress (WPScan, Patchstack) surveillent le cœur, les thèmes et les extensions publiés sur le répertoire officiel ou signalés par leurs éditeurs. Ils ne couvrent en revanche pas les paquets Composer ou npm utilisés en interne dans le code d’un thème ou d’une extension maison, qui suivent leur propre écosystème de vulnérabilités, distinct de celui de WordPress.

Auditer les dépendances Composer

Composer intègre une commande d’audit native depuis la version 2.4, qui interroge la base de données publique des avis de sécurité PHP (l’API FriendsOfPHP Security Advisories) pour vérifier chaque paquet du composer.lock :

composer audit

La sortie liste chaque paquet vulnérable trouvé, avec la version installée, la plage de versions affectées et un lien vers l’avis détaillé. Sur un projet volumineux, il est utile de restreindre la sortie aux paquets réellement utilisés en production, en excluant les dépendances de développement :

composer audit --no-dev

Il faut noter que composer audit se base sur le fichier verrouillé, pas sur ce qui pourrait être installé en théorie : lancer la commande après chaque composer update, et pas seulement de façon ponctuelle, garantit qu’elle reflète l’état réel du projet.

Auditer les dépendances npm

Côté JavaScript, la commande équivalente existe nativement dans npm depuis plusieurs années :

npm audit

Cette commande interroge la base de données de sécurité npm et retourne un résumé par niveau de gravité (faible, modéré, élevé, critique), avec le chemin de dépendance qui introduit chaque paquet vulnérable. Sur un projet front-end WordPress typique (compilation de blocs Gutenberg, bundler pour un thème), l’essentiel des alertes concerne souvent des dépendances de développement (outils de build) sans impact en production, ce qu’il faut distinguer avant de paniquer :

npm audit --omit=dev

La commande npm audit fix tente une correction automatique en mettant à jour les paquets vers une version corrigée compatible avec les contraintes de version déclarées, mais elle mérite toujours une vérification manuelle des changements pour éviter une régression silencieuse d’une dépendance de build.

Automatiser la veille avec Dependabot

Sur un dépôt hébergé sur GitHub, l’activation de Dependabot permet d’automatiser cette veille sans y penser à chaque fois. Un simple fichier de configuration déclare les écosystèmes à surveiller :

version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot ouvre alors automatiquement une pull request dès qu’une vulnérabilité connue touche une dépendance du projet, avec le détail de l’avis et, quand c’est possible, la mise à jour déjà appliquée dans la branche proposée.

Trier les alertes réellement exploitables

Toutes les alertes remontées ne se valent pas. Trois questions permettent de prioriser efficacement un lot d’alertes sur un projet chargé :

• Le paquet vulnérable est-il utilisé en production, ou uniquement dans la chaîne de build (webpack, outils de lint) sans exposition directe aux visiteurs ?
• La fonction vulnérable du paquet est-elle réellement appelée dans le code du projet, ou le paquet est-il présent sans que cette fonctionnalité précise soit utilisée ?
• Une mise à jour existe-t-elle sans rupture de compatibilité, ou faut-il évaluer un remplacement du paquet si le mainteneur a abandonné le projet ?

Intégrer l’audit dans le flux de déploiement

Sur les projets où nous avons une intégration continue, composer audit et npm audit --omit=dev tournent à chaque build, avec un seuil qui bloque le déploiement en cas de vulnérabilité critique nouvellement détectée. Ce garde-fou évite qu’une dépendance vulnérable ne se glisse en production entre deux revues manuelles espacées de plusieurs semaines.

Notre règle sur les projets sensibles : toute dépendance ajoutée doit être justifiée dans la pull request qui l’introduit. Ça ralentit un peu les ajouts impulsifs de paquets, mais ça évite l’accumulation de dépendances fantômes qu’on retrouve deux ans plus tard sans savoir pourquoi elles sont là.

En résumé

La sécurité d’un projet WordPress moderne ne s’arrête pas à ses extensions : les dépendances Composer et npm qui alimentent son code sur mesure portent leurs propres vulnérabilités, invisibles depuis le tableau de bord WordPress. composer audit, npm audit et une automatisation via Dependabot forment une routine simple à mettre en place et à intégrer dans un pipeline de déploiement, pour une surface d’attaque qui reste sinon largement hors radar.