Architecture d’un pipeline conforme au Cyber Resilience Act pour un client

« La Commission européenne a proposé, le 15 septembre 2022, un règlement sur la cyber-résilience visant à imposer des exigences de sécurité aux produits comportant des éléments numériques » : cette annonce a suffi pour qu’un client éditeur d’un produit logiciel construit sur WordPress nous demande d’anticiper, dès maintenant, les évolutions probables de son pipeline de livraison plutôt que d’attendre l’entrée en vigueur effective du texte, encore incertaine à ce stade.

Sans attendre la version finale du règlement, dont les contours précis restent à confirmer, certaines exigences pressenties peuvent déjà être anticipées dans l’architecture d’un pipeline de déploiement, sans bouleversement majeur du fonctionnement existant.

Ce que l’on peut anticiper dès aujourd’hui

Trois axes du texte proposé, tels que présentés par la Commission, orientent les choix d’architecture retenus pour ce pipeline :

• La capacité à démontrer l’intégrité d’un livrable logiciel, depuis sa construction jusqu’à son déploiement.
• La traçabilité des vulnérabilités connues affectant les composants tiers utilisés (extensions, bibliothèques).
• Une procédure documentée de gestion des mises à jour de sécurité, avec des délais de correction définis.

Signer chaque livrable produit par le pipeline

Pour garantir qu’un artefact déployé en production correspond exactement à ce qui a été construit et validé par la pipeline, sans modification intermédiaire, chaque archive de déploiement est désormais signée cryptographiquement à l’issue de l’étape de build :

jobs:
  build:
    steps:
      - name: Construire l'archive de déploiement
        run: tar -czf release.tar.gz dist/
      - name: Signer l'archive
        run: |
          gpg --batch --yes --detach-sign --armor \
              --local-user "pipeline@agence.fr" release.tar.gz
      - name: Publier l'archive et sa signature
        uses: actions/upload-artifact@v3
        with:
          name: release-signee
          path: |
            release.tar.gz
            release.tar.gz.asc

Avant tout déploiement en production, une étape de vérification confirme que la signature correspond bien à la clé publique de la pipeline, avant d’autoriser la suite du processus.

Cartographier les composants tiers

Un inventaire précis des composants logiciels utilisés — extensions WordPress, bibliothèques PHP et JavaScript — avec leur version exacte, est désormais généré automatiquement à chaque build, sous forme de nomenclature logicielle (SBOM, software bill of materials) :

composer show --format=json > sbom-composer.json
wp plugin list --format=json > sbom-plugins.json

Cette nomenclature permet de répondre rapidement à la question « ce composant vulnérable récemment révélé est-il présent dans l’un de nos projets ? », sans devoir inspecter manuellement chaque projet du parc.

Un journal d’audit qui survit aux changements d’équipe

Le pipeline consigne désormais chaque déploiement dans un journal structuré, distinct des simples journaux techniques de la CI, avec les informations suivantes conservées durablement :

1. La date et l’heure du déploiement, l’auteur du commit déclencheur, et l’empreinte cryptographique de l’archive déployée.
2. La liste des composants tiers inclus dans cette version précise, via la nomenclature générée à l’étape précédente.
3. Le résultat des vérifications de sécurité automatisées exécutées avant le déploiement.

Ce qui reste incertain à ce stade

Le texte n’étant encore qu’une proposition de la Commission européenne, certains détails d’application — seuils exacts, calendrier de mise en conformité, périmètre précis des produits concernés — ne sont pas encore stabilisés. L’architecture retenue privilégie donc des fondations générales et robustes (signature, traçabilité, journal d’audit) plutôt qu’une conformité pointilleuse à un texte susceptible d’évoluer avant son adoption définitive.

Construire une architecture de conformité robuste avant que le texte final ne soit figé coûte moins cher qu’une mise en conformité précipitée après son entrée en vigueur.

En résumé

Anticiper un règlement encore en projet demande de la mesure : viser des principes durables — intégrité vérifiable, traçabilité des composants, journal d’audit exploitable — plutôt qu’une conformité littérale à un texte dont la version définitive n’est pas encore connue.