Avis ENISA sur les mécanismes de mise à jour sécurisés : guide CRA

L'ENISA attend vos retours avant le 10 juillet 2026. Son deuxième avis technique sur la sécurité des produits, Secure Update Mechanisms, est publié en projet et la consultation est ouverte dès maintenant.

Voici pourquoi cela compte. L'avis prend l'exigence du Règlement sur la cyberrésilience de livrer des mises à jour sécurisées et la décompose en sept étapes, chacune reliée à un échec réel. Quatre étaient des attaques : SolarWinds, ASUS, Notepad++ et Trivy. Une, la panne CrowdStrike de 2024, était une version défectueuse plutôt qu'une attaque. L'ENISA associe ensuite chaque étape à des contrôles qui réduisent la probabilité ou l'impact de cette menace ou de cet échec. Ce guide extrait les éléments dont une microentreprise, une petite ou une moyenne entreprise a besoin, les relie à vos obligations CRA, ajoute notre propre vue sur l'outillage et sur ce qu'il faut prioriser, et déroule l'exemple du thermostat que l'ENISA utilise pour tout relier.

Ce qu'est l'avis, et ce qu'il n'est pas

L'avis technique ENISA sur les mécanismes de mise à jour sécurisés est un projet daté de mai 2026, étiqueté Version 0.1 dans les en-têtes de ses pages. Le fichier publié porte le nom v0.6, ce qui semble être une coquille. L'ENISA l'a ouvert à consultation publique avec une enquête de retour qui se clôt le 10 juillet 2026.

Il vise les fabricants de produits comportant des éléments numériques, et en particulier les équipes qui conçoivent, construisent ou exploitent les mécanismes de mise à jour. L'ENISA l'a écrit pour les micro, petits et moyens fabricants qui doivent comprendre les menaces courantes sur les mises à jour et appliquer un ensemble de contrôles sans monter une grande équipe de sécurité.

Soyez clair sur ses limites. L'ENISA en énonce trois directement.

Ce qu'il vous donne, en revanche, c'est une carte partagée. Le même cycle de vie en sept étapes traverse la section sur les menaces et la section sur les contrôles, de sorte qu'un contrôle renvoie toujours à la menace à laquelle il répond.

Le cycle de vie des mises à jour, en sept étapes

L'ENISA décrit toute mise à jour, qu'il s'agisse d'un firmware, d'un binaire, d'un correctif différentiel, d'un fichier de signature ou d'un changement de configuration, comme passant par les mêmes sept étapes. Cinq acteurs les portent : le producteur (fabricant), le service de publication, le dépôt de mises à jour, le client de mise à jour et le terminal.

Les sept étapes se répartissent sur trois zones de confiance. Le domaine de confiance du producteur est l'endroit où la mise à jour est construite et signée. Le domaine de distribution, qui inclut les dépôts et les CDN, est traité comme moins fiable. Le domaine de confiance de l'appareil est l'endroit où la mise à jour est vérifiée et installée.

L'idée la plus utile du document tient derrière ce schéma.

Comment les mises à jour atteignent réellement l'appareil

Le cycle de vie est le même partout. Qui exécute chaque étape, non. L'ENISA nomme quatre modèles de livraison, et le modèle décide de l'endroit où vos contrôles doivent vivre. La matrice ci-dessous montre qui exécute chaque étape, pour que vous voyiez quelles cases vous reviennent.

Les exemples donnés par l'ENISA : le modèle intégré couvre les updaters d'applications de bureau, les updaters de greffons intégrés au produit et la mise à jour automatique du navigateur. Le modèle géré par plateforme couvre les magasins d'applications mobiles, les dépôts de paquets Linux, les plateformes MDM et les magasins d'extensions de navigateur. Le modèle manuel hors bande couvre un installeur depuis le site d'un éditeur, un correctif via un portail sécurisé ou un paquet envoyé par e-mail. Le modèle entreprise ou étagé couvre la mise en attente de type WSUS, les miroirs d'entreprise, les serveurs de gestion des correctifs et le transfert en réseau isolé.

Pour les conceptions simples, l'ENISA décrit un appareil qui fait confiance à une clé publique racine plus une clé de signature opérationnelle. Les conceptions plus avancées utilisent des rôles de signature distincts, et les déploiements à plus forte assurance ajoutent des signatures à seuil, où plus d'un détenteur de clé doit approuver un changement sensible. TUF et Uptane formalisent cette séparation des rôles. Vous n'avez à adopter ni l'un ni l'autre pour atteindre le socle de base.

Sept façons d'attaquer le canal de mise à jour

C'est la partie à lire deux fois. L'ENISA parcourt chaque étape du cycle de vie, énonce la menace, l'impact et un incident réel. Le schéma est constant : une compromission précoce dans la chaîne reste invisible si les étapes ultérieures traitent tout comme normal. Le tableau ci-dessous reprend la section 3 de l'avis, condensée, avec le contrôle principal ajouté depuis sa section 4.

