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
Quand la migration complète ne peut pas être livrée immédiatement, trois options de contournement existent, du plus simple au plus engageant :
- 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.
- 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.
- É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-01Cette 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 --lockedcomme é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.
