Il Suo cliente vuole una SBOM: guida per i fornitori di componenti e software

Questa guida è per i fornitori di una supply chain manifatturiera: ECU, display, controllori, gateway, azionamenti, stack Linux embedded e moduli firmware. Se vende software e un cliente Le ha inviato una richiesta occasionale, inizi da come rispondere a una richiesta di SBOM di un cliente, che tratta quel caso.

Perché gli OEM lo chiedono ora

La richiesta di SBOM di un OEM è di solito la normativa dell'OEM che arriva alla Sua porta attraverso un contratto. Quale normativa sia determina che cosa l'OEM deve avere, e quanta parte ne viene trasferita a Lei.

Il regolamento sulla ciberresilienza

Secondo il regolamento (UE) 2024/2847 sulla ciberresilienza (Cyber Resilience Act), un prodotto con elementi digitali comprende «i componenti software o hardware immesso sul mercato separatamente» (articolo 3, punto 1). Un componente che vende da solo nell'UE è un prodotto a pieno titolo, e Lei ne è il fabbricante, con un proprio obbligo di SBOM: l'allegato I, parte II, punto 1, chiede una distinta base del software «in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto». Se il componente è destinato all'integrazione in altri prodotti, le Sue istruzioni devono anche fornire «le informazioni necessarie affinché l'integratore soddisfi» i requisiti essenziali (allegato II, punto 8, lettera f)).

Anche l'OEM ha obblighi che arrivano a Lei. I fabbricanti «esercitano la dovuta diligenza quando integrano componenti provenienti da terzi» (articolo 13, paragrafo 5), e quando l'OEM rileva una vulnerabilità in un componente che ha integrato, deve segnalarla alla persona o all'entità che fabbrica o mantiene il componente (articolo 13, paragrafo 6). Gli orientamenti della Commissione sul CRA del luglio 2026 indicano che le evidenze di dovuta diligenza possono consistere in documentazione ottenuta dal fabbricante del componente, e non citano le SBOM; in pratica, una SBOM è spesso la documentazione che gli OEM chiedono. Gli obblighi di segnalazione si applicano dall'11 settembre 2026 e il regolamento si applica integralmente dall'11 dicembre 2027. Sono esclusi i pezzi di ricambio fabbricati secondo le stesse specifiche dei componenti che sostituiscono (articolo 2, paragrafo 6). Per il resto del regolamento, veda che cos'è il CRA e la guida al CRA.

Veicoli

Il CRA non si applica ai prodotti disciplinati dal regolamento (UE) 2019/2144, il regolamento sull'omologazione dei veicoli (articolo 2, paragrafo 2, lettera c)). I componenti per veicoli omologati arrivano sul mercato secondo le norme sui veicoli, e quelle norme non citano mai una SBOM.

• Il regolamento ONU n. 155 (cibersicurezza) impone al costruttore di raccogliere e verificare informazioni lungo la supply chain per dimostrare che i rischi legati ai fornitori sono individuati e gestiti (5.1.1(a)), di mostrare come il suo sistema di gestione della cibersicurezza gestirà le dipendenze che possono esistere con fornitori sotto contratto, fornitori di servizi o sotto-organizzazioni del costruttore (7.2.2.5) e di individuare e gestire, per il tipo di veicolo da omologare, i rischi legati ai fornitori (7.3.2).
• Il regolamento ONU n. 156 (aggiornamenti software) impone che tutte le versioni software iniziali e aggiornate siano identificabili in modo univoco (7.1.1.2) e, per ogni numero di identificazione software RX (RXSWIN), un registro verificabile che descriva tutto il software pertinente per l'RXSWIN (7.1.2.3).
• ISO/SAE 21434 organizza il lavoro di cibersicurezza tra OEM e fornitore come attività distribuite, con la ripartizione concordata in un cybersecurity interface agreement (accordo di interfaccia di cibersicurezza).
• L'SBOM Informational Report di Auto-ISAC (febbraio 2025) fornisce le indicazioni del settore stesso.

Nell'automotive la SBOM arriva come requisito contrattuale, non di legge.

Automazione industriale

