CRA : la régulation qui change la donne pour les produits IoT

La CRA, ou Cyber Resilience Act, est une proposition de règlement européen introduite en 2022, qui vise à renforcer la cybersécurité des produits numériques commercialisés en Europe.

Pourquoi c’est important ?

Traditionnellement, la cybersécurité dans l’IoT était souvent reléguée en fin de chaîne. Avec la CRA, elle devient une exigence réglementaire, au même titre que la conformité électrique ou la sécurité physique.

Ce que la CRA impose :

• Analyse de risques systématique avant la mise sur le marché.
• Support de mises à jour de sécurité pendant toute la durée de vie du produit.
• Notification obligatoire des vulnérabilités détectées.
• Documentation de sécurité claire, incluant notamment un SBOM.

Impact pour les entreprises :

La CRA transforme le logiciel en composant réglementé. Elle force les entreprises à adopter des pratiques de développement sécurisé, de traçabilité des dépendances logicielles et de gestion des vulnérabilités. Cela implique de revoir certains outils, processus et relations avec les sous-traitants.

Qui est concerné ?

• Les fabricants de dispositifs connectés.
• Les intégrateurs de solutions embarquées.
• Les fournisseurs de logiciels embarqués.

Autrement dit, tout acteur qui met un produit numérique sur le marché européen. La portée est vaste, incluant les objets connectés grand public, mais aussi l’IoT industriel, médical, ou encore les infrastructures critiques.

Yocto : une fondation robuste pour construire vos firmwares

Le Yocto Project est un framework open source pour créer des systèmes Linux embarqués personnalisés. Il est largement utilisé dans les produits IoT industriels, car il offre un excellent équilibre entre flexibilité, pérennité, et contrôle.

Yocto, c’est quoi exactement ?

C’est un ensemble d’outils permettant de :

• Décrire précisément le contenu d’un firmware Linux.
• Construire des images reproductibles (rootfs, kernel, bootloader).
• Intégrer des couches de personnalisation propres à un matériel donné.
• Gérer les dépendances et versions des composants logiciels.

Pourquoi Yocto est pertinent pour les décideurs ?

• Réduction des coûts à long terme : en partant d’une base propre et contrôlée, on limite les dépendances inutiles.
• Sécurité et traçabilité : chaque composant est documenté, versionné, reproductible.
• Adaptabilité : on peut porter le même projet sur plusieurs plateformes matérielles.

Yocto est donc une brique stratégique pour concevoir des firmwares robustes, durables et conformes à la CRA.

Cas d’usage typique

Un fabricant de dispositifs de télémesure peut créer un système de base avec Yocto, y ajouter ses modules applicatifs (MQTT, LTE, capteurs), et le décliner sur plusieurs gammes (4G, WiFi, satellite) avec des couches BSP distinctes.

Firmware platforming : unifier pour mieux déployer

Développer un firmware pour chaque produit ou client mène rapidement à une explosion des coûts de maintenance. Le firmware platforming consiste à créer une base commune sur laquelle plusieurs variantes de produits peuvent s’appuyer.

Avec Yocto, le firmware platforming devient accessible

Grâce à son architecture modulaire (recettes, couches, configurations), Yocto permet de :

• Séparer les couches matérielles (BSP) des couches fonctionnelles.
• Décliner plusieurs produits à partir d’un même tronc logiciel.
• Automatiser la construction de variantes via des machines cibles et des classes de build.

Exemple concret :

Une entreprise qui vend des capteurs pour l’énergie, la logistique et l’environnement peut :

• Créer une base Yocto commune (noyau, base de packages, politique de mise à jour).
• Ajouter des couches spécifiques par segment (drivers, applications métiers).
• Déclencher la construction d’images spécifiques par client ou gamme de produits.

Bénéfices pour l’entreprise :

• Maintenance simplifiée : un patch de sécurité peut être intégré une seule fois.
• Time-to-market réduit : les déclinaisons ne nécessitent pas de repartir de zéro.
• Conformité facilitée : la documentation technique peut être centralisée.

Platforming et CRA

Le firmware platforming facilite la conformité à la CRA : un seul processus de sécurisation peut s’appliquer à plusieurs produits. Cela simplifie l’analyse de risque, la gestion des vulnérabilités, et la production de SBOM.

SBOM : comprendre ce qu’on embarque

