Sécurité du firmware
Scanner de vulnérabilités firmware pour les images basées sur Linux
Un scanner de vulnérabilités firmware extrait le contenu d’une image firmware, identifie les composants logiciels qu’elle contient et les confronte aux vulnérabilités connues. KROMSE le fait aujourd’hui pour les images firmware basées sur Linux jusqu’à 512 Mo, et vous dit clairement ce qu’il n’a pas pu voir.
Offre Free, sans carte bancaire.
Pourquoi le firmware nécessite sa propre analyse
Le firmware commence là où s’arrête l’analyse du code source. Une image d’appareil contient le code du fabricant, mais aussi un noyau Linux, une bibliothèque C, BusyBox, une bibliothèque SSL et des dizaines de paquets apportés par un board support package (BSP) ou par un système de build comme Yocto ou Buildroot. Beaucoup d’entre eux n’apparaissent jamais dans un dépôt dont l’équipe produit a la charge.
L’image est aussi ce que les clients exécutent réellement. L’analyser répond à la question qui compte pour le Cyber Resilience Act : quels composants, dans quelles versions, se trouvent dans le produit mis sur le marché.
Comment fonctionne l’analyse de firmware
Une analyse comporte trois étapes : extraire, identifier, rapprocher. Chacune peut échouer sans bruit ; un bon scanner signale donc ce qu’il n’a pas pu faire aussi clairement que ce qu’il a trouvé.
- Extraire : décompresser l’image de manière récursive, à travers des systèmes de fichiers comme SquashFS, JFFS2, CramFS et UBI, et les en-têtes propres aux fabricants.
- Identifier : lister les paquets à partir des bases de paquets et identifier les binaires, par exemple grâce à leurs chaînes de version.
- Rapprocher : confronter les composants identifiés à des données de vulnérabilités comme OSV.dev et des sources fondées sur la NVD.
- Rendre compte : indiquer la couverture, y compris les fichiers qui n’ont pas pu être extraits ou identifiés.
Ce qu’une analyse de firmware peut et ne peut pas vous dire
L’identification de binaires est par nature moins certaine que la lecture d’un fichier de verrouillage. Un binaire peut avoir été corrigé sans que sa chaîne de version change, ou compilé sans la fonctionnalité qui rend une vulnérabilité exploitable. Les constats issus d’un firmware sont donc un point de départ pour une revue technique, pas un verdict.
Certaines images ne peuvent pas du tout être analysées de l’extérieur : les images chiffrées ou signées de manière opaque, et les firmwares bare-metal ou RTOS dépourvus de système de fichiers. Un scanner doit le dire plutôt que de renvoyer un résultat vide et faussement rassurant.
Le firmware et le Cyber Resilience Act
Le CRA couvre les produits matériels comportant des éléments numériques et leurs logiciels ; le firmware d’un appareil connecté fait donc partie de ce que le fabricant doit sécuriser, documenter et mettre à jour. L’exigence de SBOM (nomenclature des logiciels) de l’annexe I, partie II, s’y applique, tout comme la notification au titre de l’article 14 lorsqu’un composant du firmware est activement exploité.
Pour des appareils qui restent en service pendant des années, la difficulté pratique consiste à conserver l’inventaire de chaque image publiée et à le revérifier à mesure que de nouvelles vulnérabilités sont publiées.
Préparer les images pour l’analyse
Quelques habitudes rendent les analyses de firmware plus complètes et plus faciles à exploiter.
- Analyser l’image exacte que vous livrez, pas une version de développement.
- Conserver les manifestes de build Yocto ou Buildroot avec l’image ; ils apportent le détail des paquets.
- Consigner la version de l’image et le produit auquel elle appartient, pour que les constats correspondent aux versions publiées.
- Relancer l’analyse quand les données de vulnérabilités changent, pas seulement quand l’image change.
Lire les résultats : couverture et niveau de confiance
Deux chiffres comptent autant que la liste des constats : la part de l’image qui a pu être extraite, et le nombre de composants qui ont pu être identifiés. Un résultat avec peu de constats et une faible couverture ne dit pas grand-chose ; un résultat avec de nombreux constats issus du rapprochement de binaires doit être examiné avant de parvenir à un client ou à une autorité.
Consignez la décision pour chaque constat qui compte : affecté, non affecté et pourquoi, ou corrigé dans une version précise. Ce sont ces décisions que transmet un document VEX, et que demanderont une notification au titre de l’article 14 ou un questionnaire client.
Disponible aujourd’hui dans KROMSE
Aujourd’hui, l’analyse de firmware dans KROMSE couvre les images basées sur Linux.
- Importez une image firmware basée sur Linux jusqu’à 512 Mo ; KROMSE en extrait le contenu de manière récursive.
- Les paquets sont listés et confrontés à OSV.dev, et les binaires sont rapprochés hors ligne de données de vulnérabilités fondées sur la NVD.
- Le système de fichiers racine extrait est aussi vérifié pour y détecter les erreurs de configuration et les secrets embarqués, dont les valeurs ne sont jamais stockées.
- Les fichiers PX4 .px4 sont d’abord sortis de leur enveloppe, puis décompressés.
- Chaque analyse produit des SBOM CycloneDX et SPDX, et indique ce qui n’a pas pu être extrait ou identifié.
- Les images chiffrées, ainsi que les firmwares bare-metal ou RTOS, sont signalés comme non analysables plutôt que comme sains.
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
Quels firmwares KROMSE peut-il analyser ?
Les images firmware basées sur Linux jusqu’à 512 Mo, que KROMSE extrait à travers les systèmes de fichiers embarqués courants avant d’identifier les composants. Les images chiffrées et les firmwares bare-metal ou RTOS sans système de fichiers ne sont pas encore pris en charge, et le résultat de l’analyse l’indique.
En quoi une analyse de firmware diffère-t-elle d’une analyse du code source ?
Une analyse du code source lit les dépendances que déclare votre dépôt. Une analyse de firmware examine l’image finale, y compris le système d’exploitation, les bibliothèques et les paquets ajoutés par le système de build, qui n’apparaissent souvent jamais dans votre dépôt. Les deux sont utiles ; l’image est ce que vos clients exécutent.
Les constats issus d’un firmware sont-ils toujours exacts ?
Aucun scanner ne peut le promettre. Identifier des binaires par leurs chaînes de version peut passer à côté de correctifs rétroportés ou signaler un composant présent mais non exploitable. Traitez les constats issus d’un firmware comme des éléments de preuve qu’un ingénieur doit examiner, et consignez la décision.
KROMSE peut-il analyser le firmware de drones PX4 ?
En partie. KROMSE sort les fichiers PX4 .px4 de leur enveloppe et les soumet aux mêmes étapes d’extraction et de vérification que les autres firmwares, mais l’identification des composants basés sur NuttX qu’ils contiennent n’est pas encore disponible. L’image Linux d’un ordinateur compagnon peut être analysée intégralement. Une couverture propre à la robotique figure sur la feuille de route.
Le CRA s’applique-t-il au firmware ?
Oui, en tant que partie d’un produit comportant des éléments numériques. Le firmware d’un appareil connecté doit respecter les exigences essentielles, être couvert par le SBOM et la gestion des vulnérabilités, et relève de la notification au titre de l’article 14 si l’un de ses composants est activement exploité.