Tra undici mesi le aziende che vendono hardware o software con componenti digitali nell’Unione Europea dovranno dimostrare, entro 24 ore da una vulnerabilità sfruttata attivamente, di sapere esattamente cosa gira dentro i loro prodotti. L’11 settembre 2026 scattano i primi obblighi di segnalazione del Cyber Resilience Act, e chi non ha già un inventario del software leggibile da una macchina parte in salita. Quell’inventario si chiama SBOM, Software Bill of Materials, e oggi esistono due modi seri per scriverlo: CycloneDX e SPDX. Non sono intercambiabili, non hanno la stessa storia e non li usano le stesse persone. Questo confronto mette a terra numeri veri, non impressioni: chi adotta cosa in Europa, quanto costano gli strumenti che li generano, e quale formato ha senso scegliere a seconda del prodotto che costruisci.

Cos’è un SBOM e perché il Cyber Resilience Act lo rende urgente

Un SBOM è, in sostanza, la lista degli ingredienti di un pacchetto software: librerie, dipendenze dirette e transitive, versioni, licenze e, nelle versioni più recenti degli standard, anche informazioni crittografiche sui componenti. Fino a poco tempo fa era un esercizio da reparto compliance. Con il Cyber Resilience Act (Regolamento UE 2024/2847), entrato in vigore il 10 dicembre 2024, diventa un requisito Annex I per qualunque prodotto con elementi digitali immesso sul mercato europeo.

Il calendario ha due tappe, e vale la pena tenerle separate perché online si trovano spesso confuse. Dall’11 settembre 2026 scattano gli obblighi di segnalazione: chi produce hardware o software con componenti digitali deve notificare ad ENISA e ai CSIRT nazionali le vulnerabilità sfruttate attivamente entro 24 ore dalla scoperta. L’11 dicembre 2027 arriva invece l’applicazione piena del regolamento, compresi la marcatura CE-Cyber e l’obbligo formale di produrre e mantenere un SBOM in un formato leggibile da una macchina. Il punto pratico è semplice: non puoi rispettare la scadenza di segnalazione del 2026 senza già sapere cosa contengono i tuoi prodotti, quindi l’SBOM va costruito ora anche se l’obbligo esplicito arriva dopo.

Qui entra in gioco la scelta del formato. Il CRA non impone CycloneDX o SPDX per nome: chiede un formato “comunemente utilizzato e leggibile da una macchina”. Ma in pratica, secondo l’SBOM Adoption State of Play 2026 di ENISA, la scelta si è già ristretta a due candidati che insieme coprono quasi tre quarti del mercato reale.

Non è la prima volta che il settore prova a standardizzare l’inventario del software. Già nel 2009 lo standard ISO/IEC 19770-2 aveva introdotto i tag SWID per identificare pacchetti installati, pensati soprattutto per l’asset management aziendale più che per la sicurezza della supply chain. Quello che cambia oggi è il contesto: SWID descriveva cosa era installato su una macchina, mentre CycloneDX e SPDX descrivono cosa compone un pacchetto software prima ancora che venga distribuito, in modo da poter risalire in pochi minuti a ogni prodotto che contiene una libreria vulnerabile. È questa differenza di scopo, più che una semplice questione di sintassi, a spiegare perché il mercato si sia polarizzato proprio su questi due standard e non su alternative più vecchie.

CycloneDX: lo standard OWASP/Ecma in breve

CycloneDX nasce nel progetto OWASP con un obiettivo dichiarato: essere leggero, orientato alla sicurezza e facile da automatizzare in pipeline CI/CD. Oggi è uno standard internazionale ECMA-424, sviluppato congiuntamente da OWASP Foundation ed Ecma International. La versione corrente è la 1.7, pubblicata a fine 2025, e supporta nativamente tre formati di serializzazione: JSON, XML e Protocol Buffers, con tipi media registrati IANA (application/vnd.cyclonedx+json e application/vnd.cyclonedx+xml).

CycloneDX non si è fermato all’SBOM classico. Nel corso delle ultime versioni ha aggiunto profili specializzati: SaaSBOM per i servizi cloud, HBOM per l’hardware, ML-BOM per i modelli di machine learning, CBOM per gli asset crittografici e OBOM per le operazioni. È un approccio “full-stack bill of materials” che punta a coprire più superfici di rischio con un unico schema dati. Sul fronte roadmap, CycloneDX 2.0 è atteso in autunno 2026, con ratifica Ecma prevista per dicembre 2026, e promette di estendere il modello a minacce, controlli e provenienza dei materiali.