Le modèle de menace que retient l'ENISA est large. Les attaquants peuvent viser les chaînes de build, les clés de signature, les services de publication, les dépôts, les CDN, le DNS, le rejeu de métadonnées, l'état de mise à jour côté client ou le flux d'installation. Le mélange de cas malveillants (SolarWinds, ASUS) et d'un cas non malveillant (CrowdStrike) est délibéré. Un mécanisme de mise à jour sécurisé doit survivre à la fois à un attaquant et à une version défectueuse.

STRIDE en un coup d'œil

L'annexe 1 de l'avis relie les menaces aux catégories STRIDE de Microsoft. C'est une correspondance indicative, non exhaustive, et plusieurs menaces couvrent plus d'une catégorie. Si vous menez une seule session de modélisation des menaces cette année, utilisez ce tableau comme ordre du jour : parcourez votre canal de mise à jour étape par étape et demandez quelle catégorie STRIDE mord le plus fort à chacune. Pour une équipe réduite, les lignes Altération et Usurpation d'identité aux étapes Récupérer et Rechercher méritent le plus de temps, car c'est là que les attaques ASUS et Notepad++ ont frappé.

Les contrôles, regroupés comme l'ENISA les regroupe

La section 4 rassemble les contrôles en quatre étapes et les aligne sur le playbook ENISA Secure by Design and Default. L'avis complet liste 36 recommandations nommées. Les tableaux ci-dessous gardent les plus utiles par étape. Lisez la source pour l'ensemble complet.

Préparation et publication

Cette étape couvre la construction, l'autorisation et la publication de la mise à jour et de ses métadonnées.

Découverte et récupération

Cette étape décide comment les clients trouvent et téléchargent les mises à jour sans être redirigés ni recevoir des données périmées.

Vérification et installation

C'est le point de décision de confiance principal. S'il échoue, les compromissions antérieures deviennent des mises à jour valides.

1. Vérification de signature. Vérifiez l'authenticité des métadonnées, et confirmez que l'artefact y est lié cryptographiquement.
2. Validation d'applicabilité. Confirmez que la mise à jour correspond à ce produit, cette version et cette configuration avant l'installation.
3. Contrôle d'intégrité. Validez le hachage de l'artefact et rejetez tout contenu corrompu ou modifié avant l'installation.
4. Contrôle de version et anti-retour arrière. Bloquez l'installation de versions plus anciennes ou non autorisées à l'aide de compteurs de retour arrière ou de numéros de séquence monotones.
5. Contexte d'installation autorisé. Seuls des composants de confiance et autorisés peuvent démarrer et exécuter l'installation, avec des restrictions de moindre privilège. C'est le contrôle pour la menace de privilèges élevés à l'étape d'installation.
6. Comportement de mise à jour atomique. Le système bascule entièrement vers la nouvelle version ou reste en sécurité sur la précédente, avec récupération en cas d'échec.

Observabilité et récupération

Cette étape enregistre les résultats, fait remonter les échecs et permet à l'appareil de récupérer.

Comment les équipes construisent cela avec des outils open source

L'ENISA garde l'avis agnostique sur le plan technologique et nomme des cadres et des guides comme TUF, Uptane, SLSA, in-toto et NIST SP 800-40, sans recommander d'outils précis. C'est le bon choix pour un régulateur, mais il laisse la question pratique ouverte. La correspondance ci-dessous est la nôtre, pas celle de l'ENISA. Aucun de ces outils n'est un certificat de conformité. Ils implémentent l'ingénierie. La preuve reste votre responsabilité.

Construisez l'updater dans l'ordre des dépendances

Cette partie est notre recommandation, pas celle de l'ENISA. Une réserve d'abord : ce n'est pas une liste restreinte à laquelle s'arrêter. Le CRA exige chaque exigence essentielle de cybersécurité qui s'applique à votre produit, sur la base de votre analyse des risques au titre de l'annexe I, donc l'objectif est l'ensemble complet des contrôles. Ce qui suit est l'ordre dans lequel nous les construirions, pour qu'une petite équipe ne soit pas paralysée par 36 recommandations. Le socle rend les contrôles ultérieurs utiles, donc la séquence compte.

1. Signez les métadonnées et vérifiez sur l'appareil. Provisionnez une ancre de confiance racine et vérifiez la signature avant toute installation. Faites-le en premier, car tout autre contrôle suppose que l'appareil n'accepte que des mises à jour authentiques. Sans cela, le reste n'est que décoration.
2. Verrouillez le transport. TLS pour la découverte et la récupération, et traitez tout CDN ou miroir comme non fiable. C'est surtout de la configuration, donc peu coûteux, et cela ferme l'attaque de récupération de type ASUS.
3. Ajoutez les contrôles de hachage et d'applicabilité. De petits ajouts à l'étape de vérification : confirmez que le hachage de l'artefact correspond au manifeste signé, et que la mise à jour correspond à ce modèle et cette version. Peu d'effort une fois la signature en place.
4. Cadrez l'anti-retour arrière tôt. C'est le contrôle le plus difficile à ajouter après coup, car il a besoin d'un état de compteur protégé et de la coopération du chargeur d'amorçage, donc planifiez-le maintenant même s'il arrive plus tard. C'est la défense contre le gel et la rétrogradation que l'ENISA souligne le plus.
5. Rendez les installations atomiques, avec retour arrière. Slots A/B ou redondants, pour qu'une version défectueuse (le mode de défaillance CrowdStrike) ne rende pas l'appareil inutilisable. C'est un gros chantier en artisanal, ce qui explique qu'un cadre maintenu l'emporte généralement ici.
6. Enregistrez et signalez les résultats. Un journal de mise à jour infalsifiable et un signalement des échecs, pour détecter un problème et prouver ce qui s'est passé. C'est aussi ce sur quoi s'appuie votre preuve CRA.

