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 normativo
Eventi 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 software
- Gestione del software open source e delle dipendenze di terze parti
- Identificazione e mitigazione delle vulnerabilità di sicurezza
- Compliance ai requisiti legali e normativi
Di 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:
| Scadenza | Cosa deve essere pronto per l’invio |
|---|---|
| 24 ore | Allerta precoce dopo aver preso conoscenza di una vulnerabilità attivamente sfruttata |
| 72 ore | Notifica completa della vulnerabilità con indicatori tecnici |
| 14 giorni | Relazione finale dopo la disponibilità di misure correttive o di mitigazione |
| 1 mese | Relazione finale sull’incidente per gli incidenti gravi |
Requisiti relativi allo SBOM ai sensi del CRA
L’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 SBOM
Due 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 produttori
Il 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 compliance
Di seguito una roadmap per rendere lo SBOM compliant al CRA
1. Effettuare una valutazione dello stato di preparazione
Valutare:
- Pratiche attuali relative all’inventario del software
- Generazione dell’SBOM esistente
- Maturità del monitoraggio delle vulnerabilità
- Procedure di conservazione dei documenti
2. Definire la governance interna
Definire ruoli chiari per:
- Sviluppatori
- Team DevOps
- Squadre di sicurezza
- Aspetti legali e di compliance
- Appalti
3. Automatizzare la generazione della SBOM
Gli strumenti dovrebbero:
- Generare SBOM per ogni versione e aggiornamento
- Integrazione con le pipeline CI/CD
- Formati di output CycloneDX e SPDX
- Convalida i campi obbligatori
4. Integrare l’SBOM in tutto il ciclo di vita dello sviluppo del software
La 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 continui
Si tratta di:
- Monitorare costantemente i database delle vulnerabilità
- Aggiornare gli SBOM quando cambiano i componenti
- Definire le procedure per la segnalazione delle vulnerabilità
- Preparare la documentazione necessaria per le richieste alle autorità
Dalla compliance alla resilienza della supply chain
Il 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.
Partecipa alla community