Contrairement à un audit de dépendances mené une fois par trimestre lors d’une revue de sécurité planifiée, un pipeline de déploiement continu peut intégrer cette vérification à chaque mise en production, ce qui réduit le délai entre la divulgation d’une vulnérabilité et sa détection sur le projet à quelques minutes plutôt qu’à plusieurs semaines. Cette différence compte particulièrement pour des dépendances largement utilisées, où une vulnérabilité divulguée publiquement peut être exploitée en masse dans les jours qui suivent sa publication.
L’architecture décrite ici s’appuie sur deux outils déjà présents dans l’écosystème PHP et JavaScript — composer audit et npm audit — intégrés comme étape bloquante d’un pipeline de déploiement, plutôt qu’exécutés manuellement et de façon isolée.
Principe : une étape de vérification avant toute autre étape de déploiement
L’architecture repose sur un ordre strict des étapes : la vérification des dépendances doit s’exécuter avant la construction des assets et avant tout déploiement effectif, de façon à interrompre le pipeline avant que du code potentiellement vulnérable n’atteigne la production. Un déploiement qui construirait d’abord, puis vérifierait ensuite, perd l’essentiel de l’intérêt de l’automatisation : le mal est déjà fait au moment où l’alerte remonte.
Arborescence d’un pipeline type
.github/workflows/deploiement.yml
├── job: verifier-dependances
│ ├── composer audit --locked
│ └── npm audit --audit-level=high
├── job: construire (dépend de verifier-dependances)
│ ├── composer install --no-dev --optimize-autoloader
│ └── npm run build
└── job: deployer (dépend de construire)
└── rsync vers le serveur de production
Configurer le blocage sans excès de rigidité
Un pipeline trop strict, qui bloque au moindre avertissement de sévérité mineure, finit par être contourné ou désactivé par l’équipe qui le juge trop bruyant. Le seuil de blocage doit être calibré pour interrompre le déploiement uniquement sur des vulnérabilités de sévérité élevée ou critique, tout en laissant remonter les avertissements de sévérité moindre sous forme de rapport consultable sans bloquer la mise en production :
name: verifier-dependances
on: [push]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- run: composer install --no-interaction
- name: Audit Composer (bloquant)
run: composer audit
- name: Audit npm (bloquant au-delà de high)
run: npm audit --audit-level=high
Gérer les faux positifs sans désactiver la vérification
Une dépendance signalée vulnérable mais dont le code affecté n’est jamais réellement exécuté par le projet (une fonction non appelée, une configuration non utilisée) reste un cas fréquent qui frustre les équipes si le pipeline bloque sans distinction. composer audit permet d’ignorer explicitement une alerte identifiée, avec justification, via un fichier composer-audit-exclude.json ou l’option --ignore selon la version installée, plutôt que de désactiver l’audit dans son ensemble.
- Documenter chaque exclusion avec la raison précise et une date de réexamen
- Réexaminer les exclusions à échéance régulière, une dépendance ignorée pouvant devenir réellement exploitée par un changement ultérieur du code
- Ne jamais exclure une vulnérabilité simplement parce qu’elle bloque un déploiement urgent
Notifier sans dépendre uniquement du pipeline
Un pipeline bloqué reste invisible tant que personne ne consulte l’historique des exécutions. Ajouter une notification explicite — message vers un canal de discussion d’équipe, email à la personne responsable du déploiement — au moment où le job d’audit échoue garantit que l’alerte est traitée rapidement plutôt que découverte fortuitement plusieurs jours après.
Étendre le principe aux extensions WordPress elles-mêmes
Ce même principe d’automatisation peut s’étendre, dans une certaine mesure, aux extensions WordPress installées via Composer avec un dépôt compatible, en croisant leur version avec une base de vulnérabilités connues comme celle proposée par certains services de veille spécialisés dans l’écosystème WordPress, en complément de composer audit qui couvre principalement les bibliothèques PHP génériques.
En résumé
Automatiser la revue de dépendances directement dans le pipeline de déploiement, en position bloquante avant toute mise en production, réduit considérablement le délai d’exposition par rapport à un audit manuel périodique. La réussite de cette architecture dépend moins de l’outillage choisi que de la calibration du seuil de blocage et de la discipline à documenter et réexaminer chaque exclusion accordée.
