Software bill of materials (SBOM)

La distinta base del software, in inglese software bill of materials (SBOM), è l’elenco degli ingredienti di un software: ogni componente e libreria che contiene, la versione esatta, chi l’ha fornita e come le parti dipendono l’una dall’altra. È scritta in un formato leggibile dalle macchine, così gli strumenti possono confrontarla in automatico con gli elenchi delle vulnerabilità note. In un dispositivo connesso l’SBOM descrive il firmware, cioè il software che gira sul dispositivo: il sistema operativo, il software di rete, la libreria TLS che cifra le connessioni, i driver e l’SDK del produttore del chip.

A cosa serve l’SBOM in un dispositivo connesso?

Serve a sapere in fretta quali prodotti e quali versioni del firmware contengono una libreria, quando in quella libreria viene scoperto un difetto. Alle vulnerabilità note viene assegnato un identificativo pubblico, il CVE, e un solo CVE in una libreria TLS o in un parser di immagini può riguardare molti prodotti di molti produttori. Con un SBOM per ogni versione del firmware basta una ricerca; senza, gli ingegneri devono scavare tra vecchi file di build. Ne guadagna anche chi compra: l’SBOM mostra quanto sono vecchi i componenti di un dispositivo e aiuta il team di sicurezza a decidere quali dispositivi correggere con una patch o isolare per primi. Il quadro generale è in Fondamenti di sicurezza IoT.

Cosa contiene un SBOM?

Come minimo nome, versione, fornitore e identificativo di ogni componente, più le dipendenze tra un componente e l’altro. Gli elementi minimi pubblicati dall’NTIA statunitense nel luglio 2021 elencano sette campi: fornitore, nome del componente, versione, altri identificativi univoci, relazione di dipendenza, autore dei dati dell’SBOM e marca temporale (rapporto NTIA). Molti SBOM aggiungono le informazioni sulle licenze e gli hash crittografici, impronte che dimostrano che un file è proprio quello elencato.

Che differenza c’è tra SPDX e CycloneDX?

Sono i due formati principali per gli SBOM, entrambi aperti e supportati dagli strumenti più diffusi. SPDX nasce dalla Linux Foundation: la sua versione 2.2.1 è lo standard internazionale ISO/IEC 5962:2021, e l’attuale specifica SPDX 3.0.1 aggiunge profili per la sicurezza, le build, i modelli di AI e i dataset. CycloneDX nasce dalla comunità di sicurezza OWASP: la versione 1.7 è pubblicata da Ecma International come ECMA-424 e copre componenti software e hardware, servizi e vulnerabilità. L’ENISA, l’agenzia dell’UE per la cybersicurezza, li chiama i due formati predominanti nella sua nota tecnica sugli SBOM (Technical Advisory) di ottobre 2026. Nella nota SPDX è descritto come un quadro ampio, che porta anche dati dettagliati sulle licenze, e CycloneDX come un formato orientato alla sicurezza.

L’SBOM è obbligatorio per legge?

Nell’UE sì, da dicembre 2027, in base al Cyber Resilience Act, il regolamento sulla ciberresilienza, per i prodotti con elementi digitali, una categoria che comprende quasi tutti i dispositivi connessi. L’allegato I, parte II, punto 1, del regolamento (UE) 2024/2847 chiede ai fabbricanti di redigere una distinta base del software “in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto”. L’obbligo si applica dall’11 dicembre 2027 (articolo 71, paragrafo 2). L’SBOM fa parte della documentazione tecnica (allegato VII), va consegnato a un’autorità di vigilanza del mercato su sua richiesta motivata e non deve per forza essere reso pubblico (considerando 77). La Commissione può fissarne formato ed elementi con un successivo atto di esecuzione, cioè un insieme di regole UE di dettaglio (articolo 13, paragrafo 24). Il resto del regolamento è spiegato in La normativa sulla sicurezza IoT.

Negli Stati Uniti non c’è una regola generale per tutti i prodotti, ma dal 29 marzo 2023 la FDA richiede un SBOM per i dispositivi medici che la legge chiama “cyber devices”. L’SBOM deve far parte della premarket submission, il dossier che il produttore presenta per ottenere l’autorizzazione alla vendita di un dispositivo, come prevede la sezione 524B del Federal Food, Drug, and Cosmetic Act (FAQ della FDA sulla cybersicurezza).

Come si crea e si tiene aggiornato un SBOM?

Va generato in automatico dalla build a ogni release, non scritto a mano. Gli strumenti di build e gli scanner leggono gli elenchi dei pacchetti e il codice che viene compilato e producono file SPDX o CycloneDX; la nota tecnica dell’ENISA elenca generatori open source, compresi quelli integrati nei sistemi di build Yocto e Zephyr usati per i dispositivi embedded. Conserva ogni SBOM insieme alla versione del firmware che descrive, così dopo un aggiornamento over-the-air sai ancora cosa gira su ogni dispositivo sul campo, e affiancalo a un processo di divulgazione delle vulnerabilità, perché le segnalazioni che arrivano dall’esterno diventino correzioni.

Parte del Glossario IoT. Hai trovato un errore o manca un termine? Scrivici.