IEC 62443-4-1 si applica ai fornitori di prodotti per sistemi di automazione e controllo industriale. Non cita le SBOM, ma la pratica 6, gestione dei problemi legati alla sicurezza (da DM-1 a DM-6), e la pratica 7, gestione degli aggiornamenti di sicurezza (da SUM-1 a SUM-5, compreso SUM-3, «Dependent component or operating system security update documentation»), sono i punti in cui una SBOM fa da evidenza.

Macchine

Il regolamento (UE) 2023/1230 relativo alle macchine si applica dal 20 gennaio 2027 e non cita le SBOM. I suoi requisiti essenziali di protezione dall'alterazione (allegato III, 1.1.9) chiedono che il software essenziale per la conformità sia individuato e protetto, che «la macchina o il prodotto correlato devono individuare il software installato sullo stesso, necessario per il suo funzionamento in condizioni di sicurezza», e che si raccolgano prove degli interventi su quel software. Le macchine con elementi digitali rientrano anche nel CRA, a differenza dei veicoli omologati: per questo i costruttori di macchine chiedono già oggi SBOM ai loro fornitori. Veda CRACI per i costruttori di macchine e IoT industriale.

NIS2 e clienti certificati

Se fornisce soggetti essenziali o importanti, per esempio nei semiconduttori, l'articolo 21, paragrafo 2, lettera d), della NIS2 impone al Suo cliente di occuparsi della sicurezza della supply chain. Non cita le SBOM. I clienti la trasformano in questionari, e i controlli 5.21 e 8.8 dell'Annex A di ISO/IEC 27001 sono quelli in cui una SBOM fa da evidenza. Veda le SBOM come evidenza per ISO 27001, SOC 2 e NIS2.

I regimi a confronto

Regime	Si applica a	Cita una SBOM?	Che cosa arriva al fornitore
Regolamento sulla ciberresilienza (CRA)	Prodotti con elementi digitali sul mercato UE, compresi i componenti venduti separatamente	Sì, allegato I, parte II (1)	Direttamente se immette Lei il componente sul mercato; tramite la dovuta diligenza dell'OEM (art. 13(5)) e le segnalazioni di vulnerabilità (art. 13(6))
UN R155 e R156	Costruttori di veicoli che chiedono l'omologazione	No	Gestione del rischio fornitori (R155 7.2.2.5, 7.3.2) e identificazione del software (R156), tramite contratti
ISO/SAE 21434	Ingegneria della cibersicurezza dei veicoli stradali, OEM e fornitori	Non nella sua descrizione pubblica	Attività distribuite e un accordo di interfaccia di cibersicurezza
IEC 62443-4-1	Fornitori di prodotti per sistemi di automazione e controllo industriale	No	Direttamente se è Lei il fornitore del prodotto; le SBOM fanno da evidenza per DM e SUM
Regolamento (UE) 2023/1230 relativo alle macchine	Macchine e prodotti correlati sul mercato UE	No	Identificazione e protezione del software (allegato III 1.1.9); il CRA si applica in parallelo
NIS2	Soggetti essenziali e importanti	No	Questionari sulla sicurezza della supply chain e clausole contrattuali (art. 21(2)(d), 21(3))

Qualunque sia la strada, il cliente ha bisogno della stessa cosa: una SBOM accurata per ogni versione software che Lei consegna.

Che cosa chiedono di solito gli OEM

I requisiti variano da un OEM all'altro, ma convergono sullo stesso elenco. Verifichi la Sua SBOM rispetto a questo elenco prima della prima consegna.