SPDX: lo standard Linux Foundation/ISO in breve

SPDX (Software Package Data Exchange) ha una storia più lunga: nasce come progetto della Linux Foundation orientato in origine alla gestione delle licenze open source, poi diventato uno standard ISO/IEC 5962:2021. È il formato con l’ecosistema di tooling più maturo e la base dati di licenze più estesa e mantenuta nel tempo (l’ultima release della SPDX License List porta il numero di versione a 3.26).

Sul fronte specifiche, a metà 2026 la versione di riferimento più stabile resta SPDX 3.0, mentre il 30 giugno 2026 è uscita la prima release candidate della versione 3.1, ancora aperta a revisione pubblica secondo la pagina news ufficiale del progetto. Il salto concettuale della famiglia SPDX 3.x è l’estensione del modello oltre il software puro, per includere sicurezza, hardware, servizi e filiera operativa: un disegno più ampio di CycloneDX 1.x, ma con un’adozione pratica ancora inferiore secondo i dati di settore.

CycloneDX vs SPDX: la tabella comparativa completa

Ecco il confronto tecnico riga per riga, utile per chi deve giustificare la scelta a un team di compliance o a un cliente in fase di audit.

CaratteristicaCycloneDXSPDX
Ente sviluppatoreOWASP Foundation + Ecma InternationalLinux Foundation
Standard formaleECMA-424ISO/IEC 5962:2021
Versione corrente (ago. 2026)1.7 (fine 2025)3.0 stabile, 3.1 release candidate
Prossima major2.0, attesa autunno 20263.1 finale, data non ancora fissata
Formati di serializzazioneJSON, XML, Protocol BuffersJSON, RDF, tag/value, spreadsheet
Focus originarioSicurezza applicativa e supply chainConformità licenze open source
Profili estesiSaaSBOM, HBOM, ML-BOM, CBOM, OBOMSicurezza, hardware, servizi, filiera (dalla 3.0)
Adozione ENISA 202644% delle organizzazioni29% delle organizzazioni
Adozione osservata su PyPI100% degli SBOM pubblicati0% degli SBOM pubblicati
Maturità ecosistema tool (studio arXiv)Alto coinvolgimento sviluppatoriEcosistema più maturo, più tool disponibili
Conformità ai criteri CRA (ENISA)Accettato (1.6+)Accettato (3.0.1+)
Community license listRiferimento a database esterniSPDX License List v3.26, mantenuta internamente

Un dettaglio che spesso sfugge: la Germania, tramite la linea guida tecnica BSI TR-03183-2 (versione 2.1.0, agosto 2025), è stato uno dei primi paesi UE a mettere nero su bianco quali versioni minime accettare. Ha indicato CycloneDX 1.6 o superiore oppure SPDX 3.0.1 o superiore come soglie valide per un SBOM “nuovo o aggiornato” ai fini del CRA. È un segnale utile anche per le aziende italiane, perché indica dove probabilmente si allineerà la prassi UE quando arriveranno linee guida più dettagliate a livello comunitario.

Cosa dice l’ACN in Italia

Va detto con chiarezza: al momento l’Agenzia per la Cybersicurezza Nazionale non ha pubblicato una guida dedicata al formato SBOM da adottare per il CRA. I riferimenti normativi italiani più vicini restano quelli generali sugli obblighi di cybersicurezza previsti dalla legge 90/2024, che riguardano la sicurezza della filiera in senso ampio ma non entrano nel merito tecnico di CycloneDX contro SPDX. Le aziende italiane, in assenza di un’indicazione nazionale specifica, stanno di fatto seguendo gli stessi segnali di mercato che arrivano da ENISA e dalla prassi tedesca.

Questo vuoto normativo nazionale non è necessariamente un problema per chi deve agire subito: significa che un’azienda italiana ha oggi piena libertà di allinearsi allo standard più diffuso a livello europeo, senza il rischio di dover poi disfare il lavoro per adeguarsi a una linea guida nazionale che arriva in ritardo rispetto al regolamento comunitario. Il rischio, semmai, è opposto: aspettare un’indicazione ACN che potrebbe non arrivare prima della scadenza di settembre 2026.

