# Auditer les dépendances Composer et npm d’un projet WordPress > Un projet WordPress moderne embarque souvent des dizaines de paquets Composer et npm en coulisses. Sans audit régulier, une vulnérabilité peut y dormir des mois. - Auteur : Clément Hadrot - Publié le : 2024-07-11 - Mis à jour le : 2024-07-11 - Catégorie : Sécurité - URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/auditer-dependances-composer-npm-projet-wordpress/ ## L’essentiel - composer audit et npm audit détectent les vulnérabilités connues - Toute alerte n'est pas exploitable dans votre contexte - Dependabot automatise la veille en continu 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 > L'essentiel à retenir : composer audit et npm audit détectent les vulnérabilités connues ; Toute alerte n'est pas exploitable dans votre contexte ; Dependabot automatise la veille en continu 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.