Sicurezza del firmware
Scanner di vulnerabilità firmware per immagini basate su Linux
Uno scanner di vulnerabilità firmware estrae il contenuto di un’immagine firmware, identifica i componenti software al suo interno e li confronta con le vulnerabilità note. KROMSE lo fa già oggi per le immagini firmware basate su Linux fino a 512 MB e ti dice chiaramente cosa non è riuscito a vedere.
Piano Free, nessuna carta richiesta.
Perché il firmware ha bisogno di una scansione dedicata
Il firmware è il punto in cui si ferma la scansione del codice sorgente. L’immagine di un dispositivo contiene il codice del produttore, ma anche un kernel Linux, una libreria C, BusyBox, una libreria SSL e decine di pacchetti inclusi da un board support package o da un sistema di build come Yocto o Buildroot. Molti di questi non compaiono mai in un repository di proprietà del team di prodotto.
L’immagine è anche ciò che i clienti eseguono davvero. Scansionarla risponde alla domanda che conta per il Cyber Resilience Act: quali componenti, in quali versioni, si trovano nel prodotto immesso sul mercato.
Come funziona l’analisi del firmware
Una scansione si svolge in tre fasi: estrazione, identificazione, confronto. Ognuna può fallire in silenzio, quindi un buon scanner riporta ciò che non è riuscito a fare con la stessa chiarezza di ciò che ha trovato.
- Estrazione: il contenuto dell’immagine viene estratto ricorsivamente, attraverso file system come SquashFS, JFFS2, CramFS e UBI e le intestazioni dei produttori.
- Identificazione: i pacchetti vengono elencati a partire dai database dei pacchetti e i binari vengono identificati, ad esempio tramite le stringhe di versione.
- Confronto: i componenti identificati vengono confrontati con dati sulle vulnerabilità come OSV.dev e fonti basate su NVD.
- Report: viene indicata la copertura, compresi i file che non è stato possibile estrarre o identificare.
Cosa può e non può dirti una scansione del firmware
L’identificazione dei binari è per sua natura meno certa della lettura di un lockfile. Un binario può essere stato corretto senza che la sua stringa di versione cambi, oppure compilato senza la funzionalità che rende sfruttabile una vulnerabilità. Le rilevazioni sul firmware sono quindi un punto di partenza per la revisione tecnica, non un verdetto.
Alcune immagini non si possono analizzare affatto dall’esterno: le immagini cifrate o firmate e opache, e il firmware bare-metal o RTOS privo di file system. Uno scanner dovrebbe dirlo, anziché restituire un risultato vuoto e rassicurante.
Il firmware e il Cyber Resilience Act
Il CRA riguarda i prodotti hardware con elementi digitali e il loro software, quindi il firmware di un dispositivo connesso fa parte di ciò che il fabbricante deve proteggere, documentare e aggiornare. Gli si applica il requisito della SBOM (distinta base del software) dell’allegato I, parte II, e anche la segnalazione dell’articolo 14 quando un componente del firmware è attivamente sfruttato.
Per i dispositivi che restano in campo per anni, la sfida pratica è conservare l’inventario di ogni immagine rilasciata e ricontrollarlo man mano che vengono pubblicate nuove vulnerabilità.
Preparare le immagini per la scansione
Alcune buone abitudini rendono le scansioni del firmware più complete e più facili da tradurre in azioni.
- Scansiona l’immagine esatta che distribuisci, non una build di sviluppo.
- Conserva i manifest di build di Yocto o Buildroot insieme all’immagine: aggiungono dettagli sui pacchetti.
- Registra la versione dell’immagine e il prodotto a cui appartiene, così che le rilevazioni corrispondano alle release.
- Ripeti la scansione quando cambiano i dati sulle vulnerabilità, non solo quando cambia l’immagine.
Leggere i risultati: copertura e affidabilità
Due numeri contano quanto l’elenco delle rilevazioni: quanta parte dell’immagine è stata estratta e quanti componenti è stato possibile identificare. Un risultato con poche rilevazioni e una copertura bassa dice poco; un risultato con molte rilevazioni derivate dal confronto dei binari va esaminato prima di arrivare a un cliente o a un’autorità.
Registra la decisione per ogni rilevazione rilevante: interessato, non interessato e perché, oppure corretto in una release specifica. Sono queste decisioni che un documento VEX comunica, e che una segnalazione ai sensi dell’articolo 14 o il questionario di un cliente chiederanno.
Disponibile oggi in KROMSE
Oggi la scansione del firmware in KROMSE copre le immagini basate su Linux.
- Carica un’immagine firmware basata su Linux fino a 512 MB; KROMSE la estrae ricorsivamente.
- I pacchetti vengono elencati e confrontati con OSV.dev, e i binari vengono confrontati offline con dati sulle vulnerabilità basati su NVD.
- Il file system root estratto viene controllato anche per errori di configurazione e segreti incorporati, i cui valori non vengono mai memorizzati.
- Il contenitore dei file PX4 .px4 viene aperto prima dell’estrazione.
- Ogni scansione produce SBOM CycloneDX e SPDX e indica cosa non è stato possibile estrarre o identificare.
- Le immagini cifrate e il firmware bare-metal o RTOS vengono segnalati come non analizzabili, non come puliti.
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
Quale firmware può scansionare KROMSE?
Immagini firmware basate su Linux fino a 512 MB, che KROMSE estrae attraverso i file system embedded più comuni prima di identificarne i componenti. Le immagini cifrate e il firmware bare-metal o RTOS privo di file system non sono ancora supportati, e il risultato della scansione lo indica.
In cosa si differenzia una scansione del firmware da una scansione del codice sorgente?
Una scansione del codice sorgente legge le dipendenze dichiarate dal tuo repository. Una scansione del firmware esamina l’immagine finita, compresi il sistema operativo, le librerie e i pacchetti aggiunti dal sistema di build, che spesso non compaiono mai nel tuo repository. Sono utili entrambe; l’immagine è ciò che eseguono i clienti.
Le rilevazioni sul firmware sono sempre accurate?
Nessuno scanner può garantirlo. L’identificazione dei binari tramite stringhe di versione può non accorgersi di patch applicate in backport o segnalare un componente presente ma non sfruttabile. Tratta le rilevazioni sul firmware come evidenze da far esaminare a un ingegnere, e registra la decisione.
KROMSE può scansionare il firmware dei droni PX4?
In parte. KROMSE apre il contenitore dei file PX4 .px4 e li sottopone alla stessa estrazione e agli stessi controlli degli altri firmware, ma l’identificazione dei componenti basati su NuttX al loro interno non è ancora disponibile. L’immagine di un companion computer basato su Linux può essere scansionata per intero. La copertura specifica per la robotica è nella roadmap.
Il CRA si applica al firmware?
Sì, in quanto parte di un prodotto con elementi digitali. Il firmware di un dispositivo connesso deve soddisfare i requisiti essenziali, essere coperto dalla SBOM e dalla gestione delle vulnerabilità e rientrare nella segnalazione dell’articolo 14 se un suo componente è attivamente sfruttato.