La loi sur la résilience cybernétique (CRA) de l'Union européenne (UE) marque une réglementation déterminante pour tous les produits contenant des éléments numériques. Avec un déploiement réglementaire complet prévu pour le 11 décembre 2027 — et d'autres exigences obligatoires arrivant encore plus tôt — il est essentiel pour les équipes d'ingénierie et les chefs de produit de comprendre la législation. Après tout, les fabricants portent la responsabilité principale de s'assurer que tous les appareils sont conformes avant leur mise sur le marché.
En plus de la responsabilité totale en cas d'incidents de cybersécurité, les pénalités pour non-conformité sont sévères :
- Amendes pouvant aller jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, avec des produits non conformes interdits, retirés ou rappelés des marchés de l'UE.
- Perte du marquage CE, ce qui signifie que les produits ne peuvent pas être légalement vendus dans l'UE.
- Exclusion automatique possible des appels d'offres et des partenariats, car de nombreuses demandes de propositions (RFP) exigent des solutions conformes à la CRA.
De plus, les fabricants qui ne se conforment pas risquent de perdre leur crédibilité sur le marché et la confiance des clients des secteurs critiques (tels que ceux du gouvernement, des finances et des applications industrielles) qui évitent les produits dépourvus de garanties de sécurité complètes.
Compte tenu de ces risques, les concepteurs de systèmes doivent désormais prendre en compte les implications de sécurité des choix matériels et logiciels clés dès le début du processus de conception, car les deux affecteront la conformité à long terme et donc l'accès au marché. Cet article définira les principaux engagements de sécurité d'un fabricant en vertu de la CRA avant de mettre en avant les mises à jour over-the-air (OTA) comme une stratégie puissante pour maintenir la conformité à long terme. Il décrira ensuite un cadre logiciel robuste pour fournir ces mises à jour en toute sécurité et fournira un exemple de solution commerciale sur étagère (COTS) qui s'aligne avec ces principes.
Engagements de sécurité en vertu de la CRA
Des appareils grand public aux composants d'infrastructure distribués, les systèmes modernes en périphérie souffrent d'un nombre croissant de vulnérabilités de sécurité. Les problèmes de micrologiciel obsolète et les protocoles de communication non sécurisés peuvent entraîner des violations de données et un accès non autorisé qui compromettent l'intégrité des appareils. En conséquence, la CRA impose plusieurs mesures pour maintenir une surface d'attaque minimale :
Tout d'abord, les fabricants doivent protéger les appareils contre les manipulations non autorisées et garantir l'intégrité du logiciel dès le premier démarrage. Bien que la CRA ne définisse pas de cadre spécifique pour y parvenir, le démarrage sécurisé, en combinaison avec une racine de confiance (RoT), sert de base fondamentale pour répondre à cette exigence.
Le démarrage sécurisé utilise la cryptographie pour garantir que seul un logiciel authentique et vérifié s'exécute sur l'appareil. Cette RoT forme le premier maillon d'une chaîne de confiance qui authentifie chaque étape du processus de démarrage pour garantir l'intégrité de l'appareil, comme le montre la Figure 1. Si, par exemple, un hachage d'un composant logiciel est chiffré avec une clé privée qui ne correspond pas aux clés publiques dans la RoT — que ce soit en raison de manipulations ou de corruption — le processus de démarrage s'arrêtera ou limitera les capacités système supérieures (telles que l'accès au réseau) pour empêcher la propagation potentielle de logiciels malveillants ou de botnets.
Les fabricants doivent garantir l'intégrité via une gestion continue des vulnérabilités et des mises à jour de sécurité en temps opportun tout au long du cycle de vie du produit. La CRA définit une période de support obligatoire d'au moins 5 ans, ou la durée de vie prévue du produit si elle est plus courte, et exige que les fabricants fournissent une date de fin de support spécifiée lors de la mise sur le marché.
Lorsqu'une vulnérabilité activement exploitée est découverte, les fabricants doivent la divulguer à leur équipe nationale de réponse aux incidents de sécurité informatique (CSIRT) et à l'Agence européenne pour la sécurité des réseaux et de l'information (ENISA), l'agence de cybersécurité de l'UE. Cet engagement de rapport entre en vigueur le 11 septembre 2026, avec les exigences de délai suivantes :
- 24 heures : Des rapports d'alerte précoce doivent être envoyés à l'ENISA et au CSIRT national.
- 72 heures : Une notification formelle de vulnérabilité doit être générée, détaillant l'exploitation et son impact sur un système.
- 14 jours : Un rapport final doit être soumis une fois qu'un correctif de sécurité est disponible.
Naturellement, la gestion continue des vulnérabilités exige un certain niveau de surveillance des menaces en temps réel. Des frameworks publics comme le système Common Vulnerabilities and Exposures (CVE) peuvent aider les fabricants à détecter et corriger de nouvelles menaces dans les composants logiciels tiers, avant même qu’elles ne soient activement exploitées au sein de leurs propres dispositifs.
Pour soutenir ce qui précède, le CRA impose également aux fabricants de conserver une documentation technique pour chaque mise à jour. En particulier, une software bill-of-materials (SBOM) doit être fournie dans un format lisible par machine, tel que CycloneDX ou SPDX, couvrant au minimum toutes les dépendances de premier niveau. Ce format permet aux outils automatisés d’analyser chaque build logiciel par rapport aux bases de données CVE afin d’identifier de nouvelles vulnérabilités dès qu’elles sont signalées. Les équipes DevSecOps peuvent ensuite distribuer des correctifs qui résolvent les problèmes internes sans introduire de logiciels tiers.
Outre les SBOM, la conformité au CRA exige une documentation étendue comprenant une évaluation de haut niveau des risques de sécurité, des diagrammes de l’architecture système avec une description du processus de développement, ainsi que des descriptions du processus de gestion des vulnérabilités (voir Figure 2). Ces éléments sont utilisés pour vérifier que le système est secure-by-design conformément aux lignes directrices du CRA. La documentation enregistrée doit être conservée pendant tout le cycle de vie du dispositif et mise à disposition des auditeurs, des autorités de surveillance et des organismes notifiés pendant 10 ans après la mise sur le marché, ou pendant toute la durée d’une période de support plus longue.
Enfin, une déclaration formelle de conformité (DoC) permet aux fabricants d’utiliser le marquage CE pour accéder au marché de l’UE. Le document DoC contient des informations telles que le nom et l’adresse du fabricant, une identification unique du produit et des références aux standards et spécifications techniques utilisés pour démontrer la conformité. Pour certains produits numériques relevant des catégories CRA « Important Class I », « Important Class II » et « Critical », les détails d’un auditeur tiers chargé de vérifier la conformité doivent également être inclus. Ces dispositifs incluent les systèmes de contrôle industriel, les gateways IoT et les logiciels destinés aux accès privilégiés, pour lesquels d’éventuelles violations pourraient causer des dommages plus larges aux infrastructures.
En signant une DoC, les fabricants assument l’entière responsabilité de la conformité au CRA. Compte tenu de l’ampleur de ces engagements, les mises à jour OTA représentent le moyen le plus efficace de distribuer rapidement des correctifs et de maintenir l’intégrité des dispositifs connectés. Toutefois, les mises à jour OTA continues nécessitent une architecture logicielle sophistiquée, spécifiquement conçue pour prendre en charge des mises à jour alignées sur le CRA.
Concevoir une infrastructure logicielle pour des correctifs de sécurité OTA réguliers
Au titre du CRA, les équipes DevSecOps travaillent sous une forte pression temporelle lorsqu’elles doivent identifier, caractériser et résoudre des problèmes de sécurité après leur découverte. Pour simplifier la gestion de la sécurité, les dispositifs embarqués bénéficient des ajustements architecturaux suivants:
- Integrated telemetry reporting: en collectant des données sur l’état de santé des dispositifs et en les envoyant à une plateforme cloud, les fabricants peuvent identifier rapidement des bugs ou des exploits dans les dispositifs connectés. Le telemetry reporting permet également aux équipes de vérifier l’efficacité des nouveaux correctifs dans des tests réels limités avant le déploiement sur l’ensemble de la flotte.
- Architecture logicielle hautement modulaire et containerisée: l’isolation des menaces contribue à réduire la surface d’attaque si un dispositif est compromis. Par exemple, la containerisation empêche qu’une attaque visant l’interface utilisateur puisse accéder au code core du système d’exploitation (OS). Elle permet également à certains composants logiciels de continuer à fonctionner pendant que d’autres sont mis à jour, réduisant ainsi le downtime opérationnel. De même, le logiciel modulaire accélère l’identification des vulnérabilités et réduit les besoins en données OTA — et donc les coûts — par rapport aux mises à jour de code monolithiques.
- Mécanismes de rollback: les interruptions et anomalies lors des mises à jour OTA peuvent empêcher l’installation correcte des correctifs, provoquant potentiellement le bricking du dispositif. Les mécanismes de rollback garantissent qu’un dispositif peut toujours revenir à un état opérationnel si une mise à jour échoue, permettant aux fabricants de respecter les engagements prévus par le CRA et de maintenir l’intégrité du dispositif.
Bien entendu, les mises à jour OTA sécurisées nécessitent des tunnels chiffrés end-to-end afin de garantir que les correctifs ne puissent pas être compromis pendant la transmission et que seul un firmware signé et vérifié puisse s’exécuter sur un dispositif. Pour satisfaire les exigences de documentation relatives à chaque correctif publié, les fabricants bénéficient de frameworks de développement logiciel fournissant une génération automatisée de SBOM et du logging.
Cependant, la mise en œuvre de frameworks alignés sur le CRA peut représenter une charge importante pour les développeurs qui construisent des logiciels à partir de zéro, surtout avec des échéances réglementaires qui approchent rapidement. Heureusement, les solutions COTS peuvent aider les équipes à satisfaire les exigences de compliance dans les délais prévus.
Tirer parti des frameworks logiciels COTS pour l’alignement avec le CRA
Les frameworks logiciels COTS offrent plusieurs avantages particulièrement pertinents pour le CRA. Le premier est l’accélération du développement afin de réduire le time-to-market. De même, bien que la responsabilité juridique de la conformité incombe toujours aux fabricants, des solutions tierces éprouvées peuvent également réduire le risque de zones d’ombre réglementaires. En outre, en collaborant avec des partenaires commerciaux, les fabricants peuvent obtenir un support supplémentaire à long terme pour leur infrastructure logicielle, allégeant encore davantage la charge des développeurs.
Un exemple de ce type de solution est Clea OS de SECO, une architecture logicielle personnalisable conçue pour des systèmes sécurisés de niveau industriel et dotée de nombreuses fonctionnalités qui simplifient la conformité au CRA. Basé sur le projet open-source Yocto, Clea OS offre reproductibilité et traçabilité pour les audits CRA, avec des fonctionnalités de génération automatisée de SBOM à l’appui des obligations documentaires.
Contrairement à de nombreux systèmes d’exploitation fermés, Clea OS est conçu comme une base Linux OS légère et contrôlée, qui minimise les composants inutiles afin de réduire la surface d’attaque et d’améliorer la sécurité et la résilience globales. La containerisation est assurée par Docker afin d’isoler les menaces et de permettre une disponibilité 24/7 pendant les activités de patching. Cette approche est également soutenue par le partitionnement A/B, qui garantit la présence constante d’une image firmware fonctionnelle sur le dispositif et permet le rollback du firmware actif en cas d’échec d’une mise à jour.
En outre, Clea OS prend en charge le secure boot, les mises à jour OTA signées numériquement, la surveillance continue des dispositifs en temps réel en combinaison avec l’écosystème Clea plus large de SECO (comme illustré à la Figure 3), ainsi qu’un Cyber Security Package. En permettant aux fabricants de maximiser les opportunités de détection des menaces et de patching, ce support facilite le respect des exigences du CRA relatives aux longues périodes de support, en répondant directement à des exigences clés telles que les mécanismes de mise à jour sécurisés, la gestion continue des vulnérabilités et l’intégrité du système.
L’existence de solutions COTS, dont Clea OS de SECO, démontre que la conformité au CRA ne doit pas nécessairement être aussi complexe qu’elle peut le sembler au premier abord. En encourageant les équipes de développement à utiliser des frameworks logiciels prêts à l’emploi offrant un haut niveau de personnalisation, les fabricants peuvent simplifier la transition vers un nouveau paysage de cybersécurité, tout en commercialisant des produits différenciés.