Requisito	Aspettativa tipica
Formato	CycloneDX o SPDX, JSON o XML, con una versione minima della specifica. BSI TR-03183-2 fissa CycloneDX 1.6 o successivo, oppure SPDX 3.0.1 o successivo.
Campi	Allineati ai CISA 2026 Minimum Elements o a BSI TR-03183-2: autore, timestamp e, per ogni componente, nome, versione, produttore e identificatori
Identificatori	Un package URL ovunque l'ecosistema ne abbia uno, un CPE dove non c'è, così i componenti possono essere confrontati con i database di vulnerabilità
Licenze	Identificatori di licenza SPDX. Lo specialista di licenze dell'OEM li legge per valutare il copyleft e gli altri rischi di licenza.
Hash	Un hash di ogni binario consegnato, così l'OEM può confermare che la SBOM descrive il file ricevuto. Il BSI chiede SHA-512.
Profondità	Dipendenze transitive, non solo il primo livello
Granularità	Una SBOM per versione software o codice articolo consegnato
Consegna e risposta	Un canale di consegna, e tempi di risposta per le domande sulle vulnerabilità

Molti OEM verificano questi punti automaticamente all'arrivo. Veda la checklist di qualità SBOM per sapere che cosa controllerà il Suo cliente, e con quali strumenti, e gli esempi di SBOM per vedere come appaiono i campi in un file.

La Sua SBOM quando c'è poco o niente open source

Una ECU o un controllore bare-metal con firmware proprietario generato da modelli ha una SBOM onesta che può essere breve: l'applicazione proprietaria, il Suo bootloader, le librerie o la calibrazione di un produttore di silicio, ed eventuale open source come una libreria crittografica. È una risposta valida. Le regole:

• Elenchi i componenti proprietari con i Suoi identificatori: nome, versione e Lei come produttore.
• Dichiari le incognite note, come una libreria di un produttore di cui non può vedere il contenuto.
• Non gonfi mai la SBOM per sembrare esaustivo, e non ometta mai una libreria open source perché è piccola.

Per display e gateway basati su Linux vale il contrario: centinaia o migliaia di componenti, tra cui il kernel, il bootloader e i pacchetti del sistema di base (veda dispositivi connessi). Una SBOM che elenca solo la Sua applicazione e poche librerie è la prima cosa che un team ricevente segnala. Se esegue le build con Yocto, veda perché gli scanner non vedono ciò che c'è nelle build Yocto.

Contratti: che cosa concordare prima della prima consegna

Clausola	Perché è importante
Prodotti e versioni software coperti	Così nessuno discute in seguito se una variante o una release di manutenzione richiedesse una SBOM
Formato e versione della specifica	La loro pipeline di accettazione può rifiutare tutto il resto
Campi e framework di riferimento	«BSI TR-03183-2 v2.1.0» o «CISA 2026 Minimum Elements» si può verificare; «una SBOM completa» no
Evento che fa scattare la consegna	Ogni release, ogni versione software spedita all'OEM e ogni correzione
Canale di consegna	Il portale fornitori dell'OEM, uno scambio di file sicuro o un'e-mail sotto NDA
Riservatezza	Un NDA o l'accordo di fornitura esistente, che indichi la SBOM come informazione riservata
Limiti d'uso	Solo gestione delle vulnerabilità e conformità, nessuna condivisione con terzi senza consenso
Notifica delle vulnerabilità, in entrambe le direzioni	L'OEM segnala le vulnerabilità che trova nel Suo componente (CRA art. 13(6)); Lei gli notifica le Sue
Aspettative su VEX	Quale formato, e in quanto tempo valuta una nuova CVE
Conservazione	Per quanto tempo conserva la SBOM di ogni versione, in linea con il periodo di assistenza del prodotto
Accuratezza e incognite note	Una clausola onesta su ciò che la SBOM può e non può coprire tutela entrambe le parti

L'SBOM Sharing Primer della CISA descrive il caso automotive allo stesso modo: le richieste di SBOM rientrerebbero nei normali accordi di scambio di informazioni (per esempio accordo di riservatezza, cybersecurity interface agreement, development interface agreement).

Condividere senza esporre la proprietà intellettuale

Una SBOM non è il Suo codice sorgente. Elenca nomi di componenti, versioni, produttori, licenze, hash e relazioni. Non contiene il Suo codice, i Suoi algoritmi, i Suoi dati di calibrazione né il Suo progetto.

