Sicurezza del firmware
Sicurezza firmware embedded per dispositivi RTOS e bare-metal
La sicurezza del firmware embedded consiste nel sapere quali componenti girano su un microcontrollore o su un dispositivo RTOS e nel mantenerli privi di vulnerabilità note, anche quando non c’è un sistema operativo da ispezionare. KROMSE oggi copre il firmware basato su Linux; le immagini bare-metal e RTOS e i componenti hardware sono nella roadmap.
Piano Free, nessuna carta richiesta.
Perché il firmware RTOS e bare-metal è difficile da scansionare
Il firmware basato su Linux contiene un file system con database dei pacchetti e binari separati, quindi uno scanner può estrarlo e leggerne il contenuto. Il firmware bare-metal e RTOS è di solito un unico blob collegato staticamente: l’applicazione, il kernel RTOS (FreeRTOS, Zephyr, ThreadX, NuttX e altri), stack di rete come lwIP e librerie crittografiche come Mbed TLS o wolfSSL sono compilati insieme, senza nomi né file di versione.
Identificare i componenti in un’immagine di questo tipo richiede firme di codice noto oppure metadati di build forniti dal produttore. Senza nessuno dei due, uno scanner onesto può solo dire che non è stato possibile estrarre nulla.
Partire dalla build, non dal binario
Per i prodotti embedded l’inventario più affidabile proviene di solito dal sistema di build, perché il fabbricante ce l’ha e uno scanner che guarda il binario no.
- Zephyr: il manifest west (west.yml) fissa i moduli e le loro revisioni.
- ESP-IDF: idf_component.yml e il file di lock delle dipendenze elencano i componenti gestiti.
- PlatformIO e Arduino: platformio.ini, library.properties e i file degli sketch indicano le librerie.
- Conan e vcpkg: i lockfile registrano le versioni dei pacchetti C e C++.
- Yocto e Buildroot: i manifest dell’immagine e delle licenze elencano ogni pacchetto di una build Linux.
Cosa si aspetta il Cyber Resilience Act
Il CRA non fa eccezioni per i dispositivi piccoli. Un prodotto basato su microcontrollore con una connessione di rete è un prodotto con elementi digitali; il suo fabbricante ha bisogno di una SBOM (distinta base del software) che includa almeno le dipendenze di primo livello, di un processo di gestione delle vulnerabilità, di aggiornamenti di sicurezza per il periodo di assistenza e della segnalazione ai sensi dell’articolo 14.
Diversi tipi di componenti compaiono negli elenchi dei prodotti importanti del regolamento, come i microprocessori e i microcontrollori con funzionalità legate alla sicurezza nella classe I e i microprocessori e microcontrollori a prova di manomissione nella classe II, che comporta una valutazione della conformità più rigorosa.
Anche i componenti hardware fanno parte del quadro
Le vulnerabilità vengono pubblicate anche per l’hardware: processori, chipset radio, secure element. Una distinta base dell’hardware (hardware bill of materials) permette a un fabbricante di verificare quali dei suoi prodotti usano un componente interessato. Il requisito SBOM del CRA riguarda il software, ma la gestione delle vulnerabilità copre l’intero prodotto.
Aggiornamenti per i dispositivi in campo
Trovare un componente vulnerabile è solo metà dell’obbligo. Il CRA impone che gli aggiornamenti di sicurezza siano distribuiti in modo sicuro e senza ritardo per l’intero periodo di assistenza, che deve essere di almeno cinque anni a meno che non si preveda un uso più breve del prodotto, e ogni aggiornamento deve restare disponibile per almeno dieci anni o per il restante periodo di assistenza.
Per i prodotti basati su microcontrollore questo significa pianificare il percorso di aggiornamento in fase di progettazione: una catena di secure boot, immagini firmate, memoria flash sufficiente per un’immagine di ripristino e un modo per raggiungere i dispositivi che si connettono raramente. Aggiungere tutto questo dopo il lancio è di solito impossibile.
Passi pratici da fare ora
Finché gli strumenti non sapranno leggere ogni immagine, sono i registri del fabbricante a sostenere gran parte del peso.
- Conserva i manifest di build e i lockfile di ogni versione firmware rilasciata.
- Registra per ogni prodotto le versioni dell’RTOS, dello stack di rete e della libreria crittografica.
- Iscriviti agli avvisi di sicurezza di ogni RTOS e libreria che distribuisci.
- Pianifica come i dispositivi in campo riceveranno gli aggiornamenti di sicurezza per il periodo di assistenza.
Disponibile oggi in KROMSE
Cosa copre oggi KROMSE per i prodotti embedded:
- Immagini firmware basate su Linux: estratte, inventariate e confrontate con le vulnerabilità note.
- I manifest di build embedded vengono elencati nell’inventario (Zephyr west.yml, ESP-IDF, PlatformIO, Arduino, Conan, vcpkg, CMake, Yocto e Buildroot); la maggior parte non viene ancora confrontata con gli avvisi di sicurezza.
- I manifest Yocto e Buildroot possono essere caricati come una SBOM e vengono confrontati con OSV.dev.
- Le immagini bare-metal e RTOS vengono segnalate come non analizzabili, mai come pulite.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q1 2027Firmware bare-metal e RTOS. KROMSE identificherà i componenti nei firmware privi di un file system Linux, come le immagini bare-metal e RTOS basate su FreeRTOS o Zephyr.
- In arrivo · Q1 2027Componenti hardware. KROMSE confronterà i componenti hardware del tuo prodotto con gli avvisi di sicurezza hardware pubblicati.
- In arrivo · Q4 2026 (dicembre)Sicurezza per la robotica. KROMSE aggiungerà gli avvisi di sicurezza per ROS 2, l’identificazione dei componenti all’interno dei firmware PX4 e ArduPilot e dati sulle vulnerabilità specifici per i robot.
Domande frequenti
KROMSE può scansionare firmware FreeRTOS o Zephyr?
Non ancora come immagine binaria. KROMSE elenca nel suo inventario i manifest di build di Zephyr e di altri sistemi embedded, ma l’identificazione dei componenti all’interno delle immagini bare-metal e RTOS è nella roadmap. La scansione di un’immagine di questo tipo segnala che non è stato possibile estrarre nulla.
Il CRA si applica ai dispositivi basati su microcontrollore?
Sì, se il dispositivo è un prodotto con elementi digitali con una connessione dati diretta o indiretta. Le dimensioni non contano. I microprocessori e i microcontrollori con funzionalità legate alla sicurezza figurano tra i prodotti importanti dell’allegato III.
Cos’è una distinta base dell’hardware?
Un elenco dei componenti hardware di un prodotto, come processori, chipset radio e secure element, con i relativi codici articolo. Permette a un fabbricante di scoprire rapidamente quali prodotti usano un componente per cui è stata pubblicata una vulnerabilità.
Il periodo di assistenza vale anche per i dispositivi piccoli?
Sì. Ogni prodotto con elementi digitali ha bisogno di un periodo di assistenza che rifletta il tempo di utilizzo previsto e sia di almeno cinque anni, a meno che non se ne preveda un uso più breve. Gli aggiornamenti di sicurezza vanno forniti per tutto quel periodo, quindi il meccanismo di aggiornamento deve essere previsto fin dall’inizio.
Come si costruisce una SBOM per un firmware RTOS?
Parti dal sistema di build: il manifest west di Zephyr, i file di lock dei componenti ESP-IDF, la configurazione di PlatformIO o i lockfile di Conan e vcpkg registrano ciò che è entrato nell’immagine. Convertili in CycloneDX o SPDX e conservane uno per ogni release.