Chi usa cosa: i dati reali di adozione in Europa

Il sondaggio ENISA pubblicato il 9 giugno 2026 resta la fonte più solida disponibile: ha intervistato 334 organizzazioni, il 65% con sede nell’UE e l’80% direttamente soggetto al CRA. Il risultato: il 44% usa CycloneDX, il 29% SPDX, il 17% formati proprietari e l’11% non usa alcun formato standard. Sommando le due quote, CycloneDX e SPDX coprono insieme il 73% del panorama reale, lasciando un 28% di aziende ancora fuori standard e potenzialmente non pronte per l’11 settembre 2026.

Un secondo punto dati, più di nicchia ma illuminante, arriva da un’analisi indipendente sull’ecosistema PyPI condotta da sbomify a marzo 2026: su 15.021 pacchetti Python analizzati, solo 238 (l’1,58%) pubblicano un SBOM insieme al codice. Di quei 238, il 100% è in formato CycloneDX JSON. Zero pacchetti usano SPDX. È un campione piccolo e specifico (l’ecosistema Python open source, non le grandi aziende regolamentate), ma conferma la stessa direzione: dove gli sviluppatori scelgono da soli, senza un mandato aziendale, CycloneDX vince nettamente.

Attenzione però a non generalizzare troppo: altre stime di mercato, basate su proiezioni di ricavi del software di gestione SBOM piuttosto che su sondaggi di adozione diretta, indicano quote diverse (in alcuni casi SPDX viene descritto come leggermente avanti su segmenti di mercato specifici, grazie alla sua maggiore maturità nella gestione delle licenze). La differenza dipende dalla metodologia: un conto è chiedere “che formato usi oggi per generare SBOM di sicurezza”, un altro è stimare il fatturato di piattaforme che, in alcuni casi, gestiscono anche flussi di compliance licenze più legati alla tradizione SPDX. Per un’azienda che deve rispettare il CRA, il dato ENISA resta il più rilevante perché misura esattamente la popolazione interessata dal regolamento.

C’è poi un dettaglio del sondaggio ENISA che merita attenzione a parte: il 28% delle organizzazioni intervistate (il 17% con formati proprietari più l’11% senza alcuno standard) non userebbe oggi né CycloneDX né SPDX. Per un’entità direttamente soggetta al CRA, questo significa dover ripartire quasi da zero nei prossimi mesi, non semplicemente convertire un file esistente. È un rischio operativo concreto perché la conversione tra formati proprietari e standard aperti non è mai un’operazione a costo zero: richiede tempo di ingegneria, test e spesso la riscoperta di dipendenze che il sistema interno aveva tracciato in modo incompleto.

Benchmark e maturità: cosa dicono tre fonti indipendenti

Non esiste ancora un benchmark pubblico e verificabile che misuri velocità o accuratezza di generazione tra i vari tool SBOM su basi comparabili: chiunque trovi cifre precise online su “X genera SBOM 3 volte più veloce di Y” dovrebbe chiedersi su quale dataset sono state calcolate. Quello che invece esiste, ed è verificabile, sono tre angolazioni indipendenti sulla maturità dei due standard.

  • ENISA (sondaggio di adozione, giugno 2026): CycloneDX al 44%, SPDX al 29%, con il CRA come motore principale della crescita degli investimenti in strumenti SBOM.
  • sbomify / analisi PyPI (marzo 2026): nell’ecosistema open source dal basso, CycloneDX domina al 100% tra i pochi pacchetti che pubblicano SBOM, segno di una preferenza organica degli sviluppatori.
  • Studio accademico su arXiv, “The State of the SBOM Tool Ecosystems” (dicembre 2025): i progetti che usano tool CycloneDX mostrano un coinvolgimento sviluppatori più alto e indicatori di salute del progetto migliori, mentre i tool SPDX beneficiano di un ecosistema più maturo e di una disponibilità di strumenti più ampia e consolidata nel tempo.

La sintesi onesta è questa: CycloneDX sta vincendo sull’adozione corrente e sullo slancio, SPDX mantiene un vantaggio di maturità e profondità sul fronte licenze, perché è lo standard più vecchio e più esposto a casi d’uso legali reali. Non è un verdetto a somma zero: sono due strumenti costruiti con priorità diverse fin dall’inizio.