• Il CRA non obbliga i fabbricanti a rendere pubblica la SBOM (considerando 77). La SBOM va a un'autorità di vigilanza del mercato su richiesta motivata (allegato VII, punto 8).
• Le indicazioni della CISA sulla condivisione descrivono i canali abituali per il software proprietario: e-mail sotto NDA, il portale fornitori del cliente o uno scambio sicuro di documenti, oppure un Suo portale ad accesso controllato, con contratti che regolano riservatezza e accesso.
• Opzioni pratiche: una SBOM completa per ogni OEM sotto contratto; identificatori per le parti proprietarie che non rivelino nomi di progetti interni; e un documento VEX separato, così può aggiornare lo stato di una vulnerabilità senza inviare di nuovo la SBOM.

Con quale frequenza, e che cosa succede dopo la consegna

• Una nuova SBOM per ogni versione software consegnata, con lo stesso identificatore che l'OEM flasha o registra. Per i veicoli, questo si collega all'identificazione del software di R156.
• Una SBOM corretta quando trova un errore in una già inviata.
• Una dichiarazione VEX o un advisory quando ha valutato una vulnerabilità.

La domanda successiva, «siete interessati dalla CVE-X?», arriva con la prossima grande vulnerabilità. Sia pronto a rispondere per ogni versione consegnata, cosa possibile solo se ha conservato la SBOM di ciascuna.

VEX: che cosa si aspetterà poi il Suo cliente

Un documento VEX indica se un prodotto è interessato da una vulnerabilità. I Minimum Requirements for VEX della CISA (aprile 2023) definiscono quattro stati: not_affected, affected, fixed e under_investigation. Una dichiarazione not_affected dovrebbe riportare una di cinque giustificazioni, oppure una dichiarazione d'impatto:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Una dichiarazione affected richiede una dichiarazione d'azione: che cosa deve fare il cliente. VEX esiste in tre formati: il profilo VEX di CSAF 2.0, CycloneDX VEX e OpenVEX. L'output SPDX 3.0 di Yocto include dati VEX per impostazione predefinita (la variabile SPDX_INCLUDE_VEX).

Esempio pratico. Un display basato su Linux include OpenSSL 3.0.8. La CVE-2023-0464 descrive un uso eccessivo di risorse durante la verifica di catene di certificati X.509 che includono vincoli di policy. L'elaborazione delle policy è disattivata per impostazione predefinita, e il software del display non la attiva mai. Il fornitore invia una dichiarazione OpenVEX a titolo illustrativo:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Produrre SBOM in modo ripetibile

Come esegue le build	Modo realistico di produrre la SBOM
Software compilato in CI	Generare la SBOM nella build che produce il software consegnato, e conservarla con la release
Linux embedded basato su Yocto	L'output SPDX di Yocto (create-spdx), verificato per ciò che omette, oppure una registrazione della build Yocto
Firmware bare-metal da strumenti basati su modelli	Una libreria o uno strumento di generazione, mai un editor di testo, mantenuto a ogni release e validato prima dell'invio
Binari di terze parti che integra	Chiedere la SBOM al Suo fornitore; l'analisi binaria come sostituto finché non arriva

Qualunque sia la strada, validi il file prima di inviarlo. La checklist di qualità SBOM elenca i validatori che il Suo cliente userà probabilmente, CycloneDX vs SPDX aiuta con il formato, e standardizzare la generazione delle SBOM spiega come renderla uniforme tra i team.

Il ruolo di CRACI

Per i fornitori che eseguono le build su GitHub Actions, CRACI sostituisce i runner ospitati da GitHub e registra una SBOM da ogni build, così ogni versione consegnata ne ha già una.

• La SBOM elenca ciò che la build ha effettivamente scaricato, comprese le dipendenze transitive, con un package URL per pacchetto e la licenza dichiarata di ogni componente.
• La SBOM di ogni job porta uno stato di completezza, così sa che cosa sta inviando prima di inviarlo.
• Le SBOM si esportano in CycloneDX o SPDX, e CRACI supporta VEX.
• Le SBOM monitorate vengono rivalutate man mano che vengono pubblicate nuove vulnerabilità, e la cronologia delle build mostra quali build contenevano una dipendenza vulnerabile, entro il Suo periodo di conservazione.
• Le build Yocto girano sui runner CRACI e sono documentate.
• È possibile aggiungere SBOM di terze parti, così i componenti acquistati vengono monitorati insieme alle Sue build.

