SBOM: la distinta base del software che il CRA ti chiede

Se non sai cosa c'è dentro il software della tua macchina, non sai nemmeno se sei esposto quando esce una vulnerabilità critica. È il problema che la Software Bill of Materials (SBOM) risolve, ed è il motivo per cui il Regolamento (UE) 2024/2847 (CRA) la considera uno strumento necessario, anche quando non prevede l'obbligo di pubblicarla.

La SBOM è la distinta base del tuo software: elenca ogni componente, ogni libreria, ogni dipendenza usata per costruire un prodotto. Non è un documento di marketing né un allegato da mostrare all'organismo notificato. È lo strumento che ti permette, quando arriva l'avviso di una CVE su una libreria open source, di rispondere in minuti "sì, la usiamo nel firmware v3.2" invece che in settimane di verifiche manuali sul codice.

Cosa deve contenere davvero

Una SBOM utile non è un elenco generico di "librerie usate". Deve indicare componente, versione esatta e relazioni di dipendenza: se la libreria A dipende dalla libreria B, e B ha la falla, devi poterlo vedere subito.

Il livello di dettaglio si misura su un solo criterio: la capacità di reagire a una vulnerabilità nota. Se guardando la tua SBOM non riesci a stabilire in pochi minuti se un CVE ti riguarda, il documento non sta facendo il suo lavoro, a prescindere da quanto sia formalmente completo.

non serve un formato esotico. Standard come SPDX o CycloneDX sono pensati proprio per essere leggibili da strumenti automatici che incrociano SBOM e database di vulnerabilità.

Il problema della SBOM statica

Una SBOM fatta al lancio del prodotto e mai più toccata perde valore a ogni release successiva. Ogni aggiornamento firmware, ogni patch, ogni nuova versione di una dipendenza cambia la composizione reale del software: se il documento non segue quel cambiamento, diventa fuorviante invece che utile.

Il punto debole tipico è proprio qui: si genera la SBOM per il fascicolo tecnico iniziale e poi si dimentica per anni. Nel frattempo il prodotto in campo ha già ricevuto tre aggiornamenti che nessuno ha tracciato. Quando arriva la vulnerabilità critica, la SBOM in archivio descrive un software che non esiste più.

una SBOM disallineata dalla versione realmente installata è peggio di nessuna SBOM. Ti dà una falsa sicurezza mentre cerchi la falla nel posto sbagliato.

Il collegamento con l'obbligo di notifica in 24 ore

Qui la SBOM smette di essere un esercizio di buona pratica e diventa condizione abilitante per un obbligo di legge. Il CRA impone, dall'11 settembre 2026, la notifica a ENISA e al CSIRT competente delle vulnerabilità sfruttate attivamente entro 24 ore dalla conoscenza dell'evento, come previsto dall'art. 14 del Regolamento (UE) 2024/2847.

Ventiquattro ore sono poche, se prima devi capire manualmente quali prodotti in campo montano il componente vulnerabile. Con una SBOM aggiornata e interrogabile, quella verifica è una query. Senza, è un'indagine forense sul tuo stesso codice, con l'orologio della notifica obbligatoria che intanto corre.

Cosa significa per te

• Genera la SBOM per ogni prodotto software fin dalla prima release, non solo per il fascicolo tecnico di lancio.
• Aggiorna la SBOM a ogni nuova versione o patch: deve rispecchiare esattamente cosa gira in campo, non cosa girava al collaudo.
• Usa un formato leggibile da strumenti automatici (SPDX o CycloneDX) per incrociare rapidamente componenti e CVE note.
• Collega la SBOM al tuo processo interno di gestione vulnerabilità: deve essere il primo documento che consulti quando scatta un allarme, non l'ultimo.
• Verifica che la profondità delle dipendenze tracciate sia sufficiente a coprire anche le librerie di terzo livello, dove spesso si annidano le falle più vecchie.

Una SBOM aggiornata è anche materiale di verifica che Clausify controlla insieme al resto del fascicolo tecnico, per capire se la documentazione del tuo prodotto tiene il passo con quello che effettivamente rilasci.