La maggior parte dei fabbricanti scopre le lacune negli SBOM durante il primo controllo di conformità, non prima. A quel punto la scadenza di applicazione è più vicina e l'ambito della remediation è più ampio. L'obbligo SBOM dell'Allegato I è semplice da enunciare: formato leggibile da un dispositivo automatico, almeno le dipendenze di primo livello del prodotto, conservato nel fascicolo tecnico dell'Allegato VII. Ciò che mette in difficoltà i fabbricanti è la locuzione «che includa almeno». Questo articolo illustra sei errori che creano il divario più ampio tra uno SBOM formalmente prodotto e uno che supererebbe un'ispezione da parte delle autorità di vigilanza del mercato.
Riepilogo
- Fermarsi alle dipendenze dirette lascia le vulnerabilità transitive fuori dallo SBOM
- Uno SBOM creato una sola volta diventa obsoleto nel giro di settimane con la pubblicazione di nuovi CVE
- L'assenza di valori hash e identificatori PURL fa fallire i controlli di qualità BSI TR-03183
- La creazione manuale degli SBOM non soddisfa l'obbligo continuativo di aggiornamento del CRA
- I componenti interni e proprietari devono figurare accanto alle librerie open source
- Gli SBOM dei fornitori sono materia prima, non un artefatto di conformità già pronto
Errori in sintesi
| # | Errore | Perché non è sufficiente | Soluzione |
|---|---|---|---|
| 1 | Fermarsi alle dipendenze dirette | I CVE transitivi sono invisibili agli scanner | Lock file e scansione degli artefatti di build |
| 2 | Trattare lo SBOM come documento una tantum | Diventa obsoleto in poche settimane con i nuovi CVE | Generazione CI/CD per ogni build |
| 3 | Campi di identità mancanti | Nessuna corrispondenza CVE, TR-03183 fallisce | Versione esatta, SHA-256, PURL, fornitore |
| 4 | Generazione manuale | Non riesce a stare al passo con i rilasci | Automazione con Syft, Trivy o cdxgen |
| 5 | Omissione di componenti interni o proprietari | L'Allegato I non opera tale distinzione | ID interni, organizzazione come fornitore, SHA-256 |
| 6 | Trattare gli SBOM dei fornitori come artefatto finale | Il fabbricante è titolare dell'obbligo dell'Allegato I | Consolidare in un unico SBOM di prodotto |
Errore 1: fermarsi alle dipendenze dirette
L'Allegato I, Parte II, punto 1 fissa il minimo normativo alle dipendenze di primo livello. Molti fabbricanti si fermano esattamente lì. Il problema non è il mancato rispetto del minimo normativo. Il problema è il rischio che il minimo lascia fuori dalla propria visibilità. Una dipendenza transitiva (una libreria da cui dipende la propria dipendenza diretta) è altrettanto sfruttabile di una diretta. Quando viene pubblicato un CVE contro un pacchetto transitivo non incluso nello SBOM, non è possibile individuarlo, non è possibile segnalarlo e si è esposti senza saperlo.
Il prodotto
+-- Libreria A (diretta) ← minimo normativo, soglia Allegato I
| +-- Libreria B (transitiva) ← fuori dallo SBOM, invisibile agli scanner
| \-- Libreria C (transitiva) ← fuori dallo SBOM, invisibile agli scanner
\-- Libreria D (diretta) ← minimo normativo, soglia Allegato I
La soluzione consiste negli strumenti e nella configurazione. Si utilizzino i lock file e si scansionino gli artefatti di build piuttosto che solo il codice sorgente. Trivy, Syft e cdxgen supportano tutti la cattura delle dipendenze transitive se configurati correttamente. BSI TR-03183 considera la copertura transitive completa come l'indicatore di qualità che separa uno SBOM minimalmente conforme da uno genuinamente utile. Si consulti i livelli di qualità BSI TR-03183 per i requisiti di campo a ogni livello.
Errore 2: trattare lo SBOM come documento una tantum
Uno SBOM generato una sola volta e mai aggiornato crea una falsa sensazione di sicurezza. Nuovi CVE vengono pubblicati ogni giorno contro componenti già presenti nel prodotto. Uno SBOM accurato al momento della build diventa obsoleto nel giro di settimane. L'obbligo dell'Allegato I del CRA è continuativo: lo SBOM deve riflettere lo stato attuale del prodotto per tutta la durata del periodo di assistenza.
Trigger di aggiornamento obbligatori ai sensi del CRA:
| Trigger | Cosa cambia | Aggiornamento SBOM richiesto? |
|---|---|---|
| Nuova versione firmware o software | Nuovo artefatto di build | Sì, rigenerazione completa |
| Rilascio di patch di sicurezza | Versione del componente aggiornata | Sì, componenti interessati |
| Vulnerabilità scoperta e risolta | Stato VEX o di sfruttabilità | Sì, campi VEX |
| Componente aggiunto, rimosso o sostituito | Grafico delle dipendenze | Sì, rigenerazione completa |
| Modifica progettuale con impatto sulla sicurezza | Componenti e architettura | Sì, rigenerazione completa |
La soluzione è l'integrazione CI/CD. Ogni build dovrebbe produrre un artefatto SBOM aggiornato, conservato insieme al rilascio. Un'esportazione manuale non riesce a stare al passo con la frequenza di aggiornamento richiesta dal CRA. Si consulti i requisiti SBOM del CRA per l'elenco completo dei trigger e il computo decennale della conservazione.
Dall'11 settembre 2026, è obbligatorio segnalare le vulnerabilità attivamente sfruttate a ENISA entro 24 ore. Uno SBOM obsoleto impedisce di verificare se il prodotto sia interessato prima che l'orologio parta. I dati aggiornati sui componenti servono prima dell'incidente, non dopo.
Errore 3: campi di identità mancanti
Uno SBOM privo di campi accurati di versione, hash e identificatore è quasi inutile per la corrispondenza delle vulnerabilità. Questi campi collegano la voce di un componente a un record CVE nel National Vulnerability Database (NVD), OSV o CISA KEV. Senza di essi gli scanner di vulnerabilità non riescono a verificare i componenti, e i controlli di qualità BSI TR-03183 falliscono.
Ogni componente deve includere:
| Campo | Perché è rilevante | Fonte |
|---|---|---|
| Numero di versione esatto | Necessario per la corrispondenza CVE/NVD/OSV (non «latest» o intervalli) | Allegato I; TR-03183 obbligatorio |
| Hash SHA-256 | Verifica dell'integrità per i componenti binari | TR-03183 obbligatorio |
| Identificatore PURL | Collega il componente al suo record nel registro | TR-03183 obbligatorio |
| Nome del fornitore | Richiesto a ogni livello di qualità | Allegato I; TR-03183 |
Un errore di versione frequente riguarda l'uso di CycloneDX 1.3 o versioni precedenti. Il supporto VEX di base è stato aggiunto in CycloneDX 1.4 (gennaio 2022), mentre la struttura evidence più ricca per i componenti (identity, occurrences), utilizzata per dimostrare la tracciabilità CRA, è arrivata nella versione 1.5 (giugno 2023). Si miri a CycloneDX 1.6 o versioni successive per la conformità al CRA. Si verifichi la versione di output dello strumento prima di assumere la conformità.
Errore 4: generare gli SBOM manualmente
La creazione manuale degli SBOM è soggetta a errori e non è scalabile tra le versioni del prodotto. Uno SBOM fatto a mano omette componenti che gli strumenti automatici troverebbero, contiene errori di battitura nelle stringhe di versione e non può essere rigenerato in modo affidabile quando un componente cambia. Più criticamente, un processo manuale non può soddisfare l'obbligo continuativo di aggiornamento del CRA: ogni rilascio, ogni patch e ogni modifica di componente richiede uno SBOM aggiornato.
Si automatizzi la generazione con Syft, Trivy o cdxgen. Le voci manuali andrebbero riservate ai componenti che gli strumenti automatici non riescono a rilevare, come le librerie commerciali prive di voci nel database dei pacchetti o i blob di firmware proprietario. Tutto il resto dovrebbe provenire dalla build. Le autorità di vigilanza del mercato possono richiedere lo SBOM in qualsiasi momento; deve riflettere lo stato attuale del prodotto.
Errore 5: ignorare i componenti interni e proprietari
Un'abbreviazione comune consiste nel documentare solo le dipendenze open source e omettere le librerie interne, i moduli proprietari o i blob di firmware. L'Allegato I non opera tale distinzione. Se un componente è presente nel prodotto, appartiene allo SBOM.
I componenti interni spesso non hanno PURL né voce nel registro. L'approccio corretto consiste nell'assegnare un identificatore interno, indicare la propria organizzazione come fornitore e includere l'hash SHA-256 dell'artefatto binario. BSI TR-03183 copre esplicitamente i componenti proprietari a tutti i livelli di qualità.
Per i prodotti con firmware integrato proveniente da un ODM o da un fornitore di chip, non è possibile controllare ciò che non si ha sviluppato. La soluzione è contrattuale: si richieda la consegna dello SBOM ai propri fornitori di firmware. Ai sensi del CRA, il fabbricante è responsabile dell'intero prodotto, indipendentemente da chi ha scritto il codice. Per i prodotti hardware-software, si consulti l'HBOM ai sensi del CRA per stabilire quando è necessaria una Hardware Bill of Materials in aggiunta allo SBOM.
Errore 6: affidarsi agli SBOM dei fornitori come artefatto finale
Gli SBOM dei fornitori sono un input valido, e il CRA si aspetta che i fabbricanti si avvalgano della documentazione upstream. Non sostituiscono tuttavia uno SBOM integrato di prodotto. L'obbligo dell'Allegato I grava sul fabbricante del prodotto immesso sul mercato UE: è necessario consolidare gli SBOM dei fornitori con i propri componenti di prima parte, le dipendenze di build e il codice di glue in un unico SBOM per il prodotto integrato.
Se uno SBOM del fornitore è privo dei campi richiesti da BSI TR-03183 (PURL, hash, licenza), il fabbricante è responsabile di colmare tali lacune prima che il prodotto sia immesso sul mercato. Gli SBOM dei fornitori vanno trattati come materia prima. Lo SBOM di prodotto è l'artefatto di conformità già pronto.
Domande frequenti
È possibile riutilizzare gli SBOM dei propri fornitori per soddisfare il CRA?
In parte. Gli SBOM dei fornitori sono un input valido per i componenti da loro forniti, e il CRA si aspetta che i fabbricanti si avvalgano della documentazione upstream piuttosto che ricrearla da zero. L'obbligo previsto dall'Allegato I grava tuttavia sul fabbricante del prodotto immesso sul mercato UE: è necessario produrre e mantenere uno SBOM per il prodotto integrato, il che comporta il consolidamento degli SBOM dei fornitori con i propri componenti di prima parte, le dipendenze di build e qualsiasi codice di glue. Se uno SBOM del fornitore è privo dei campi richiesti da BSI TR-03183 (PURL, hash, licenza), il fabbricante è responsabile di colmare tali lacune prima che il prodotto sia immesso sul mercato. Gli SBOM dei fornitori vanno trattati come materia prima, non come artefatto di conformità già pronto.
Qual è il minimo normativo per la copertura delle dipendenze SBOM ai sensi del CRA?
L'Allegato I, Parte II, punto 1 fissa il minimo normativo alle dipendenze di primo livello. Il testo ufficiale recita: «identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche 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». Ciò significa che le dipendenze dirette sono il minimo normativo. Le dipendenze transitive non sono giuridicamente obbligatorie ma sono fortemente raccomandate come buona pratica: sono ciò di cui gli scanner di vulnerabilità hanno effettivamente bisogno per corrispondere i CVE con precisione, e BSI TR-03183 considera la copertura transitiva come un indicatore di qualità.
Lo SBOM deve essere aggiornato a ogni rilascio di patch?
Sì. Ogni rilascio di patch di sicurezza è un trigger obbligatorio di aggiornamento dello SBOM ai sensi del CRA. Il fascicolo tecnico, che include lo SBOM, deve essere aggiornato per tutta la durata del ciclo di vita del prodotto. Se si corregge un componente vulnerabile, lo SBOM deve riflettere la nuova versione. Si automatizzi la generazione degli SBOM nella CI/CD in modo che i rilasci di patch producano automaticamente un artefatto SBOM aggiornato, senza un passaggio manuale che possa essere omesso sotto pressione delle scadenze.