Un SBOM (Software Bill of Materials) est une liste structurée des composants logiciels (open source ou propriétaires) intégrés dans un firmware.

Pourquoi c’est un enjeu stratégique ?

• Pour respecter la CRA (et d’autres régulations comme la directive NIS2).
• Pour réagir vite en cas de faille critique (ex : Log4Shell).
• Pour gérer les dépendances de manière proactive.
• Pour éviter les licences open source problématiques (GPLv3, AGPL, etc).

Que contient un SBOM ?

• Nom, version, fournisseur de chaque composant.
• Lien avec les paquets sources utilisés.
• Méthode d’intégration (compilé, embarqué, lié dynamiquement).
• Licences associées.

Formats standards :

• SPDX : largement utilisé dans l’industrie.
• CycloneDX : très prisé dans les démarches DevSecOps.

---

Générer un SBOM avec Yocto

Yocto intègre depuis plusieurs années des mécanismes natifs pour générer un SBOM conforme aux formats standards comme SPDX.

Étapes pour générer un SBOM :

1. Activer la génération dans les options de build dans votre local.conf ou recettes.

   # Required to enable SPDX file generation
   INHERIT += "create-spdx"
   
   # Optional: If set to "1", the output SPDX files will be formatted
   SPDX_PRETTY = "1"
   
   # Optional: If set to "1", the output SPDX files will include file information
   SPDX_INCLUDE_SOURCES = "1"
   
   # Optional: If set to "1", BitBake will create a source files archive for each package
   SPDX_ARCHIVE_SOURCES = "1"
   
   # Optional: If set to "1", BitBake will create an output binary archive for each package
   SPDX_ARCHIVE_PACKAGED = "1"
   

2. Construire l’image normalement :

   bitbake core-image-minimal
   

3. Récupérer les fichiers générés : Dans le répertoire tmp/deploy/spdx/, vous trouverez des fichiers .spdx pour chaque package et une vue d’ensemble. Vous pouvez le analyser avec des outils.

Astuces:

• Structurez vos layers pour isoler les composants tiers.
• Utilisez les tags SPDX dasn vos recipes pour lclarifier les informations de license, source, et version.
• Validez la complétude de la SBOM en utilisant des outils de lint.

Intégration dans un pipeline CI :

Il est fortement recommandé d’intégrer la génération de SBOM dans votre pipeline CI/CD, pour qu’elle suive le cycle de vie complet de chaque version firmware. Cela permet de garder une trace claire et d’automatiser la surveillance de vulnérabilités.

Analyser et exploiter un SBOM

Une fois le SBOM généré, encore faut-il l’exploiter intelligemment.

Objectifs de l’analyse :

• Identifier les vulnérabilités connues (ex : CVE via NVD, OSV, VulnDB).
• Contrôler la conformité des licences.
• Cartographier les composants critiques (par périmètre fonctionnel).

Outils recommandés :

• Grype pour la détection de vulnérabilités.
• FOSSA, Whitesource, Snyk pour l’analyse de licence.
• OWASP Dependency-Track pour le suivi continu.

Gouvernance du SBOM :

• Centraliser les SBOMs dans un dépôt sécurisé.
• Versionner chaque livrable avec son SBOM associé.
• Planifier une veille continue sur les composants à risque.
• Mettre en place une politique de réponse aux incidents.

Bonnes pratiques :

• Documenter les exceptions (justifications, acceptation de risque).
• Partager les SBOMs avec les clients ou partenaires critiques.
• Automatiser la mise à jour des dépendances lorsque possible.

Conclusion : vers une souveraineté logicielle des produits IoT

La chaîne logicielle devient un actif stratégique pour les entreprises de l’IoT. La CRA pousse à plus de rigueur, mais c’est aussi une opportunité :

• Pour renforcer la confiance avec vos clients.
• Pour anticiper les attaques.
• Pour professionnaliser vos pratiques de développement.

Des outils comme Yocto et les SBOM ne sont pas que des sujets techniques : ce sont les leviers d’une industrialisation maîtrisée de vos produits numériques.

En tant que décideur, votre rôle est de donner l’impulsion : adopter une vision long terme, structurer les équipes, investir dans les bons outils. C’est cette cohérence qui fera la différence entre un produit connecté fragile, et un produit fiable, conforme, évolutif.