Per un team di sicurezza, l’assenza di un benchmark formale su velocità e accuratezza non è un problema da risolvere aspettando che qualcuno lo pubblichi. La strategia più sensata resta empirica: generare l’SBOM di un repository reale con due o tre strumenti diversi, confrontare manualmente il numero di componenti rilevati e verificare quante dipendenze transitive vengono effettivamente catturate. In pratica, gli scanner basati su analisi statica del filesystem (come Syft) tendono a essere più rapidi su progetti con dipendenze dichiarate in modo esplicito, mentre gli scanner integrati in strumenti di vulnerability management (come Trivy) aggiungono qualche secondo in più ma restituiscono direttamente il collegamento tra componente e CVE nota, utile per il passaggio successivo di segnalazione.

Gli strumenti di generazione SBOM a confronto

Sul lato pratico, la buona notizia è che i generatori open source più diffusi sono gratuiti e permettono di produrre entrambi i formati dalla stessa base di codice scansionata, riducendo il rischio di doversi legare a un solo standard. Questo è probabilmente il motivo per cui, nonostante la disparità di adozione tra i due standard, quasi nessun team tecnico descrive la scelta del formato come un vincolo tecnologico serio: il vero collo di bottiglia è organizzativo, cioè decidere chi nel team è responsabile di mantenere aggiornata la pipeline che genera l’SBOM ad ogni release.

StrumentoSviluppatoreLicenzaFormati generati
SyftAnchoreApache-2.0, open sourceCycloneDX e SPDX
TrivyAqua SecurityApache-2.0, open sourceCycloneDX e SPDX
cdxgenComunità CycloneDXOpen sourceFocalizzato su CycloneDX
sbom-toolMicrosoftOpen sourceOrientato a SPDX
TernComunità open sourceOpen sourceStoricamente associato a SPDX

In pratica, generare entrambi i formati dalla stessa base di codice con uno strumento come Syft richiede due comandi quasi identici:

syft dir:. -o cyclonedx-json=sbom-cyclonedx.json
syft dir:. -o spdx-json=sbom-spdx.json

Questo doppio output è la strategia più pragmatica per chi non vuole scommettere tutto su un solo standard mentre il mercato si assesta: costa pochi secondi di CI in più e tiene aperte entrambe le strade, utile soprattutto se lavori con clienti o filiere che impongono formati diversi.

Convertire un SBOM esistente da un formato all’altro

Se hai già un archivio di SBOM in un formato e ti serve l’altro, non è obbligatorio rigenerare tutto da capo. Esistono utility di conversione mantenute dalla stessa comunità SPDX, come cdx2spdx, un progetto open source pensato specificamente per trasformare documenti CycloneDX in SPDX. La conversione non è mai perfetta al 100%, perché i due schemi non hanno una corrispondenza uno a uno per ogni campo (i profili estesi di CycloneDX come HBOM o ML-BOM, ad esempio, non hanno un equivalente diretto in SPDX), ma per l’uso più comune, l’elenco di componenti con relative licenze, la conversione automatica copre la stragrande maggioranza dei casi.

Quanto costano le piattaforme SBOM commerciali

Gli strumenti da riga di comando sono gratuiti, ma la gestione SBOM su scala aziendale, con dashboard, tracciamento delle vulnerabilità collegate e reportistica per gli audit, passa spesso per piattaforme commerciali. Ecco i prezzi pubblicamente dichiarati ad agosto 2026.

PiattaformaPrezzo pubblicoModelloNote
FOSSA$20 / progetto al mese (fatturazione annuale)Per progettoLivello gratuito fino a 5 progetti, enterprise su preventivo
Snyk$0 gratuito, $25 / sviluppatore al mese (Team)Per sviluppatore contribuenteEnterprise su preventivo
JFrog XrayDa $150 / mese (Pro) a $950 / mese (Enterprise X)Bundle nella JFrog PlatformNessuna SKU Xray autonoma, nessun livello gratuito
Anchore Enterprise$34.500 / anno (Cloud Image), $50.000 / anno (Helm)Licenza annuale, listino AWS MarketplacePrezzo di listino marketplace, contratti diretti su preventivo
Sonatype PlatformDa $1.620 / anno + consumoBase più consumoModuli aggiuntivi (Firewall, air-gap) a listino separato
ChainguardGratuito fino a 5 immagini, da $19.000 / anno per team di 10Per immagine o per catalogoPiù orientato a container hardenizzati che a SBOM puro
Syft / Trivy / cdxgen / sbom-tool / TernGratuitiOpen sourceNessun costo di licenza, richiedono integrazione interna