Quando CRACI non è la risposta

• Non ha una CI, oppure esegue le build su GitLab, Jenkins o un build server. Oggi CRACI supporta solo GitHub Actions; altri sistemi di CI sono nella roadmap.
• Il Suo firmware è generato da strumenti basati su modelli, senza download di pacchetti. Lì un registratore di build aggiunge poco.
• Deve ospitare SBOM per molti OEM in un portale di condivisione, o firmare le SBOM. CRACI non offre né l'uno né l'altro.
• Le Sue build devono girare sulla Sua infrastruttura. I runner ospitati dal cliente sono nella roadmap.
• Il Suo cliente vuole una prova della gestione della sicurezza della Sua organizzazione, come un certificato ISO 27001 o le risposte a un questionario NIS2. Una SBOM è evidenza per una parte di questo, non una certificazione. Il certificato ISO 27001 di CRACI copre il servizio di CRACI, non il Suo.

SBOM per i fornitori: domande frequenti

Il mio cliente, un OEM, mi ha chiesto una SBOM. Sono obbligato a fornirla?

Spesso lo richiede il contratto più che la legge. Se immette Lei stesso sul mercato UE un componente con elementi digitali, il regolamento sulla ciberresilienza richiede una Sua SBOM. Altrimenti l'obbligo è dell'OEM, che Glielo trasferisce tramite la dovuta diligenza e l'accordo di fornitura.

Il CRA si applica ai componenti che vendo a un fabbricante?

Se immette il componente sul mercato UE separatamente, sì: l'articolo 3, punto 1, comprende i componenti software o hardware immessi sul mercato separatamente. Se arriva sul mercato solo all'interno del prodotto dell'OEM, il fabbricante è l'OEM, che deve esercitare la dovuta diligenza sul Suo componente (articolo 13, paragrafo 5). I componenti dei veicoli omologati sono esclusi dal CRA (articolo 2, paragrafo 2, lettera c)).

UN R155 o ISO/SAE 21434 richiedono una SBOM?

No. R155 non cita mai una SBOM; impone al costruttore del veicolo di gestire i rischi legati ai fornitori. ISO/SAE 21434 organizza il lavoro di cibersicurezza con i fornitori tramite accordi di interfaccia. Nell'automotive le SBOM arrivano come requisito contrattuale.

Quale formato e quali campi si aspetterà un OEM?

Di solito CycloneDX o SPDX in JSON o XML, allineato ai CISA 2026 Minimum Elements o a BSI TR-03183-2: autore e timestamp e, per ogni componente, nome, versione, produttore, package URL o CPE, licenza e hash, con le dipendenze transitive.

Ogni quanto devo inviare una SBOM aggiornata?

Per ogni versione software che consegna, ogni volta che corregge un errore, e con una dichiarazione VEX o un advisory quando ha valutato una vulnerabilità. Concordi nel contratto l'evento che fa scattare la consegna.

Condividere una SBOM espone la nostra proprietà intellettuale?

No. Una SBOM elenca nomi di componenti, versioni, produttori, licenze, hash e relazioni, non codice sorgente, algoritmi o dati di calibrazione. La condivida sotto NDA o nell'ambito dell'accordo di fornitura, con un uso limitato alla gestione delle vulnerabilità e alla conformità. Il CRA non richiede che sia pubblica.

Che cos'è VEX, e il mio cliente lo chiederà?

VEX indica se un prodotto è interessato da una vulnerabilità: not_affected, affected, fixed o under_investigation, con una giustificazione per not_affected. Si aspetti che Le venga chiesto dopo la prossima vulnerabilità molto discussa in un componente che consegna.

Il firmware della nostra ECU non contiene open source. Come è fatta la nostra SBOM?

Breve e onesta: l'applicazione proprietaria, il bootloader, eventuali librerie o calibrazioni di un produttore di silicio ed eventuale open source come una libreria crittografica, ciascuno con i Suoi identificatori, più le incognite note. Non la gonfi.