SBOM e Cyber Resilience Act: la sicurezza del software industriale - Agenda Digitale

L’Europa ha introdotto il Cyber Resilience Act (CRA) un regolamento che ridefinisce gli obblighi di cybersicurezza per tutti i prodotti con elementi digitali immessi sul mercato europeo: dal software gestionale ai sistemi industriali connessi.L’obiettivo è ridurre le vulnerabilità sistemiche, superare la frammentazione normativa e trasferire la responsabilità della sicurezza dai consumatori finali ai produttori di software e dispositivi.Dall’11 settembre 2026 scattano gli obblighi di notifica delle vulnerabilità attivamente sfruttate e degli incidenti gravi alle autorità nazionali e all’ENISA. Mentre, dall’11 dicembre 2027 si applicheranno i requisiti essenziali completi, inclusa la marcatura CE obbligatoria: da quella data nessun prodotto con elementi digitali potrà essere immesso sul mercato UE senza dimostrare la compliance lungo tutto il proprio ciclo di sviluppo.Inoltre, il regolamento porta al centro della compliance un documento che fino a pochi anni fa era considerato una buona pratica opzionale: il Software Bill of Materials (SBOM), i.e. l’inventario machine-readable di componenti, librerie e dipendenze software di un prodotto.Indice degli argomenti

