Confronti
Conformità al CRA: requisiti SBOM e strumenti
Il Cyber Resilience Act rende obbligatoria una software bill of materials per i prodotti con elementi digitali. Ecco che cosa le chiede il regolamento, che cosa aggiunge la linea guida tedesca del BSI e come si confrontano gli strumenti per la conformità al CRA.
Aggiornato il
Ogni confronto spiega che cosa fa bene l'altro prodotto, in che cosa CRACI è diverso e quando conviene usarli entrambi. Per tutte le categorie, veda tutti i confronti.
Che cosa richiede il CRA a una SBOM
Il Cyber Resilience Act, regolamento (UE) 2024/2847, colloca la SBOM tra i requisiti di gestione delle vulnerabilità. Chiede meno di quanto molti pensino: un registro leggibile da dispositivo automatico che comprenda almeno le dipendenze di primo livello, conservato nella documentazione tecnica e mostrato a un'autorità su richiesta. Ecco che cosa dice il regolamento, domanda per domanda.
| Funzionalità | Che cosa dice il CRA | Dove |
|---|---|---|
| La SBOM è obbligatoria? | Sì. I fabbricanti devono individuare e documentare i componenti contenuti nei loro prodotti, "anche redigendo una distinta base del software" | Allegato I, parte II, punto 1 |
| Che cos'è una SBOM? | "Un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software di un prodotto con elementi digitali" | Articolo 3, punto 39 |
| Quale formato? | "Un formato di uso comune e leggibile da dispositivo automatico". La Commissione può specificare il formato e gli elementi mediante atti di esecuzione | Allegato I, parte II, punto 1; articolo 13, paragrafo 24 |
| Con quale profondità? | "Almeno le dipendenze di primo livello dei prodotti" | Allegato I, parte II, punto 1 |
| Dove va inserita? | Nella documentazione tecnica, come parte delle informazioni sulla gestione delle vulnerabilità | Allegato VII, punto 2, lettera b) |
| Deve essere pubblica? | No. "I fabbricanti non dovrebbero essere tenuti a rendere pubblica la distinta base del software." Se la condivide con gli utenti, le informazioni per l'utente indicano dove trovarla | Considerando 77; allegato II, punto 9 |
| Chi può richiederla? | Un'autorità di vigilanza del mercato, su richiesta motivata, per verificare la conformità. Le autorità possono anche richiedere le SBOM per una valutazione delle dipendenze a livello dell'UE | Allegato VII, punto 8; articolo 13, paragrafo 25 |
| Per quanto tempo conservarla? | La documentazione tecnica è conservata per almeno 10 anni dall'immissione del prodotto sul mercato, o per il periodo di assistenza, se più lungo | Articolo 13, paragrafo 13 |
Il regolamento si applica integralmente dall'11 dicembre 2027, e i suoi obblighi di segnalazione si applicano dall'11 settembre 2026. Per il resto del regolamento, veda che cosa richiede il CRA.
Oltre il minimo: BSI TR-03183-2
Finché la Commissione non specificherà il formato mediante atto di esecuzione, le indicazioni pubbliche più dettagliate provengono dall'Ufficio federale tedesco per la sicurezza informatica (BSI). La sua linea guida tecnica TR-03183-2, versione 2.1.0 di agosto 2025, è un'indicazione e non fa parte del regolamento, ma mostra in che direzione vanno le aspettative:
- Formato: JSON o XML, valido rispetto a CycloneDX 1.6 o superiore, o SPDX 3.0.1 o superiore.
- Profondità: risoluzione ricorsiva delle dipendenze per ogni componente compreso nella fornitura, fino al primo componente esterno a essa, incluso.
- Fonte di verità: la SBOM deve contenere "le stesse informazioni disponibili durante il processo di build", o informazioni equivalenti dove non esiste un processo di build.
La linea guida indica anche i tipi di SBOM. Una Build SBOM "viene creata nell'ambito del processo di build". Un'Analysed SBOM "viene creata dopo il processo di build analizzando artefatti come eseguibili, pacchetti, container e immagini di macchine virtuali". Questa distinzione è la principale differenza tra gli strumenti di questa pagina.
Dipendenze di primo livello o transitive
Le dipendenze di primo livello sono la soglia minima, non l'obiettivo. Una vulnerabilità in un pacchetto transitivo resta comunque nel Suo prodotto, e il CRA chiede ai fabbricanti di affrontare e correggere le vulnerabilità nei componenti che distribuiscono. Una SBOM che si ferma al primo livello lascia quei pacchetti fuori dalla Sua gestione delle vulnerabilità. La questione pratica non è se registrare le dipendenze transitive, ma come essere certi che la registrazione corrisponda a ciò che è stato distribuito. Veda le dipendenze transitive per come elencarle e correggere quelle vulnerabili.
Build SBOM o SBOM analizzata
La maggior parte degli strumenti SBOM genera una SBOM analizzata dopo la build, o gestisce SBOM prodotte da altri strumenti. CRACI registra una build SBOM mentre la build è in esecuzione. Per un confronto tra generatori e gestori di SBOM, veda la gestione delle SBOM e gli strumenti SBOM a confronto. Per gli strumenti pensati per il CRA, veda gli strumenti per la conformità al CRA a confronto.
Dove si colloca CRACI
CRACI registra la SBOM mentre la Sua build GitHub Actions è in esecuzione. Un proxy che riconosce i pacchetti, sul runner, registra ogni pacchetto scaricato dal job, compresi i pacchetti ripristinati dalle cache CI, così la SBOM descrive la build che ha prodotto l'artefatto e non una scansione eseguita da qualche altra parte. La SBOM di ogni job riporta uno stato di completezza, e le esportazioni in CycloneDX e SPDX includono le dipendenze transitive e la licenza dichiarata di ogni componente.
Dopo il rilascio, CRACI continua a rivalutare le SBOM monitorate man mano che emergono nuove vulnerabilità e invia le notifiche previste dal CRA (preallarme, notifica e relazione finale) per Suo conto. L'API restituisce SBOM, tracce di rete e provenance. Per impostazione predefinita CRACI conserva i dati di build per 180 giorni, con conservazione personalizzata su Enterprise, quindi esporti ciò che appartiene al Suo fascicolo tecnico da conservare per 10 anni. CRACI automatizza una parte significativa della visibilità e delle evidenze sulla supply chain di cui il Suo processo per il CRA ha bisogno; la valutazione della conformità e il fascicolo tecnico restano a carico del fabbricante. Per una roadmap passo dopo passo di tutti i requisiti del CRA, veda la guida al CRA. Scopra di più sulla generazione di SBOM in fase di build, oppure prenoti una demo per vedere una SBOM registrata da una delle Sue build.
CRACI a confronto con ciascuno strumento
- CRACI e Cybeats a confronto Un sistema di riferimento per le SBOM contro SBOM registrate e monitorate.
- CRACI e FOSSA a confronto Gestione delle SBOM contro build, SBOM e monitoraggio in un unico strumento.
- CRACI e Anchore a confronto Scansione delle immagini contro registrazione e monitoraggio delle build.
- CRACI e Black Duck a confronto Scansione di codice, snippet e binari contro evidenze delle build.
- CRACI e Sonatype a confronto Controllo dei repository e SCA contro evidenze delle build.
- CRACI e ONEKEY a confronto Analisi binaria del firmware contro evidenze in fase di build.
- CRACI e Finite State a confronto Analisi dei binari e delle SBOM dei fornitori contro una registrazione della build.
- CRACI e Exein a confronto Sicurezza runtime sul dispositivo contro evidenze dalla build.
Fianco a fianco
Più strumenti in una sola pagina, per quando sceglie una categoria e non un singolo prodotto.
Domande sulla SBOM per il CRA, con le risposte
Il CRA richiede le dipendenze transitive nella SBOM?
Il regolamento fissa la soglia minima ad "almeno le dipendenze di primo livello dei prodotti" (allegato I, parte II, punto 1). Le dipendenze transitive non sono menzionate, ma un pacchetto transitivo vulnerabile resta comunque nel Suo prodotto, e il CRA Le chiede di gestire le vulnerabilità nei componenti che distribuisce. La linea guida tedesca BSI TR-03183-2 va oltre e chiede una risoluzione ricorsiva delle dipendenze.
La SBOM per il CRA deve essere pubblica?
No. Il considerando 77 afferma che i fabbricanti non dovrebbero essere tenuti a rendere pubblica la SBOM. Fa parte della documentazione tecnica, e un'autorità di vigilanza del mercato può richiederla con una richiesta motivata. Se sceglie di condividerla con gli utenti, le informazioni che accompagnano il prodotto devono indicare dove trovarla (allegato II, punto 9).
Una SBOM per il CRA deve essere in CycloneDX o in SPDX?
Il CRA chiede "un formato di uso comune e leggibile da dispositivo automatico" e non ne indica uno; la Commissione può specificare il formato mediante atto di esecuzione (articolo 13, paragrafo 24). CycloneDX e SPDX sono le due scelte comuni. BSI TR-03183-2 v2.1.0 accetta CycloneDX 1.6 o superiore e SPDX 3.0.1 o superiore, in JSON o XML.
Per quanto tempo devo conservare la SBOM?
La SBOM fa parte della documentazione tecnica, che i fabbricanti tengono a disposizione delle autorità di vigilanza del mercato per almeno 10 anni dall'immissione del prodotto sul mercato, o per il periodo di assistenza se più lungo (articolo 13, paragrafo 13).
Quando si applicano i requisiti del CRA sulla SBOM?
Gli obblighi di segnalazione del CRA si applicano dall'11 settembre 2026, e il regolamento si applica integralmente, compreso il requisito sulla SBOM dell'allegato I, dall'11 dicembre 2027.
Altre categorie
Veda CRACI sulla Sua pipeline
Prenoti una demo: esamineremo insieme le Sue build, le Sue SBOM e le Sue evidenze di conformità.
Prenota una demo