# Geler une dépendance Composer vulnérable en attendant un correctif amont

> Un composer.lock figé sur une version connue vulnérable expose un projet plus longtemps que nécessaire faute de suivi. Méthode de veille et de contournement temporaire.

- Auteur : WordPress Développement
- Publié le : 2023-05-15
- Mis à jour le : 2023-05-15
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/geler-dependance-composer-vulnerable-correctif/

## L’essentiel

- composer audit révèle les vulnérabilités connues du lock file
- Un contournement temporaire limite l'exposition sans casser la compatibilité
- Une date de relance évite d'oublier la dépendance figée

`composer audit`, lancée sur une extension qui embarque une dizaine de dépendances tierces via Composer, retourne parfois un résultat qu'on préférerait ne pas voir : une bibliothèque de traitement d'images utilisée pour générer des vignettes personnalisées est listée avec une vulnérabilité connue, référencée par un identifiant CVE, et corrigée dans une version plus récente que celle figée dans le `composer.lock` du projet.

La réaction naturelle, mettre à jour immédiatement vers la dernière version, se heurte parfois à un obstacle concret : la nouvelle version majeure de la bibliothèque a changé sa signature d'API, et la migrer proprement demande plus de temps qu'une simple exécution de `composer update`. Entre le moment où la faille est connue et celui où la migration complète peut être livrée, il faut une stratégie intermédiaire.

## Confirmer l'exposition réelle

Avant de paniquer, il faut vérifier si le projet utilise réellement le code concerné par la vulnérabilité. Une CVE affectant une fonction de conversion de format d'image spécifique ne concerne pas un projet qui n'utilise la bibliothèque que pour le redimensionnement simple. La commande `composer audit` signale la présence de la version vulnérable dans l'arbre de dépendances, mais ne sait pas si le code vulnérable est réellement exécuté par le projet.

Cette vérification passe par la lecture de l'avis de sécurité associé à la CVE, généralement disponible sur la base de données GitHub Advisory ou sur le dépôt officiel de la bibliothèque, pour identifier précisément la fonction ou le point d'entrée concerné.

## Le contournement temporaire

> L'essentiel à retenir : composer audit révèle les vulnérabilités connues du lock file ; Un contournement temporaire limite l'exposition sans casser la compatibilité ; Une date de relance évite d'oublier la dépendance figée

Quand la migration complète ne peut pas être livrée immédiatement, trois options de contournement existent, du plus simple au plus engageant :

1. **Désactiver la fonctionnalité concernée** si elle est secondaire, le temps de la migration, plutôt que de laisser un code vulnérable actif en production.
2. **Appliquer un correctif de contournement en surcouche**, par exemple en validant plus strictement les entrées avant qu'elles n'atteignent la fonction vulnérable, si l'avis de sécurité documente précisément le vecteur d'attaque.
3. **Épingler une version intermédiaire** si le mainteneur a publié un correctif rétroporté sur une branche mineure compatible, sans nécessiter la migration majeure complète.

```
{
    "require": {
        "acme/traitement-image": "~2.4.3"
    }
}
```

Cette contrainte Composer épingle la dépendance sur la version `2.4.3` ou toute version de correctif suivante dans la branche `2.4`, sans risquer une montée automatique vers la branche `2.5` qui casserait la compatibilité. C'est un geste de gel volontaire et documenté, différent d'un oubli de mise à jour.

## Documenter le geste et sa date de relance

Le vrai risque d'un contournement temporaire n'est pas sa mise en place, mais son oubli. Un fichier de suivi dans le dépôt du projet, même sommaire, évite qu'une contrainte de version posée en urgence reste en place indéfiniment :

```
# SECURITY-WATCH.md

## acme/traitement-image

- CVE-2023-XXXXX, corrigée en version 3.0.0
- Contournement : validation renforcée des entrées, voir Validateur.php
- Contrainte composer.json : ~2.4.3
- Migration vers 3.x planifiée : sprint de juin 2023
- Relance de suivi : 2023-06-01
```

Cette trace, même minimale, transforme une rustine improvisée en décision technique assumée, traçable et bornée dans le temps.

## Mettre en place une veille continue

Attendre de tomber par hasard sur une CVE en exécutant `composer audit` manuellement n'est pas une stratégie fiable. Intégrer cette commande à l'intégration continue du projet, avec un échec de build en cas de vulnérabilité critique détectée, transforme la veille en processus automatique :

- Ajouter `composer audit --locked` comme étape du pipeline d'intégration continue, avant chaque déploiement.
- Configurer une alerte automatique (via l'outil de sécurité du dépôt Git, quand il en propose une) plutôt que de compter sur une vérification manuelle périodique.
- Revoir la liste des contournements temporaires en cours à intervalle fixe, par exemple à chaque début de sprint.

> Un principe que j'applique strictement sur les projets que je maintiens : une vulnérabilité confirmée sur une dépendance activement utilisée en production ne tolère aucun délai avant qu'une décision, même provisoire, ne soit prise et documentée.

## Notre verdict

Geler une dépendance vulnérable n'est jamais la solution finale, seulement un pont vers la migration réelle. Ce pont ne vaut que s'il est documenté, borné dans le temps et revisité, faute de quoi le contournement d'urgence devient la nouvelle normalité silencieuse du projet, exposé sans que personne ne s'en souvienne.