Errori SBOM sotto il CRA: 7 correzioni pratiche per i fabbricanti

Lo strumento di generazione SBOM gira, il file supera la validazione, eppure la prossima revisione di prodotto può trovare lacune lo stesso. I fallimenti ricorrenti nella verifica di conformità CRA non riguardano di solito casi limite normativi oscuri. Si tratta di alberi di dipendenze superficiali, inventari costruiti solo dal sorgente, record obsoleti e componenti che gli scanner non riescono ad abbinare a una vulnerabilità. Il Cyber Resilience Act richiede uno SBOM in formato leggibile da un dispositivo automatico, comunemente utilizzato, che copra almeno le dipendenze di primo livello e venga conservato con la documentazione tecnica. Questo articolo tratta i sette divari tra uno SBOM che tecnicamente esiste e uno che può sostenere la gestione delle vulnerabilità. È lo SBOM che un'autorità di vigilanza del mercato si aspetta di vedere.

Errori in sintesi

• Albero sorgente, non artefatto distribuito: generare dall'artefatto o dall'immagine di build per rendere visibili il codice compilato, i pacchetti OS e il firmware.
• Campi di identità scarsi: usare versioni esatte, hash, PURL dove disponibili e nomi del fornitore per consentire agli scanner di abbinare i CVE.
• Solo dipendenze dirette: aggiungere la scansione dei lock file e degli artefatti di build per includere nello SBOM le dipendenze indirette e quelle pacchettizzate.
• File generato una sola volta: rigenerare e archiviare lo SBOM per ogni rilascio, poi mantenere aggiornata la corrispondenza delle vulnerabilità.
• Codice di prodotto omesso: i componenti interni, proprietari, commerciali e firmware necessitano comunque di identificatori ed evidenze.
• Copia-incolla dai fornitori: gli SBOM dei fornitori sono input. Riconciliarli con il codice di prima parte e l'artefatto di rilascio finale.
• Dispersione SBOM: mantenere un unico SBOM di prodotto autorevole per rilascio, così la versione 1.4.2 ha un solo record difendibile.

Cosa conta per la documentazione SBOM

Quel minimo normativo non equivale al minimo operativo per la gestione delle vulnerabilità. Uno SBOM con sole dipendenze dirette può soddisfare la locuzione sul minimo delle dipendenze ma risultare ancora troppo superficiale per identificare rapidamente i prodotti interessati. BSI TR-03183, le linee guida ENISA, le linee guida SBOM CISA e la pratica corrente degli strumenti vanno letti come benchmark di qualità che aiutano i fabbricanti a rendere operativo l'obbligo del CRA.

Errore 1: lo SBOM descrive l'albero sorgente, non il prodotto distribuito

I manifest sorgente sono comodi, ma non rappresentano il prodotto. Una scansione del sorgente può segnalare in eccesso le dipendenze di sviluppo e non rilevare ciò che compare solo dopo la build, il packaging, la stratificazione dei container, il collegamento statico o l'integrazione firmware. Per un fabbricante, lo SBOM deve rispondere a cosa c'era nel rilascio del prodotto, non solo a cosa era dichiarato in un file di pacchetto.

La differenza pesa di più nei prodotti embedded e containerizzati. Una scansione a livello di linguaggio può non rilevare i pacchetti OS in uno strato base di container. Un'esportazione Yocto o Buildroot può non rilevare firmware del fornitore di chip, bootloader, moduli kernel o blob binari entrati al di fuori del sistema di build. Se quei componenti si trovano nell'artefatto distribuito, appartengono alla documentazione di rilascio anche quando uno scanner automatico di pacchetti non riesce a inferirli.

La soluzione consiste nel generare dall'artefatto o dall'immagine di rilascio, poi confrontare con l'output del sorgente e del lock file. Per i container, scansionare l'immagine finale per digest. Per il firmware, combinare l'output SBOM del sistema di build con l'analisi binaria e i record manuali per i componenti che gli strumenti non riescono a identificare automaticamente.

Errore 2: hash e PURL mancanti rendono i componenti non abbinabili

Uno SBOM privo di versione accurata, hash, fornitore e identificatori di pacchetto è difficile da usare per la corrispondenza delle vulnerabilità. Il file può essere leggibile da un dispositivo automatico, ma uno scanner ha comunque bisogno di un'identità stabile del componente per determinare se un CVE, un avviso OSV, un GitHub Security Advisory o una voce CISA KEV si applica.

Ogni componente deve avere sufficiente identità da sopravvivere alla corrispondenza automatica:

Non si tratta solo di igiene. NIST ha annunciato il 15 aprile 2026 che l'arricchimento NVD è ora prioritario per i CVE selezionati perché il volume di vulnerabilità ha superato la capacità di arricchimento completo. Questo rende la corrispondenza basata solo su CPE un piano più debole per le future operazioni sulle vulnerabilità. Usare PURL dove disponibile, mantenere gli hash per gli artefatti distribuiti e non considerare sufficiente il solo nome del componente.

Un errore di formato comune è usare CycloneDX 1.3 o versioni precedenti. Il supporto VEX di base è arrivato in CycloneDX 1.4 e la struttura evidence più ricca per i componenti è arrivata in CycloneDX 1.5. Per la preparazione CRA attuale, puntare a CycloneDX 1.6 o versioni successive, o a un profilo SPDX corrente che gli strumenti possano consumare in modo affidabile. Verificare l'output del generatore prima di presupporre che il formato supporti i campi necessari al processo.

