# Un pipeline qui bloque le déploiement si une dépendance viole le CRA

> Ajouter un contrôle de conformité des dépendances tierces avant chaque mise en production.

- Auteur : Clément Hadrot
- Publié le : 2024-07-15
- Mis à jour le : 2024-07-15
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/pipeline-bloque-dependance-viole-cra/

## L’essentiel

- Une extension tierce peut violer le règlement sans que personne ne le remarque
- La vérification s'appuie sur une liste de critères déclarative
- Le blocage vaut mieux qu'une alerte ignorée

`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.

> L'essentiel à retenir : Une extension tierce peut violer le règlement sans que personne ne le remarque ; La vérification s'appuie sur une liste de critères déclarative ; Le blocage vaut mieux qu'une alerte ignorée

```
#!/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.