SBOM: ENISA trasforma l’elenco delle dipendenze in una pratica operativa per le PMI.

La novità: una guida per usare la SBOM, non soltanto per produrla

Il documento ENISA nasce per organizzazioni nelle prime fasi di adozione e descrive architettura, flussi di dati, ciclo di vita, rischi e misure di sicurezza. È una guida tecnica e non un’interpretazione legale del Cyber Resilience Act: le raccomandazioni possono andare oltre il minimo normativo e non creano nuovi obblighi.

La distinzione è importante. Il Cyber Resilience Act richiede ai produttori di prodotti con elementi digitali di identificare e documentare vulnerabilità e componenti, anche tramite una SBOM in formato diffuso e leggibile dalle macchine che copra almeno le dipendenze di primo livello. ENISA spiega invece come rendere quel documento affidabile e utile nel tempo.

La guida si rivolge anche agli acquirenti e agli operatori. Una PMI che non sviluppa software può usare gli stessi criteri per chiedere trasparenza ai fornitori, collegare un avviso di sicurezza alle applicazioni realmente in uso e capire chi deve intervenire quando una dipendenza diventa vulnerabile.

Che cosa contiene una distinta software affidabile

ENISA definisce la SBOM come un inventario strutturato dei componenti e delle loro dipendenze. Le informazioni possono arrivare da repository, manifest e lock file dei package manager, artefatti di build, immagini container e analisi dei file binari. Per ogni componente servono almeno un nome riconoscibile, la versione, il produttore o autore, identificatori univoci e le relazioni di dipendenza.

I formati prevalenti sono CycloneDX e SPDX. Entrambi permettono elaborazione automatica, scambio tra strumenti e correlazione con basi dati delle vulnerabilità. La guida riporta che quasi il 73% delle organizzazioni coinvolte nello studio ENISA 2026 usa uno di questi due formati. Un foglio compilato a mano o un PDF possono essere leggibili, ma riducono automazione e scalabilità.

Non esiste però una sola SBOM valida per ogni momento. Una distinta ricavata dal codice sorgente vede ciò che è dichiarato; una generata durante il build fotografa ciò che entra nella compilazione; una analizzata dopo il build esamina pacchetti, eseguibili o container; una SBOM di runtime rileva anche moduli caricati dinamicamente. Prima di scegliere lo strumento bisogna chiarire quale prodotto, fase e decisione si vogliono coprire.

• Componente, versione e soggetto che lo produce o mantiene.
• Identificatori coerenti, come Package URL o CPE, e hash dell’artefatto.
• Dipendenze dirette e transitive con relazioni esplicite.
• Formato standard e leggibile dalle macchine, come CycloneDX o SPDX.
• Data, contesto di generazione e collegamento alla release esatta.

Il rischio più comune: una SBOM corretta collegata al prodotto sbagliato

Un inventario può essere completo e comunque indurre in errore se non è legato senza ambiguità al software distribuito. ENISA segnala il rischio di associare la distinta a una release, un’immagine container o un pacchetto diverso da quello realmente installato. Il risultato sono falsi positivi, vulnerabilità mancate e priorità di intervento sbagliate.

Per evitare questo scollamento, la SBOM deve essere generata per ogni release e collegata all’artefatto tramite un hash o un digest immutabile. Versione del prodotto, identificativo del build, data, firma e posizione del file devono permettere di ricostruire la catena senza affidarsi alla memoria di chi ha eseguito il rilascio.

Trasparenza non significa pubblicare tutto su internet

La SBOM può rivelare framework, versioni, servizi e dipendenze utili anche a un attaccante. La guida include la divulgazione delle informazioni tra i rischi da gestire e raccomanda accessi basati sui ruoli, minimo privilegio, trasporto sicuro, log e repository protetti. Il Cyber Resilience Act non impone ai produttori di rendere pubblica la distinta.

Una PMI deve quindi definire chi può generarla, chi la valida, chi la riceve e per quanto tempo viene conservata. Il fornitore può metterla a disposizione attraverso un canale autenticato, con condizioni contrattuali e livelli di dettaglio coerenti con il destinatario. Condividere meno non deve però diventare un alibi per non fornire le informazioni necessarie alla gestione del rischio.