Supply chain software: da rischio tecnico a obbligo normativoChe cos’è lo SBOM?Perché le organizzazioni hanno bisogno di SBOM?Requisiti relativi allo SBOM ai sensi del CRASPDX 3.0 e CycloneDX: gli standard tecnici di riferimento dello SBOMTracciabilità nella supply chain industriale e la responsabilità dei produttoriSBOM e CRA: una roadmap alla compliance1. Effettuare una valutazione dello stato di preparazione2. Definire la governance interna3. Automatizzare la generazione della SBOM4. Integrare l’SBOM in tutto il ciclo di vita dello sviluppo del software5. Garantire la compliance e il monitoraggio continuiDalla compliance alla resilienza della supply chainSupply chain software: da rischio tecnico a obbligo normativoEventi come l’attacco a SolarWinds (2020) e la vulnerabilità Log4Shell hanno dimostrato come la supply chain software sia uno dei punti più deboli dell’ecosistema digitale. Secondo ENISA, gli attacchi alla catena di fornitura sono tra le minacce più rilevanti per la cybersicurezza europea e spesso fungono da vettore per ransomware e compromissioni su larga scala.Pertanto, in questo contesto, la tracciabilità del software non è più una best practice, ma un requisito regolatorio per l’accesso al mercato UE.Che cos’è lo SBOM?Lo SBOM – (Software Bill of Materials) è un software che elenca in modo formale tutti i componenti di un prodotto software, comprese le dipendenze open source. La National Telecommunications and Information Administration statunitense aveva definito già nel 2021 gli elementi minimi che uno SBOM deve contenere, ovvero: fornitore e versione di ogni componente, identificatori univoci, relazioni di dipendenza, autore e data di generazione del documento.Una struttura semplice sulla carta, ma complessa da applicare a software enterprise che integrano centinaia o migliaia di dipendenze transitive.Inoltre, la distinzione tra dipendenze dirette incluse esplicitamente dagli sviluppatori e dipendenze transitive richieste a loro volta da una dipendenza diretta, spesso invisibili al team, è centrale nella gestione del rischio. Ed il caso Log4Shell ha dimostrato come una vulnerabilità sepolta in una libreria di terzo livello possa propagarsi nell’intero ecosistema software mondiale in poche ore.Perché le organizzazioni hanno bisogno di SBOM?La necessità di SBOM è determinata da diversi fattori, tra cui:Garantire una maggiore trasparenza del softwareGestione del software open source e delle dipendenze di terze partiIdentificazione e mitigazione delle vulnerabilità di sicurezzaCompliance ai requisiti legali e normativiDi fatto, senza una mappatura precisa delle dipendenze, nessun produttore può rispettare i tempi stretti imposti dal CRA per la notifica delle vulnerabilità attivamente sfruttate, precisamente:ScadenzaCosa deve essere pronto per l’invio24 oreAllerta precoce dopo aver preso conoscenza di una vulnerabilità attivamente sfruttata72 oreNotifica completa della vulnerabilità con indicatori tecnici14 giorniRelazione finale dopo la disponibilità di misure correttive o di mitigazione1 meseRelazione finale sull’incidente per gli incidenti graviRequisiti relativi allo SBOM ai sensi del CRAL’Allegato I, Parte II del CRA impone ai fabbricanti di identificare e documentare vulnerabilità e componenti del prodotto, anche attraverso uno SBOM in formato comunemente usato e leggibile da macchina, che includa almeno le dipendenze di primo livello. La formulazione “dipendenze di primo livello” lascia margini interpretativi: una lettura restrittiva limiterebbe l’obbligo alle sole dipendenze dirette, mentre una lettura orientata all’efficacia della protezione lo estenderebbe anche alle dipendenze transitive critiche. Gli standard armonizzati che CEN e CENELEC stanno elaborando, attesi entro la metà del 2026, dovrebbero chiarire questo punto.Un altro elemento spesso sottovalutato è il considerando 37 del regolamento: lo SBOM non deve essere resa pubblica, ma va messa a disposizione delle autorità di vigilanza del mercato su richiesta motivata.Di fatto, si tratta di garantire un bilanciamento tra trasparenza tecnica e tutela di informazioni commerciali sensibili dei fornitori. Il regolamento distingue, inoltre, tra prodotti “importanti” e “critici”: per i prodotti critici — sistemi operativi, hypervisor, infrastrutture a chiave pubblica, componenti di sicurezza di rete — è richiesta la valutazione di compliance da parte di un organismo terzo notificato, mentre per i prodotti importanti di Classe I è ammessa l’autovalutazione secondo gli standard armonizzati.SPDX 3.0 e CycloneDX: gli standard tecnici di riferimento dello SBOMDue formati, sul piano tecnico, si sono affermati come standard de facto per la generazione delle SBOM e, precisamente:SPDX, sviluppato sotto l’egida della Linux Foundation e gode dello status di standard internazionale tramite la certificazione ISO/IEC 5962:2021, un elemento che ne facilita l’adozione in contesti regolamentati, e supporta serializzazioni multiple (JSON-LD, RDF, XML) per integrarsi sia con sistemi legacy sia con pipeline DevOps moderne.CycloneDX, sviluppato da OWASP, nasce invece con una vocazione orientata alla sicurezza applicativa più che alla gestione delle licenze open source. CycloneDX supporta tipologie di inventario che vanno oltre il software puro: HBOM per l’hardware; MBOM per la manifattura; SaaSBOM per i servizi cloud; CBOM per gli algoritmi crittografici e sempre più rilevante in vista della transizione post-quantum. Inoltre, CycloneDX ha ottenuto il riconoscimento come standard internazionale ECMA-424.È doveroso evidenziare che SPDX tende a prevalere in contesti enterprise con forte esposizione alla compliance sulle licenze; mentre CycloneDX in ambienti cloud-native e nei workflow DevSecOps.La tendenza emergente, anche per le aziende industriali italiane, è generare SBOM in entrambi i formati per garantire interoperabilità con fornitori, clienti finali e autorità di vigilanza del mercato.Tracciabilità nella supply chain industriale e la responsabilità dei produttoriIl produttore resta responsabile della sicurezza del prodotto per l’intero ciclo di vita, anche quando integra componenti open source o sviluppati da terzi: la responsabilità non si trasferisce automaticamente a monte della filiera. Il periodo minimo di supporto previsto è di cinque anni, o la durata di utilizzo prevista se superiore, e impone l’adozione di processi continui di Software Composition Analysis integrati nelle pipeline di sviluppo, non controlli puntuali da eseguire una tantum.Per le aziende industriali che si affidano a fornitori di componenti hardware, firmware e librerie software, questo significa rivedere la contrattualistica di filiera: clausole di notifica delle vulnerabilità verso l’acquirente, diritti di audit sulla sicurezza dei componenti forniti, responsabilità contrattuale in caso di non compliance.Le sanzioni per la violazione degli obblighi essenziali possono arrivare fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, un livello comparabile a quello del GDPR.SBOM e CRA: una roadmap alla complianceDi seguito una roadmap per rendere lo SBOM compliant al CRA1. Effettuare una valutazione dello stato di preparazioneValutare:Pratiche attuali relative all’inventario del softwareGenerazione dell’SBOM esistenteMaturità del monitoraggio delle vulnerabilitàProcedure di conservazione dei documenti2. Definire la governance internaDefinire ruoli chiari per:SviluppatoriTeam DevOpsSquadre di sicurezzaAspetti legali e di complianceAppalti3. Automatizzare la generazione della SBOMGli strumenti dovrebbero:Generare SBOM per ogni versione e aggiornamentoIntegrazione con le pipeline CI/CDFormati di output CycloneDX e SPDXConvalida i campi obbligatori4. Integrare l’SBOM in tutto il ciclo di vita dello sviluppo del softwareLa maturità della SBOM si evolve attraverso diverse fasi:SBOM di progettazione (componenti previsti)Crea SBOM (artefatti compilati)SBOM analizzata (controllo post-compilazione)SBOM implementato (ambiente di produzione)SBOM in tempo reale (monitoraggio attivo)5. Garantire la compliance e il monitoraggio continuiSi tratta di:Monitorare costantemente i database delle vulnerabilitàAggiornare gli SBOM quando cambiano i componentiDefinire le procedure per la segnalazione delle vulnerabilitàPreparare la documentazione necessaria per le richieste alle autoritàDalla compliance alla resilienza della supply chainIl CRA trasforma la SBOM da strumento di visibilità interna a requisito normativo vincolante per l’accesso al mercato europeo. Per i produttori industriali italiani ed europei, la strada più efficace non è scegliere tra SPDX e CycloneDX, ma costruire processi capaci di generare e mantenere entrambi i formati, integrare la tracciabilità del software nei contratti di fornitura e arrivare alle scadenze 2026-2027 con una mappatura completa del proprio portafoglio prodotti.Concludendo, investire oggi in uno SBOM significa trasformare un obbligo di compliance in un vantaggio competitivo duraturo, in un mercato dove la sicurezza della supply chain diventa criterio di selezione sempre più decisivo.