Il divario di prezzo tra “genera un SBOM” e “gestiscine migliaia con tracciamento vulnerabilità” è enorme: si passa da zero euro con Syft in locale a decine di migliaia di euro l’anno con una piattaforma enterprise come Anchore. Per una PMI italiana che deve solo dimostrare conformità di base, il combo Syft più un repository Git per versionare gli output è spesso sufficiente. Per un fornitore critico secondo NIS2, con centinaia di prodotti e obblighi di tracciamento continuo delle vulnerabilità, il costo di una piattaforma dedicata si giustifica rapidamente.

Un altro fattore da considerare nel calcolo è il numero di prodotti da coprire, non solo il numero di sviluppatori. Le piattaforme come Anchore Enterprise e FOSSA fatturano spesso in base al numero di progetti o immagini scansionate al mese, non per sviluppatore: un’azienda con pochi sviluppatori ma decine di microservizi containerizzati può finire per pagare più di un team più grande con un’unica applicazione monolitica. Vale la pena simulare il costo reale sul proprio catalogo prodotti prima di firmare un contratto annuale, soprattutto guardando ai livelli “SBOM al mese” che piattaforme come Anchore pubblicano direttamente in pagina prezzi.

Le scadenze del Cyber Resilience Act che contano davvero

Vale la pena ripetere il calendario perché è la parte che genera più confusione online.

  • 10 dicembre 2024: il Cyber Resilience Act entra ufficialmente in vigore.
  • 11 settembre 2026: scattano gli obblighi di segnalazione delle vulnerabilità sfruttate attivamente, entro 24 ore, ad ENISA e ai CSIRT nazionali.
  • 11 dicembre 2027: applicazione piena del regolamento, inclusi marcatura CE-Cyber, secure-by-design e l’obbligo formale di SBOM in formato machine-readable per i prodotti “importanti” e “critici”.

La lettura pratica condivisa da diversi analisti di settore è che l’obbligo “formale” di SBOM scatti solo nel 2027, ma che sia impossibile rispettare la scadenza di segnalazione del 2026 senza già avere un inventario affidabile dei componenti software. In altre parole: chi aspetta il 2027 per iniziare arriva comunque in ritardo alla prima scadenza reale, quella del prossimo settembre.

C’è anche una terza data intermedia da tenere d’occhio: nel quarto trimestre del 2026 è atteso un atto delegato della Commissione europea che specificherà la presunzione di conformità per lo schema di certificazione europeo sui Criteri Comuni (EUCC) rispetto al CRA. Non è direttamente legato al formato SBOM, ma segnala che il quadro normativo continuerà a essere aggiornato con atti tecnici anche dopo l’entrata in vigore delle prime scadenze, quindi conviene trattare la conformità come un processo continuo e non come un progetto con una sola data di consegna.

5 scenari reali: quale formato scegliere

La scelta giusta dipende dal tipo di prodotto, dal settore e da chi ti chiede l’SBOM. Ecco cinque situazioni concrete che coprono la maggior parte dei casi che un team tecnico italiano incontra oggi. In tutti e cinque i casi vale la stessa premessa: nessuna scelta è definitiva, perché sia il regolamento sia gli standard sono destinati ad aggiornarsi ancora prima della piena applicazione del CRA nel dicembre 2027.

1. Startup SaaS B2B che vende in UE

Se il tuo prodotto è un servizio cloud senza distribuzione fisica di software, CycloneDX è la scelta più naturale grazie al profilo SaaSBOM dedicato, pensato proprio per descrivere servizi invece di soli pacchetti installabili. È anche il formato più diffuso tra i tool CI/CD più leggeri, quindi l’integrazione richiede meno lavoro custom. Per una startup con team piccolo, il vantaggio pratico è che un singolo ingegnere può integrare Syft nella pipeline in un pomeriggio, senza dover coinvolgere un ufficio legale per interpretare requisiti di licenza che, in un contesto SaaS puro, quasi mai si applicano allo stesso modo di un software distribuito on-premise.

