npm audit vérifie les vulnérabilités connues d’un paquet ; aucun outil équivalent ne vérifie par défaut qu’une extension WordPress respecte le règlement sur la cyber-résilience (Cyber Resilience Act). Ce texte européen impose aux fabricants de produits comportant des éléments numériques des obligations précises : gestion documentée des vulnérabilités, mise à disposition de mises à jour de sécurité, information claire en cas de faille exploitée. Pour une agence qui intègre des dizaines d’extensions tierces sur ses projets, la question posée par un client exigeant s’est révélée simple à formuler et compliquée à vérifier : comment prouver que chaque dépendance ajoutée au projet respecte ces obligations ?
Plutôt que de confier cette vérification à une revue manuelle avant chaque mise en production — inévitablement oubliée sous la pression d’un planning serré — nous avons construit un contrôle automatisé intégré à la chaîne de déploiement, qui bloque toute mise en production si une dépendance ajoutée ne satisfait pas un ensemble de critères déclaratifs.
Étape 1 : définir les critères vérifiables automatiquement
Le règlement couvre des obligations larges, dont certaines ne sont pas vérifiables par un script (la qualité du processus de gestion des vulnérabilités du fabricant, par exemple). Nous avons donc isolé quatre critères techniquement vérifiables : une date de dernière mise à jour de moins de douze mois, une note de compatibilité déclarée avec la version de WordPress en cours, l’absence de vulnérabilité connue non corrigée référencée publiquement, et la présence d’un canal de signalement de faille identifiable (page de sécurité ou adresse de contact dédiée).
Étape 2 : encoder ces critères dans un fichier de politique
{
"max_mois_sans_maj": 12,
"compatibilite_wp_minimale_requise": true,
"cve_non_corrigee_bloquante": true,
"canal_signalement_requis": true,
"extensions_exclues": ["extension-maison-client-xyz"]
}
Le champ extensions_exclues permet d’écarter du contrôle les extensions développées en interne par l’agence elle-même, pour lesquelles la gestion des vulnérabilités suit un processus documenté séparément, propre à l’agence, plutôt que d’être évaluée par ce script générique.
Étape 3 : le script de vérification
Le script interroge l’API du répertoire officiel des extensions WordPress pour chaque dépendance déclarée dans composer.json, récupère sa date de dernière mise à jour et sa compatibilité déclarée, puis croise le nom du paquet avec une base de vulnérabilités connues consultée via une requête HTTP simple.
#!/usr/bin/env bash
set -euo pipefail
POLITIQUE="conformite-cra.json"
MAX_MOIS=$(jq -r '.max_mois_sans_maj' "$POLITIQUE")
for slug in $(jq -r '.require | keys[] | select(startswith("wpackagist-plugin/"))' composer.json | sed 's/wpackagist-plugin\///'); do
DERNIERE_MAJ=$(curl -s "https://api.wordpress.org/plugins/info/1.0/${slug}.json" | jq -r '.last_updated')
MOIS_ECOULES=$(( ($(date +%s) - $(date -d "$DERNIERE_MAJ" +%s)) / 2592000 ))
if [ "$MOIS_ECOULES" -gt "$MAX_MOIS" ]; then
echo "ECHEC : $slug non mis a jour depuis $MOIS_ECOULES mois"
exit 1
fi
done
echo "Conformite CRA verifiee pour toutes les dependances"
Étape 4 : que faire quand une dépendance échoue
Un blocage sans alternative crée de la friction inutile lorsqu’une extension par ailleurs indispensable au projet échoue temporairement à un critère (par exemple une mise à jour en retard de quelques semaines chez son éditeur). Le script produit dans ce cas un rapport détaillé listant le critère en échec, permettant à l’équipe de décider en connaissance de cause : ajouter une dérogation temporaire documentée et datée dans le fichier de politique, ou remplacer la dépendance par une alternative plus activement maintenue.
- Chaque dérogation temporaire doit porter une date d’expiration au-delà de laquelle le contrôle redevient bloquant.
- Les dérogations sont journalisées dans un fichier séparé, consulté lors des revues de sécurité trimestrielles.
- Un rapport de conformité est archivé à chaque exécution réussie, daté et associé au commit déployé, pour servir de preuve en cas de contrôle.
Ce que ce contrôle ne remplace pas
Ce script vérifie des signaux techniques observables ; il ne remplace ni une analyse juridique du périmètre exact d’application du règlement à un projet donné, ni une revue de code de l’extension elle-même. Il constitue une première ligne de défense automatisée, pas une garantie complète de conformité, un point que nous avons pris soin de clarifier avec le client avant la mise en place.
Un contrôle automatisé de conformité vaut surtout pour ce qu’il empêche d’oublier, pas pour ce qu’il garantit à lui seul. Documenter cette limite évite de faire porter au script une responsabilité qu’il ne peut pas assumer.
Pour aller plus loin
Ce type de contrôle gagne à être généralisé au-delà du seul CRA : les mêmes critères de fraîcheur de maintenance et de canal de signalement de faille sont pertinents pour toute dépendance tierce, indépendamment de l’obligation réglementaire qui a motivé sa mise en place initiale.