Un exemple concret : livrer un correctif de thermostat

L'ENISA conclut par un exemple concret, et c'est la partie la plus claire du document. Un thermostat IoT embarqué en version 1.0.0 a besoin d'une mise à jour de sécurité qui corrige EUVDB-202X-Y, une faille de validation d'entrée. L'appareil utilise un updater intégré. L'exemple est illustratif, pas un modèle universel.

Le fabricant exploite deux niveaux de signature. Une autorité de signature racine reste hors ligne et autorise une clé de signature opérationnelle du fournisseur utilisée pour les versions courantes. Cette séparation permet à la clé du fournisseur de tourner sans changer l'ancre de confiance racine de l'appareil.

L'appareil est livré avec les parties montrées ci-dessous.

Préparation. Le build s'exécute dans un environnement contrôlé avec uniquement du code et des dépendances autorisés. Un SBOM est généré et contrôlé pour les vulnérabilités. Le fabricant produit un manifest.json signé portant le hachage SHA-256 et la taille du fichier, le produit et la version applicables, les champs de fraîcheur et d'anti-retour arrière (horodatage, expiration, compteur de retour arrière), et l'information sur l'avis (gravité, URL de l'avis). Un changement d'un seul octet dans le paquet produit un hachage différent, détecté sur l'appareil.

openssl dgst -sha256 -sign keys/vendor_private.pem \
  -out repo/manifest.json.sig repo/manifest.json

Découverte. Le thermostat recherche les mises à jour via TLS, en validant le certificat du serveur contre ca.pem. Les champs update_type et severity lui permettent de distinguer une mise à jour de sécurité d'une version courante et de prévenir l'utilisateur en conséquence. Les téléchargements atterrissent dans staging, de sorte qu'une coupure de courant en plein téléchargement ne touche jamais le firmware en cours d'exécution.

curl --tlsv1.2 --cacert /etc/ssl/certs/ca.pem \
  https://updates.acme.com/device/manifest.json -o manifest.json

Vérification et installation. Avant d'installer, l'appareil exécute cinq vérifications dans l'ordre. Si l'une échoue, il abandonne.

La vérification anti-retour arrière pèse le plus lourd. Le compteur de retour arrière de l'appareil ne monte qu'après que le nouveau firmware démarre et passe ses contrôles de santé, de sorte qu'une mise à jour échouée ou malveillante ne peut pas relever discrètement le plancher et bloquer un correctif ultérieur. En cas de succès, le firmware est écrit dans le slot inactif et activé par un basculement de slot atomique, de sorte qu'une version connue comme saine reste toujours disponible. L'observabilité enregistre chaque tentative dans un update.log à accès restreint avec horodatage et statut. Si la clé du fournisseur est un jour compromise, le fabricant signe et livre une nouvelle clé de fournisseur que la clé racine autorise. La clé racine n'est jamais mise à jour par ce canal. Une compromission de la racine nécessite un processus sécurisé distinct comme une réinitialisation d'usine.

Ce que cela signifie pour votre dossier CRA

Le tableau final de l'avis associe chaque revendication de sécurité à des exemples de preuves et d'artefacts. Cette correspondance est le pont vers votre documentation technique. La documentation technique du CRA demande les deux : une description de votre solution de mise à jour sécurisée (annexe VII) et la preuve qui l'étaye, dont une nomenclature des logiciels (SBOM) et des rapports de test. Une description sans rien derrière, c'est le point faible.

Les revendications de sécurité de l'exemple, et la preuve qui étaye chacune, ressemblent à ceci.

Chaque ligne soutient une ou plusieurs exigences de l'annexe I du CRA, de l'intégrité et la distribution sécurisée à la surveillance et la disponibilité. Voyez les exigences CRA de mise à jour de sécurité pour le détail au niveau des articles.

Si vous ne pouvez pas produire la colonne de droite aujourd'hui, cet écart est votre tâche à traiter. Un enregistrement VEX et une vérification des dépendances pilotée par le SBOM couvrent directement deux de ces lignes. Votre diligence raisonnable fournisseur couvre la ligne de confiance du build pour les composants que vous n'avez pas écrits.

Cet article est fourni à titre d'information uniquement et ne constitue pas un avis juridique. Pour des conseils de conformité spécifiques, consultez un conseil juridique qualifié.