2. Produttore di dispositivi IoT o embedded

Qui il profilo HBOM di CycloneDX, pensato per descrivere componenti hardware oltre al software, offre un vantaggio concreto: puoi documentare firmware, librerie e chip in un unico schema dati, utile quando il CRA chiede tracciabilità end-to-end su un prodotto fisico con elementi digitali. Per questi produttori, la posta in gioco è più alta che per un’azienda puramente software: un dispositivo IoT difettoso resta in campo per anni dopo la vendita, quindi l’SBOM non è un documento da produrre una tantum ma un artefatto da aggiornare a ogni patch firmware, per tutto il ciclo di vita dichiarato del prodotto.

3. Banca o fintech soggetta a PSD3

Con l’accordo politico su PSD3/PSR raggiunto a novembre 2025 e l’adozione formale attesa nel primo semestre 2026, il settore finanziario sta già affrontando obblighi di sicurezza delle API paralleli al CRA. In questo contesto, la maturità di SPDX sulla gestione delle licenze diventa utile per gli audit legali, spesso richiesti insieme a quelli di sicurezza. Molte banche finiscono per generare entrambi i formati: SPDX per compliance legale, CycloneDX per sicurezza operativa. Il doppio binario ha senso soprattutto quando l’ufficio legale e il team di sicurezza applicativa lavorano con processi di audit separati: duplicare l’output evita che uno dei due reparti debba dipendere dai tempi dell’altro per chiudere la propria checklist di conformità.

4. Fornitore critico secondo NIS2

Le entità essenziali e importanti secondo il decreto legislativo 138/2024, che recepisce NIS2 in Italia, devono già dimostrare misure di autenticazione multifattore e continua. In questi contesti a maggiore criticità, la scelta prudente è seguire l’indicazione tedesca BSI TR-03183-2 e accettare entrambi gli standard nelle versioni minime indicate (CycloneDX 1.6+ o SPDX 3.0.1+), lasciando ai fornitori la scelta del formato ma imponendo la soglia di versione. Questo approccio riduce l’attrito con i fornitori esteri, che potrebbero già aver standardizzato su un formato diverso da quello preferito internamente, senza abbassare la soglia di sicurezza richiesta dal recepimento italiano della direttiva.

5. PMI italiana fornitrice di una filiera più grande

Se sei un fornitore di secondo o terzo livello per un cliente più grande, la scelta pratica non è tua: è quella imposta dal capofiliera. In assenza di un’imposizione esplicita, generare entrambi i formati con Syft (due comandi, pochi secondi in più di CI) evita di dover rifare il lavoro quando cambia cliente o quando arriva la prima richiesta formale di conformità CRA. È lo scenario più comune per l’industria manifatturiera italiana, dove capofiliera tedeschi o francesi spesso arrivano con requisiti tecnici già definiti prima ancora che il fornitore italiano abbia formalizzato una propria policy interna.

Guida alla migrazione: come arrivare pronti al CRA

Che tu parta da zero o da un formato proprietario, il percorso verso la conformità segue più o meno gli stessi passaggi. Non serve un progetto trimestrale con un team dedicato: per la maggior parte delle organizzazioni si tratta di integrare uno strumento già esistente nella pipeline di build e di disciplinare un processo che probabilmente esiste già in forma informale, sotto forma di elenco delle dipendenze mantenuto a mano in un file di progetto.

  1. Fai un inventario delle build attive. Elenca ogni prodotto o servizio con componenti digitali che vendi o distribuisci nell’UE: è la lista a cui si applica il CRA.
  2. Scegli il formato di partenza in base al tipo di prodotto. Software puro o SaaS: parti da CycloneDX. Prodotto con forte componente licenze o legale: valuta SPDX o entrambi.
  3. Integra un generatore open source nella pipeline CI/CD. Syft o Trivy, entrambi Apache-2.0 e già capaci di produrre CycloneDX e SPDX dallo stesso comando di scansione.
  4. Versiona gli SBOM insieme al codice. Ogni release deve avere il proprio SBOM allegato, non un documento aggiornato manualmente una volta l’anno.
  5. Automatizza la segnalazione delle vulnerabilità. Collega l’SBOM a uno scanner (lo stesso Trivy, o Grype) per identificare in automatico i componenti con CVE note: è il prerequisito diretto per rispettare le 24 ore richieste dal CRA dall’11 settembre 2026.
  6. Verifica le versioni minime richieste. Segui come riferimento prudente CycloneDX 1.6+ o SPDX 3.0.1+, le stesse soglie indicate dalla guida tecnica tedesca BSI TR-03183-2.
  7. Valuta una piattaforma di gestione solo se il volume lo giustifica. Sotto le poche decine di prodotti, un repository Git e uno script CI bastano. Sopra quella soglia, il costo di una piattaforma dedicata (vedi la tabella prezzi sopra) si ripaga in tempo risparmiato sugli audit.
  8. Documenta il processo, non solo l’output. In un audit CRA conta anche dimostrare che l’SBOM viene generato automaticamente ad ogni release, non solo che esiste un file.

