# SBOM per il Cyber Resilience Act

La distinta base del software (SBOM) è l'elenco degli ingredienti del software di un prodotto. Con il CRA diventa obbligatoria ed è l'unico modo pratico per rispondere alla domanda "siamo interessati?" quando viene pubblicata la prossima vulnerabilità.

Source: https://kernwatch.com/it/sbom · Ultimo aggiornamento: 2026-10-17

## In sintesi

- L'allegato I del CRA richiede una distinta base del software (SBOM) in un formato di uso comune e leggibile da dispositivo automatico, che copra almeno le dipendenze di primo livello.
- CycloneDX (OWASP) e SPDX (ISO/IEC 5962) sono i due formati SBOM più diffusi.
- La SBOM fa parte della documentazione tecnica: non deve essere pubblicata, ma le autorità di vigilanza del mercato possono richiederla.
- Buona prassi: una SBOM per ogni release supportata, generata nella pipeline di build e confrontata ogni giorno con i dati sulle vulnerabilità.

## Che cos'è una SBOM

Una SBOM elenca ogni componente software di un prodotto: librerie open source, sistema operativo, moduli di terze parti e pacchetti propri. Per ogni componente riporta:

- nome e versione, ad esempio `openssl 3.0.13`

- fornitore

- un identificativo univoco: un package URL (purl) o un CPE

- licenza

- da quali altri componenti dipende

## Che cosa richiede il CRA

L'allegato I del Cyber Resilience Act impone ai fabbricanti di individuare e documentare le vulnerabilità e i componenti contenuti nei loro prodotti, **anche redigendo una distinta base del software in un formato di uso comune e leggibile da dispositivo automatico, che copra almeno le dipendenze di primo livello**. La SBOM fa parte della documentazione tecnica: non è necessario pubblicarla, ma le autorità di vigilanza del mercato possono richiederla.

## CycloneDX e SPDX

Due formati sono ampiamente diffusi ed entrambi sono leggibili da dispositivo automatico:

- **CycloneDX** (OWASP): pensato per i casi d'uso di sicurezza, con supporto integrato per la sfruttabilità delle vulnerabilità (VEX).

- **SPDX** (Linux Foundation, ISO/IEC 5962): nato per la conformità delle licenze, ampiamente supportato dagli strumenti di build.

La maggior parte degli ecosistemi di build è in grado di generarli: ad esempio Syft o cdxgen per container e file system, i plugin CycloneDX per Maven, Gradle e npm e l'output SPDX del Yocto Project per Linux embedded.

## Una SBOM è utile solo se resta aggiornata

Una SBOM redatta una sola volta per la dichiarazione di conformità è già superata alla release successiva. Ciò che aiuta nella pratica:

- una SBOM per ogni versione rilasciata, generata nella pipeline di build;

- ogni componente confrontato ogni giorno con i nuovi dati sulle vulnerabilità;

- una decisione registrata per ogni rilievo: interessato, non interessato o corretto;

- le differenze tra release visibili a colpo d'occhio.

## Come Kernwatch utilizza le SBOM

- Importazione di CycloneDX o SPDX tramite caricamento o dalla CI con una chiave API.

- Confronto tra release per vedere quali componenti sono stati aggiunti, rimossi o modificati.

- Confronto dei componenti con identificativo di pacchetto (purl) con OSV, l'elenco CISA delle vulnerabilità note sfruttate e la banca dati europea delle vulnerabilità: ogni giorno nei piani a pagamento, ogni settimana nel piano Free.

- Decisioni di valutazione esportate come VEX insieme alla SBOM quando lo chiede un cliente o un'autorità.

## Fonti ufficiali

- [Regolamento (UE) 2024/2847, allegato I, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [Specifica CycloneDX](https://cyclonedx.org/)
- [Specifica SPDX](https://spdx.dev/)
- [Banca dati delle vulnerabilità OSV](https://osv.dev/)
- [Catalogo CISA delle vulnerabilità note sfruttate](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)