Errore 3: fermarsi alle dipendenze dirette

Le dipendenze dirette sono il minimo CRA. Non bastano per una gestione utile delle vulnerabilità. Una dipendenza transitiva è un componente estratto da un altro componente e può portare la vulnerabilità che conta. Quando un CVE colpisce un pacchetto transitivo non presente nello SBOM, il prodotto può risultare interessato mentre la pipeline di corrispondenza rimane silente.

Per colmare questo divario, usare i lock file dove l'ecosistema li prevede, scansionare gli artefatti di build oltre al sorgente e ispezionare i pacchetti che raggruppano o fondono dipendenze. Trattare la copertura transitiva come una pratica di qualità per l'audit, non come un'impostazione secondaria nascosta nel comportamento predefinito di uno scanner.

Errore 4: 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 contro componenti già nel prodotto. Nuove versioni firmware, patch e aggiornamenti dei fornitori cambiano il prodotto. Il CRA si aspetta inoltre che la documentazione tecnica venga aggiornata continuamente dove appropriato durante il periodo di assistenza.

Trigger di aggiornamento comuni:

La CI/CD è il controllo pratico. Ogni rilascio dovrebbe produrre un artefatto SBOM corrente archiviato insieme alla build e collegato alla documentazione tecnica. Le voci manuali dovrebbero esistere solo per i componenti che gli strumenti non riescono a rilevare, e anche quelle voci richiedono revisione quando il prodotto cambia.

Errore 5: omettere i componenti interni, proprietari e firmware

Una scorciatoia comune consiste nel documentare solo le dipendenze open source e omettere le librerie interne, i moduli commerciali, il firmware proprietario o i blob dei fornitori. Non è uno SBOM di prodotto. Se un componente è distribuito nel prodotto, rientra nell'ambito, anche quando non ha una pagina di registry pubblica.

I componenti interni spesso non hanno PURL di ecosistema né record di pacchetto pubblico. Usare un identificatore interno, la propria organizzazione come fornitore dove appropriato, la versione esatta o l'ID di build e l'hash dell'artefatto binario. Per i componenti commerciali, conservare il nome del fornitore, la versione, le prove di licenza e i riferimenti al contratto nella documentazione tecnica.

Per i prodotti hardware-software, il firmware è dove questo diventa visibile. Moduli Wi-Fi, modem, elementi sicuri, bootloader, binari di ambiente di esecuzione trusted e moduli kernel fuori albero possono portare vulnerabilità pur rimanendo invisibili agli scanner di pacchetti di linguaggio. Usare gli SBOM dei fornitori dove disponibili, aggiungere record manuali dove non lo sono e usare l'analisi binaria come verifica. Per il lato hardware del pacchetto di prove, vedere HBOM sotto il CRA.

Errore 6: affidarsi agli SBOM dei fornitori come artefatto finito

Gli SBOM dei fornitori sono input validi. Non sono lo SBOM di prodotto finito. Il fabbricante immette il prodotto integrato sul mercato UE. Lo SBOM di prodotto deve combinare i componenti dei fornitori, il codice di prima parte, gli output di build, il firmware, il codice di collegamento e le relazioni di dipendenza specifiche del prodotto.

Il modo in cui questo fallisce è facile da non notare: un fornitore consegna un file CycloneDX, un altro consegna SPDX, un terzo consegna un inventario PDF e la cartella del prodotto finale contiene link a tutti e tre. Questa è documentazione dei fornitori, non un unico record di prodotto. Un revisore ha comunque bisogno di sapere quali componenti erano nella versione 1.4.2 del prodotto.

Riconciliare invece di copiare. Unire gli SBOM dei fornitori nello SBOM di prodotto, normalizzare i campi di identità, registrare i noti ignoti e conservare gli SBOM upstream come prove a supporto. Se uno SBOM del fornitore manca di PURL, hash, licenza o versione esatta, documentare la lacuna e colmare ciò che si può prima del rilascio. Un URL a un file upstream non equivale a uno SBOM di prodotto integrato.

Errore 7: molti SBOM, nessun unico record di prodotto

La dispersione SBOM è la fase che segue quando i team adottano gli strumenti. C'è uno SBOM dell'app, uno SBOM del container, uno SBOM del firmware, diversi SBOM dei fornitori e un foglio di calcolo gestito da un product manager. Nessuno di essi è la risposta autorevole per il rilascio del prodotto immesso sul mercato.

Questo crea rischio di audit e operativo. Quando compare una nuova vulnerabilità attivamente sfruttata, il team deve cercare tra i frammenti prima di poter affermare se il prodotto è interessato. Quando un'autorità fa una richiesta motivata, il pacchetto di prove non dovrebbe dipendere dal fatto che qualcuno ricordi quale cartella contiene l'ultimo merge.

Usare un unico SBOM di prodotto autorevole per rilascio, con SBOM di componente a supporto conservati al di sotto. Conservarlo per almeno 10 anni dopo che il prodotto è stato immesso sul mercato, o per il periodo di assistenza, a seconda di quale sia più lungo. Archiviarlo dove il rilascio, il monitoraggio delle vulnerabilità, le decisioni VEX e la documentazione tecnica possono tutti fare riferimento alla stessa versione.