Vantaggi e svantaggi di CycloneDX

Vantaggi:

  • Adozione nettamente più alta secondo ENISA (44% contro 29%) e dominante nell’ecosistema open source dal basso.
  • Profili specializzati (SaaSBOM, HBOM, ML-BOM, CBOM) che coprono scenari moderni oltre al software puro.
  • Standard formale ECMA-424, sviluppo attivo con CycloneDX 2.0 già in roadmap per fine 2026.
  • Supporto nativo a tre formati di serializzazione, incluso Protocol Buffers per pipeline ad alte prestazioni.

Svantaggi:

  • Ecosistema di gestione licenze meno maturo rispetto a SPDX, che ha decenni di lavoro specifico su questo fronte.
  • Essendo più giovane e in evoluzione rapida (1.7 a fine 2025, 2.0 già in arrivo), richiede aggiornamenti di tooling più frequenti.

Vantaggi e svantaggi di SPDX

Vantaggi:

  • Standard ISO/IEC 5962:2021, riconosciuto formalmente a livello internazionale da più tempo di CycloneDX.
  • Ecosistema di tool più maturo secondo lo studio arXiv citato sopra, con maggiore disponibilità di strumenti consolidati.
  • Gestione delle licenze open source più profonda, grazie alla SPDX License List mantenuta e aggiornata (versione 3.26).
  • SPDX 3.x estende il modello a hardware, servizi e sicurezza, avvicinandosi all’ambizione “full-stack” di CycloneDX.

Svantaggi:

  • Adozione reale nettamente più bassa secondo ENISA (29% contro 44%) e assente nel campione PyPI analizzato da sbomify.
  • La versione 3.1 è ancora in release candidate a metà 2026, quindi non stabile per un’adozione enterprise immediata.
  • Meno diffuso tra gli strumenti CI/CD leggeri pensati per sviluppatori singoli o piccoli team.

Il verdetto: quale formato scegliere nel 2026

Se devi scegliere un solo formato oggi, per la maggior parte delle aziende italiane la risposta è CycloneDX: adozione doppia rispetto a SPDX secondo ENISA (44% contro 29%), standard formale ECMA-424 già consolidato, profili specializzati che coprono SaaS, hardware e machine learning, e un supporto praticamente universale negli scanner open source più usati. È anche il formato che il mercato sta scegliendo organicamente, come mostra il 100% di adozione CycloneDX nel campione PyPI di sbomify.

Ma “solo un formato” è spesso la domanda sbagliata. Con Syft o Trivy, generare entrambi i formati dalla stessa scansione costa pochi secondi di CI in più e azzera il rischio di dover rifare il lavoro quando un cliente, una banca o un capofiliera chiede specificamente SPDX per motivi legali o di gestione licenze. La raccomandazione pratica: CycloneDX come formato primario per sicurezza e conformità CRA, SPDX generato in parallelo quando la filiera lo richiede per compliance sulle licenze. Il costo di generare entrambi è quasi zero, mentre il costo di scegliere male e dover rifare tutto a ridosso dell’11 settembre 2026 non lo è affatto.

Un ultimo avvertimento pratico: qualunque formato tu scelga, il rischio più grande non è tecnico ma organizzativo. Un SBOM generato una volta e poi dimenticato vale poco più di zero in un audit, perché non riflette le dipendenze aggiunte nelle release successive. La differenza tra un’azienda pronta per il CRA e una che rincorre la scadenza sta più nel processo automatizzato di generazione ad ogni build che nella scelta specifica tra CycloneDX e SPDX.

