Sécurité du firmware
Sécurité du firmware embarqué pour les appareils RTOS et bare-metal
La sécurité du firmware embarqué consiste à savoir quels composants s’exécutent sur un microcontrôleur ou un appareil sous RTOS et à les maintenir exempts de vulnérabilités connues, même lorsqu’il n’y a pas de système d’exploitation à inspecter. KROMSE couvre aujourd’hui le firmware basé sur Linux ; les images bare-metal et RTOS ainsi que les composants matériels figurent sur la feuille de route.
Offre Free, sans carte bancaire.
Pourquoi les firmwares RTOS et bare-metal sont difficiles à analyser
Un firmware basé sur Linux embarque un système de fichiers avec des bases de paquets et des binaires distincts ; un scanner peut donc l’extraire et lire ce qu’il contient. Un firmware bare-metal ou RTOS est généralement un bloc unique lié statiquement : l’application, le noyau RTOS (FreeRTOS, Zephyr, ThreadX, NuttX et d’autres), les piles réseau comme lwIP et les bibliothèques cryptographiques comme Mbed TLS ou wolfSSL y sont compilés ensemble, sans noms ni fichiers de version.
Identifier les composants d’une telle image nécessite des signatures de code connu ou des métadonnées de build fournies par le fabricant. Sans l’un ni l’autre, un scanner honnête ne peut que constater que rien n’a pu être extrait.
Partir du build, pas du binaire
Pour les produits embarqués, l’inventaire le plus fiable provient généralement du système de build, car le fabricant y a accès, contrairement à un scanner qui examine le binaire.
- Zephyr : le manifeste west (west.yml) fige les modules et leurs révisions.
- ESP-IDF : idf_component.yml et le fichier de verrouillage des dépendances listent les composants gérés.
- PlatformIO et Arduino : platformio.ini, library.properties et les fichiers de sketch nomment les bibliothèques.
- Conan et vcpkg : les fichiers de verrouillage consignent les versions des paquets C et C++.
- Yocto et Buildroot : les manifestes d’image et de licences listent chaque paquet d’un build Linux.
Ce qu’attend le Cyber Resilience Act
Le CRA ne prévoit pas d’exception pour les petits appareils. Un produit à microcontrôleur doté d’une connexion réseau est un produit comportant des éléments numériques ; son fabricant a besoin d’un SBOM (nomenclature des logiciels) couvrant au moins les dépendances de niveau supérieur, d’un processus de gestion des vulnérabilités, de mises à jour de sécurité pendant la période d’assistance et d’une procédure de notification au titre de l’article 14.
Plusieurs types de composants figurent dans les listes de produits importants du règlement, comme les microprocesseurs et microcontrôleurs dotés de fonctionnalités liées à la sécurité en classe I, et les microprocesseurs et microcontrôleurs résistants aux manipulations en classe II, ce qui entraîne une évaluation de la conformité plus stricte.
Les composants matériels font partie du tableau
Des vulnérabilités sont aussi publiées pour le matériel : processeurs, puces radio, éléments sécurisés. Une nomenclature du matériel (HBOM) permet à un fabricant de vérifier lesquels de ses produits utilisent un composant affecté. L’exigence de SBOM du CRA porte sur les logiciels, mais la gestion des vulnérabilités couvre l’ensemble du produit.
Des mises à jour pour les appareils en service
Trouver un composant vulnérable n’est que la moitié de l’obligation. Le CRA exige que les mises à jour de sécurité soient diffusées de manière sécurisée et sans retard pendant toute la période d’assistance, qui doit être d’au moins cinq ans sauf si le produit est censé être utilisé moins longtemps, et chaque mise à jour doit rester disponible pendant au moins dix ans ou pendant le reste de la période d’assistance.
Pour les produits à microcontrôleur, cela implique de prévoir le chemin de mise à jour dès la conception : une chaîne de démarrage sécurisé, des images signées, assez de mémoire flash pour une image de secours et un moyen d’atteindre des appareils rarement connectés. Il est généralement impossible d’ajouter ces éléments après le lancement.
Mesures concrètes dès maintenant
Tant que les outils ne savent pas lire toutes les images, ce sont les registres du fabricant qui portent l’essentiel du travail.
- Conserver les manifestes de build et les fichiers de verrouillage de chaque version de firmware publiée.
- Consigner les versions du RTOS, de la pile réseau et de la bibliothèque cryptographique pour chaque produit.
- S’abonner aux avis de sécurité de chaque RTOS et de chaque bibliothèque que vous livrez.
- Planifier la manière dont les appareils en service recevront les mises à jour de sécurité pendant la période d’assistance.
Disponible aujourd’hui dans KROMSE
Ce que KROMSE couvre aujourd’hui pour les produits embarqués :
- Images firmware basées sur Linux : extraites, inventoriées et confrontées aux vulnérabilités connues.
- Les manifestes de build embarqués sont listés dans l’inventaire (Zephyr west.yml, ESP-IDF, PlatformIO, Arduino, Conan, vcpkg, CMake, Yocto et Buildroot) ; la plupart ne sont pas encore rapprochés des avis de sécurité.
- Les manifestes Yocto et Buildroot peuvent être importés comme un SBOM et sont confrontés à OSV.dev.
- Les images bare-metal et RTOS sont signalées comme non analysables, jamais comme saines.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T1 2027Firmware bare-metal et RTOS. KROMSE identifiera les composants des firmwares dépourvus de système de fichiers Linux, comme les images bare-metal et RTOS basées sur FreeRTOS ou Zephyr.
- À venir · T1 2027Composants matériels. KROMSE comparera les composants matériels de votre produit aux avis de sécurité publiés pour le matériel.
- À venir · T4 2026 (décembre)Sécurité de la robotique. KROMSE ajoutera les avis de sécurité ROS 2, l’identification des composants dans les firmwares PX4 et ArduPilot, et des données de vulnérabilités propres aux robots.
Questions fréquentes
KROMSE peut-il analyser un firmware FreeRTOS ou Zephyr ?
Pas encore sous forme d’image binaire. KROMSE liste dans son inventaire les manifestes Zephyr et d’autres manifestes de build embarqués, mais l’identification des composants à l’intérieur des images bare-metal et RTOS figure sur la feuille de route. L’analyse d’une telle image indique que rien n’a pu être extrait.
Le CRA s’applique-t-il aux appareils à microcontrôleur ?
Oui, si l’appareil est un produit comportant des éléments numériques doté d’une connexion de données directe ou indirecte. La taille n’entre pas en ligne de compte. Les microprocesseurs et microcontrôleurs dotés de fonctionnalités liées à la sécurité figurent parmi les produits importants de l’annexe III.
Qu’est-ce qu’une nomenclature du matériel ?
Une liste des composants matériels d’un produit, comme les processeurs, les puces radio et les éléments sécurisés, avec leurs références. Elle permet à un fabricant de savoir rapidement quels produits utilisent un composant qui fait l’objet d’une vulnérabilité publiée.
La période d’assistance s’applique-t-elle aussi aux petits appareils ?
Oui. Chaque produit comportant des éléments numériques a besoin d’une période d’assistance qui reflète sa durée d’utilisation prévue et soit d’au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps. Les mises à jour de sécurité doivent être fournies pendant cette période ; le mécanisme de mise à jour doit donc être prévu dès le départ.
Comment établir un SBOM pour un firmware RTOS ?
Partez du système de build : le manifeste west de Zephyr, les fichiers de verrouillage des composants ESP-IDF, la configuration PlatformIO ou les fichiers de verrouillage Conan et vcpkg consignent ce qui est entré dans l’image. Convertissez-les en CycloneDX ou SPDX et conservez-en un par version.