Dall’elenco delle librerie alla priorità di intervento

Generare una SBOM e non consumarla produce soltanto un allegato. Il valore operativo nasce quando i componenti vengono confrontati con fonti di vulnerabilità e collegati a tempi di correzione, responsabilità ed escalation. Un nuovo avviso può così diventare una ricerca precisa: quali prodotti contengono quel componente, in quale versione e presso quali ambienti?

Non tutte le corrispondenze richiedono la stessa urgenza. Un componente elencato può non essere raggiungibile nel modo necessario allo sfruttamento, mentre un altro può essere esposto su un sistema critico. ENISA raccomanda di combinare SBOM, informazioni VEX sull’effettiva vulnerabilità, esposizione, criticità dell’asset, disponibilità della patch e controlli compensativi.

Questa valutazione evita due estremi: ignorare un allarme perché l’inventario è incompleto oppure bloccare il lavoro per centinaia di segnalazioni non contestualizzate. La decisione finale deve lasciare una traccia: vulnerabilità valutata, impatto, azione, responsabile, scadenza ed eventuale motivo per cui non è applicabile.

• Correlare componenti e versioni con vulnerabilità note.
• Verificare se il componente è presente, esposto e realmente sfruttabile.
• Dare priorità a rischio, criticità e disponibilità di mitigazioni.
• Assegnare proprietario, tempo di risposta e percorso di escalation.
• Conservare esito e prove della decisione per audit e incident response.

Cinque domande da inserire negli acquisti e nei rinnovi software

Per molte PMI il primo passo non sarà installare un generatore, ma migliorare le domande rivolte ai fornitori. Un gestionale, un’applicazione verticale o un dispositivo con software incorporato porta con sé componenti che l’azienda cliente non vede. Chiedere una SBOM senza definire qualità, aggiornamento e accesso rischia però di produrre un file inutilizzabile.

• Riceveremo CycloneDX, SPDX o un altro formato standard e machine-readable?
• La distinta include dipendenze dirette, transitive e componenti incorporati?
• Come viene collegata alla release installata e quando viene aggiornata?
• Chi ci avvisa se emerge una vulnerabilità e quali sono i tempi di correzione?
• Come accediamo alle versioni storiche se dobbiamo ricostruire un incidente?

Un piano minimo in trenta giorni per una PMI

Nella prima settimana si sceglie un solo prodotto: quello esposto a internet, più importante per il business o destinato a clienti. Si identifica la release reale, il responsabile, il repository o fornitore e il processo con cui viene costruita o aggiornata. L’obiettivo non è censire subito ogni computer, ma creare un caso verificabile.

Nella seconda settimana si genera o richiede una SBOM in CycloneDX o SPDX e si controllano componenti, versioni, dipendenze e identificatori. Il file viene associato all’artefatto con hash o digest. Errori, dipendenze non riconosciute e componenti binari restano dichiarati come lacune note, non nascosti per far apparire completo il risultato.

Nella terza settimana si collega la distinta al processo di vulnerability management: fonte degli avvisi, soglia di priorità, referente, scadenze ed evidenze da conservare. Nella quarta si automatizza la generazione nel build o nel rilascio, si protegge l’archivio e si prova una vulnerabilità simulata per verificare ricerca, decisione e comunicazione.

Il risultato atteso non è una dashboard perfetta. È la capacità di rispondere rapidamente con un prodotto, una versione, un elenco di componenti attendibile e una persona incaricata di agire. Da quel primo caso il metodo può estendersi agli altri sistemi e diventare un requisito nei contratti.

Nota sulla visual editoriale

La visual di apertura è un’immagine originale Scenicom realizzata con strumenti di intelligenza artificiale generativa e direzione creativa umana. Rappresenta un prodotto software come una struttura a strati: componenti e dipendenze diventano visibili, collegati a un nodo di verifica, senza riprodurre interfacce, documenti o marchi di terzi.