# composer audit : vérifier les failles des dépendances

> Avec composer audit, vérifiez les failles de vos dépendances PHP : commandes, intégration CI et déploiement, et pourquoi PHP se corrige à part.

Source : https://phpsos.de/fr/ratgeber/composer-abhaengigkeiten-pruefen/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** `composer audit` compare les paquets de votre projet PHP avec les avis de sécurité connus et affiche les versions concernées. Exécutez la commande à chaque build et régulièrement sur l'état de production. Important après PHP2Shell : le contrôle porte sur les bibliothèques, pas sur l'interpréteur PHP lui-même.

## Pourquoi les dépendances demandent de l'attention précisément maintenant

Les applications PHP modernes se composent en grande partie de code tiers. Une boutique basée sur Symfony ou un portail avec Laravel embarque vite plusieurs dizaines, voire des centaines de paquets, beaucoup d'entre eux indirectement via d'autres paquets. Chacune de ces bibliothèques peut contenir une faille. L'OWASP Top 10 range donc les composants obsolètes et vulnérables dans une catégorie de risque à part.

En octobre 2026, PHP2Shell a montré à quelle vitesse une faille critique se propage. Les deux failles CVE-2026-109618 et CVE-2026-109619 concernent certes PHP lui-même et non les paquets Composer. Mais de nombreuses équipes ont alors vérifié toute leur chaîne et constaté qu'elles ne connaissaient pas précisément l'état de leurs dépendances.

Cette lacune dans la vue d'ensemble se comble sans grand effort. Composer fournit déjà l'outil adapté dans ses versions actuelles.

## Ce que composer audit vérifie et ce qu'il ne vérifie pas

La commande lit les paquets installés ou le fichier de verrouillage et interroge les avis de sécurité connus pour ces paquets. Pour chaque résultat, elle affiche le paquet, la plage de versions concernée, la gravité, l'identifiant de l'avis et un lien vers la description.

| Niveau | Vérifié par composer audit ? | Comment vérifier autrement |
|---|---|---|
| Paquets Composer du projet | oui | composer audit |
| Interpréteur PHP (p. ex. PHP2Shell) | non | État des paquets, confirmation de l'hébergeur |
| Extensions PHP du système | non | Gestion des paquets de la distribution |
| Paquets JavaScript du frontend | non | Outil du gestionnaire de paquets concerné |
| Code applicatif propre | non | Revue de code, audit de sécurité |

La commande prend aussi en compte les dépendances indirectes, c'est-à-dire des paquets que vous n'avez jamais demandés vous-même mais qui arrivent avec d'autres paquets. C'est précisément là que se trouvent souvent des failles inaperçues, parce que personne dans l'équipe ne connaît ces paquets. Les versions récentes de Composer signalent en outre les paquets que leurs auteurs ont marqués comme abandonnés. De tels paquets ne reçoivent en général plus de correctifs et devraient être remplacés.

Un résultat propre signifie donc seulement qu'aucun avis connu n'existe pour les versions de paquets installées. L'outil ne trouve ni les failles inconnues ni les erreurs dans votre propre code. La façon de vérifier vous-même l'état de PHP est décrite dans l'article [Vérifier correctement la version de PHP et l'état du correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/).

## Exécuter composer audit et lire les résultats

Dans le répertoire du projet, une seule commande suffit. Les variantes diffèrent par ce qui est vérifié et par la manière dont le résultat est présenté.

```bash
# Vérifier les paquets installés
composer audit

# Vérifier uniquement le fichier de verrouillage, p. ex. dans un build sans paquets installés
composer audit --locked

# Ignorer les dépendances de développement (état comme sur le serveur)
composer audit --no-dev

# Sortie lisible par machine pour l'analyse ou le système de tickets
composer audit --format=json > audit-$(date +%F).json
```

Si la commande trouve des failles, elle se termine avec un code d'erreur. C'est voulu, car un build automatisé s'interrompt ainsi. Évaluez chaque résultat : le paquet est-il utilisé sur le serveur, la fonction concernée est-elle utilisée, existe-t-il une version corrigée ?

```bash
# Quelles dépendances directes sont obsolètes ?
composer outdated --direct
# Pourquoi un paquet donné est-il installé ?
composer why vendor/paket
# Mettre à jour de façon ciblée, avec les dépendances
composer update vendor/paket --with-dependencies
```