Vale la pena ricordare, in chiusura, che nessuna delle due comunità è ferma: CycloneDX 2.0 arriverà entro la fine del 2026 con un’estensione ancora più ampia oltre il puro bill of materials, mentre SPDX 3.1 uscirà dalla fase di release candidate probabilmente nei mesi successivi. Qualunque scelta tu faccia oggi andrà rivista tra dodici o diciotto mesi, non perché sbagliata, ma perché lo standard su cui si basa continuerà a evolvere insieme al regolamento che lo rende necessario.

Domande frequenti

Il Cyber Resilience Act impone per legge CycloneDX o SPDX?
No. Il regolamento chiede un formato “comunemente utilizzato e leggibile da una macchina”, senza nominare uno standard specifico. In pratica il mercato si è concentrato su questi due, che insieme coprono il 73% delle organizzazioni secondo ENISA.

Da quando devo avere un SBOM pronto?
L’obbligo formale scatta l’11 dicembre 2027, ma gli obblighi di segnalazione delle vulnerabilità entro 24 ore partono già l’11 settembre 2026, e sono impossibili da rispettare senza un inventario software affidabile. Conviene essere pronti entro il 2026.

Posso generare sia CycloneDX che SPDX dallo stesso codice?
Sì. Strumenti open source come Syft e Trivy generano entrambi i formati dalla stessa scansione, con un comando quasi identico per ciascun formato.

Quanto costa iniziare a generare SBOM?
Zero, se usi strumenti open source come Syft o Trivy (entrambi Apache-2.0) integrati in una pipeline CI esistente. I costi arrivano solo se scegli una piattaforma di gestione dedicata, che va da circa $1.620 l’anno più consumo (Sonatype) a decine di migliaia di euro l’anno per soluzioni enterprise come Anchore.

L’ACN italiana ha pubblicato linee guida sul formato SBOM?
No, non risulta al momento una guida ACN dedicata specificamente al formato SBOM per il CRA. Le aziende italiane seguono i segnali di mercato europei, in particolare i dati ENISA e la prassi tecnica tedesca BSI TR-03183-2.

Qual è la differenza pratica più importante tra i due formati?
CycloneDX è nato per la sicurezza applicativa e la supply chain, con profili dedicati a SaaS, hardware e machine learning. SPDX è nato per la gestione delle licenze open source e mantiene un vantaggio in quell’area, con una base dati di licenze più profonda e matura.

Le grandi piattaforme cloud impongono un formato specifico?
Le informazioni raccolte per questo articolo non permettono di confermare una preferenza formale e univoca da parte di npm, GitHub o enti governativi USA come NTIA o CISA: entrambi gli standard risultano ampiamente accettati a seconda del contesto. Evita di fidarti di fonti che affermano il contrario senza citare una policy ufficiale.

Cosa succede se non ho nessun SBOM pronto all’11 settembre 2026?
Rischi di non riuscire a rispettare l’obbligo di segnalazione delle vulnerabilità sfruttate entro 24 ore, perché senza inventario dei componenti non puoi identificare rapidamente cosa è impattato. Non generare un SBOM oggi significa correre per recuperare sotto la pressione di una scadenza normativa già iniziata.

Conviene generare l’SBOM manualmente o automatizzarlo in CI/CD?
Automatizzarlo. Un elenco compilato a mano diventa obsoleto alla prima dipendenza aggiunta dopo la sua creazione, e in un audit CRA la data di generazione conta quanto il contenuto. Integrare Syft o Trivy come step della pipeline garantisce che ogni release abbia il proprio SBOM allineato al codice effettivamente rilasciato.

SPDX o CycloneDX sono retrocompatibili con le versioni precedenti?
In generale sì per le versioni minori, ma i salti tra major version possono introdurre campi nuovi o ristrutturati. CycloneDX 2.0, atteso entro la fine del 2026, e SPDX 3.1, ancora in release candidate, andranno valutati con attenzione prima di un aggiornamento automatico della pipeline, verificando che gli strumenti di generazione e gli eventuali consumatori a valle dell’SBOM supportino già la nuova versione.

Copertura correlata