Testez chaque mise à jour dans un environnement de préproduction. Les mises à jour de sécurité au sein de la même version majeure sont généralement sans risque, alors qu'une nouvelle version majeure peut exiger des adaptations du code.

## Automatiser le contrôle

Un appel unique aide peu, car de nouvelles failles sont connues en permanence. Intégrez donc `composer audit` à deux endroits : dans le pipeline de build à chaque modification et dans un contrôle régulier de l'état de production, même si le code ne change pas.

Un script simple pour une exécution quotidienne sur le serveur de build ou de contrôle peut ressembler à ceci :

```bash
#!/bin/sh
# Audit quotidien de l'état livré (adapter le chemin)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
  logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi
```

Transmettez le message du journal système à votre surveillance, à votre boîte de réception interne ou à votre système de tickets. Il est important que quelqu'un soit responsable de l'évaluation des messages. Un audit dont personne ne lit les avertissements ne protège pas.

> **Astuce:**
> Définissez dans `composer.json`, sous `config.platform.php`, la version de PHP qui tourne sur le serveur. Composer ne résout alors que des paquets compatibles avec cet état, et `composer check-platform-reqs` montre les écarts.

## Livrer proprement : un déploiement sans effets secondaires

Le chemin vers le serveur influence lui aussi la sécurité. Quelques règles de base ont fait leurs preuves :

- Inclure `composer.lock` dans le dépôt et n'exécuter sur le serveur que `composer install`, jamais `composer update`.
- Installer avec `--no-dev` afin que les outils de test et de débogage n'atterrissent pas sur le serveur de production.
- Garder le dossier `vendor/` en dehors de la racine web afin qu'il ne soit pas directement accessible par une URL.
- Exécuter `composer validate` dans le build pour détecter tôt des indications erronées ou contradictoires.

```bash
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
```

Soyez en outre attentif à la prise en charge de la version de PHP elle-même. Les bibliothèques exigent de plus en plus des branches PHP récentes. Qui reste bloqué sur PHP 8.1 ou antérieur ne reçoit plus de mises à jour officielles pour PHP lui-même et ne peut souvent plus installer les versions de paquets plus récentes contenant des correctifs de sécurité. La planification correspondante est décrite dans le guide [Fin de vie de PHP : les risques des versions obsolètes](https://phpsos.de/fr/ratgeber/php-end-of-life-risiken/). Des indications spécifiques aux frameworks figurent sous [Sécuriser les applications Laravel](https://phpsos.de/fr/plattformen/laravel/).

## Comment PHP SOS aide-t-il concrètement ?

- Nous recensons l'état de toutes les dépendances et évaluons les résultats selon l'utilisation réelle.
- Nous mettons en place des contrôles automatisés dans le build et en exploitation, avec une responsabilité claire pour les constats.
- Nous planifions et testons les mises à jour, même lorsque de nouvelles versions majeures exigent des adaptations.
- Sur demande, nous vérifions aussi le code propre et la configuration, là où aucun outil automatique ne regarde.

Une vérification par des tiers est décrite par la prestation [Audit de sécurité et test d'intrusion](https://phpsos.de/fr/leistungen/sicherheitsaudit-penetrationstest/).


## Questions fréquentes

**composer audit trouve-t-il aussi PHP2Shell ?**  
Non. composer audit vérifie les paquets de votre projet, pas l'interpréteur PHP du serveur. PHP2Shell se trouve dans PHP lui-même et n'est corrigée que par une mise à jour de PHP et un redémarrage de tous les processus PHP.

**composer.lock doit-il figurer dans le dépôt ?**  
Pour les applications, oui. Le fichier de verrouillage consigne les versions exactes installées. C'est seulement ainsi que composer audit contrôle l'état qui tourne réellement sur le serveur, et chaque déploiement installe les mêmes versions.

**Que faire si aucune mise à jour n'existe pour un paquet concerné ?**  
Vérifiez si votre projet utilise réellement la fonction concernée et documentez l'évaluation. S'il n'existe pas de correctif, un paquet de remplacement, un correctif maison ou une protection temporaire au niveau du serveur entrent en ligne de compte.

**À quelle fréquence dois-je exécuter composer audit ?**  
À chaque build et, en plus, régulièrement, par exemple chaque jour, même sans modification du code. De nouvelles failles sont signalées en permanence, et un état sain hier peut être concerné aujourd'hui.

## Sources

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net : avis de sécurité](https://www.php.net/)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)