---
title: "Orchestrare SBOM Multiple"
url: "https://www.sparkfabrik.com/it/blog/orchestrare-sbom-multiple/"
lang: "it"
type: "blog-post"
date: "2026-08-31"
lastmod: "2026-08-31"
author: "SparkFabrik Team"
description: "Gestire decine di documenti per release crea disallineamenti con i requisiti del Cyber Resilience Act. Impara a collegare, firmare e comporre i file CycloneDX e SPDX dei singoli servizi in un'unica distinta base di prodotto. Strategie pratiche per mantenere la tracciabilità senza perdere i dettagli."
tags: ["DevOps","Security"]
schema:
"@context": "https://schema.org"
"@type": "BlogPosting"
"headline": "Orchestrare SBOM Multiple"
"description": "Gestire decine di documenti per release crea disallineamenti con i requisiti del Cyber Resilience Act. Impara a collegare, firmare e comporre i file CycloneDX e SPDX dei singoli servizi in un'unica distinta base di prodotto. Strategie pratiche per mantenere la tracciabilità senza perdere i dettagli."
"url": "https://www.sparkfabrik.com/it/blog/orchestrare-sbom-multiple/"
"datePublished": "2026-08-31T00:00:00+00:00"
"dateModified": "2026-08-31T00:00:00+00:00"
"author":
"@type": "Person"
"name": "SparkFabrik Team"
"image": "https://www.sparkfabrik.com/images/blog/orchestrare-sbom-multiple/featured.webp"
"publisher":
"@type": "Organization"
"name": "SparkFabrik"
"url": "https://www.sparkfabrik.com"
"logo": "https://www.sparkfabrik.com/images/logo.svg"
---
# Orchestrare SBOM Multiple
**Autore:** SparkFabrik Team
**Pubblicato:** 31 August 2026
**Tags:** DevOps, Security
---
{{% tldr %}}Un prodotto con dodici servizi sforna facilmente trenta SBOM a release, ma il Cyber Resilience Act ne chiede una sola: quella del prodotto immesso sul mercato. Generarle non è più il problema; comporle in un documento autorevole, firmato e conservato per dieci anni sì. Vediamo quando conviene fondere tutto in un file e quando serve invece una root BOM che referenzia i componenti senza appiattirli, con il test decisivo: quanto tempo passa da un CVE alla lista dei servizi impattati.{{% /tldr %}}
Un prodotto composto da dodici servizi, tre immagini base diverse e due componenti acquistati da fornitori produce con facilità venti o trenta documenti SBOM per ogni release. Il Cyber Resilience Act[^1], però, ne chiede uno: l'unità di evidenza è il prodotto immesso sul mercato, non il repository né la singola build.
È lo scarto fra come funzionano le pipeline e come ragiona il regolatore. La **generazione delle SBOM** è un problema risolto: **Syft**[^2], **Trivy**[^3] e gli scanner integrati nei registry producono CycloneDX o SPDX in pochi secondi. Quello che manca, nella maggior parte dei setup che abbiamo visto, è la **composizione**: un documento autorevole per versione di prodotto, che tenga insieme le SBOM dei componenti senza appiattirle in un file monolitico. Questo articolo affronta quel problema: come collegare, firmare e mantenere nel tempo una distinta base di prodotto in architetture multi-servizio.
## Perché in un prodotto multi-servizio le SBOM si moltiplicano?
La moltiplicazione non è un difetto di configurazione: è una proprietà strutturale delle architetture cloud native. Agisce su tre assi che si compongono per moltiplicazione, non per somma:
1. **Servizi e repository**: ogni servizio con un proprio ciclo di rilascio genera i propri documenti, e ogni monorepo con più artefatti pubblicabili si comporta come N sorgenti distinte.
2. **Tipologia lungo il ciclo di vita**: la tassonomia CISA[^4] distingue Design, Source, Build, Analyzed, Deployed e Runtime SBOM. Sono viste diverse dello stesso software, non copie.
3. **Origine dei componenti**: codice first-party, immagini base con i loro pacchetti OS, runtime linguistici, firmware, componenti di terze parti consegnati dai fornitori.
Una **Source SBOM** e una **Build SBOM** dello stesso servizio non sono ridondanti. La prima descrive ciò che è dichiarato nei manifest e nei lock-file, la seconda ciò che è effettivamente entrato nell'artefatto spedito. Chi genera solo dal sorgente ottiene contemporaneamente falsi positivi, cioè dipendenze dichiarate e mai compilate, e punti ciechi: le librerie di sistema dell'immagine base, i binari statici linkati in fase di build, i moduli vendorizzati. Il primo caso gonfia il triage, il secondo lo rende incompleto proprio dove il rischio è più opaco.
Il failure mode ricorrente ha una forma riconoscibile. Cartelle di artefatti CI con retention limitata nel tempo, un foglio di calcolo che tiene traccia di quale merge sia il più recente, nessun documento che qualcuno sia disposto a dichiarare autorevole per la release in commercio. Questo **SBOM sprawl** ha un costo che si manifesta esattamente nel momento peggiore: alla comparsa di una vulnerabilità sfruttata attivamente, il team non risponde alla domanda "quale versione di prodotto contiene il componente affetto e in quale servizio", ma alla domanda molto più povera "dove sta il file giusto".
La probabilità che quella domanda arrivi non è remota. Il rapporto OSSRA 2024 fotografa il 91% dei repository esaminati con componenti arretrati di dieci versioni o più[^5]: in un prodotto con dieci servizi, la presenza di almeno un componente obsoleto e potenzialmente affetto è la condizione normale, non l'eccezione. La visibilità granulare sulle dipendenze è il presupposto di tutto il resto, un punto che abbiamo già trattato analizzando [come la Software Bill of Materials rende tracciabili i rischi di terze parti sotto il CRA](/it/blog/sbom-e-cyber-resilience-act-mappare-i-rischi-delle-dipendenze/).
Sul piano tecnico il regolamento chiede quattro cose, e conviene leggerle come specifiche. La SBOM deve essere **machine-readable**: JSON o XML in formato CycloneDX o SPDX[^6], mentre un PDF allegato alla documentazione non assolve l'obbligo. Il formato comune non è prescritto. Il minimo legale, fissato dall'Allegato I, Parte II del CRA, sono le dipendenze di primo livello, ma **in cloud native le transitive sono la sostanza del rischio**, quindi il minimo legale è un pavimento, non un obiettivo. Soprattutto: serve la rappresentazione delle relazioni di dipendenza e contenimento, non una lista piatta di nomi.
**La SBOM è parte della documentazione tecnica** definita dall'Allegato VII del CRA[^1]: non si trasmette proattivamente, deve esistere all'immissione sul mercato ed essere producibile su richiesta motivata di un'autorità di sorveglianza. Le scadenze fissano il contesto: 11 settembre 2026 per gli obblighi di reporting delle vulnerabilità, 11 dicembre 2027 per la piena applicazione.
## Compose o merge: quale strategia regge un audit di prodotto?
Entrambe le strade sono conformi. Il CRA non impone un meccanismo di aggregazione, impone che esista un documento machine-readable che rappresenti il prodotto con le sue relazioni di dipendenza. La **scelta fra fondere e collegare** è quindi ingegneristica, e va motivata con i costi informativi che comporta.
### Cosa perdi quando fondi tutto in un file
Il merge piatto ha un paradosso al centro: la **deduplicazione**. Nei tool di build eliminare i duplicati è buona pratica; nell'analisi di supply chain, deduplicare i componenti di N documenti cancella l'unica informazione che serve, cioè quale servizio usa quale versione. Restano i nomi, sparisce la mappa.
* **Il triage cambia natura**: da una query sul grafo ("quali componenti del prodotto 3.4 dipendono da `libX < 2.9`, e in quale servizio") a una ricerca testuale seguita da verifica manuale servizio per servizio. È qui che si allunga l'MTTR, non nella scrittura della patch.
* **I lifecycle sono disaccoppiati**: un documento fuso è uno snapshot che invecchia al primo deploy indipendente di un singolo servizio, e ogni rigenerazione impone di ricostruire l'intero file.
* **La provenienza si perde**: hash e firme dei documenti originali non sopravvivono alla fusione, quindi l'integrità è verificabile solo sull'aggregato.
Il merge resta la scelta corretta in condizioni precise: prodotto sostanzialmente monolitico, poche decine di componenti, una sola cadenza di rilascio, oppure consumatore della SBOM che non sa risolvere riferimenti esterni. In quei casi produce un artefatto autonomo e verificabile con meno infrastruttura attorno.
### Il compose gerarchico: una root BOM che referenzia, non che copia
La struttura è semplice: un documento di prodotto per versione, i cui componenti di tipo `application` rappresentano i servizi, ciascuno con un riferimento esterno alla propria SBOM. In CycloneDX il meccanismo è l'`externalReference` di tipo `bom` che trasporta un **BOM-Link**[^7] nella forma `urn:cdx:/`, capace di puntare a un intero documento o a un singolo `bom-ref` al suo interno. In SPDX l'equivalente si ottiene con la coppia `ExternalDocumentRef` più `Relationship` (`DESCRIBES`, `CONTAINS`, `DEPENDS_ON`).
Le proprietà che ne derivano sono quelle che il merge non può offrire: **rigenerazione indipendente per servizio**, integrità verificabile documento per documento con checksum e firma separati, provenienza preservata, dimensione dei singoli file gestibile anche con centinaia di componenti per servizio. È la stessa logica dell'assembly gerarchico di una distinta base manifatturiera, dove il livello prodotto referenzia i sotto-assiemi invece di elencare ogni singola vite.
Il vincolo, che va dichiarato: **la risoluzione dei riferimenti è a carico del consumatore**. Se la **root BOM** punta a URN non risolvibili o ad artefatti scaduti in un registry con retention di trenta giorni, l'evidenza si spezza e il documento diventa una promessa non mantenuta. Il compose richiede quindi uno storage immutabile e indirizzabile per le SBOM di componente, con la stessa retention del prodotto. Valutare questo tipo di trade-off architetturale, dove una scelta di formato diventa un requisito di infrastruttura, è terreno che abbiamo sistematizzato nella [guida ai modelli di difesa per architetture cloud native](/it/landing/guida-cloud-native-security/).
### Il diagramma: come si legge una root BOM
```mermaid
flowchart LR
P["SBOM prodotto v3.4
CycloneDX 1.6
metadata.component: application"]
S1["api-gateway"]
S2["checkout-service"]
S3["frontend"]
O1["SBOM immagine OCI
pacchetti OS and runtime"]
O2["SBOM immagine OCI
pacchetti OS and runtime"]
O3["SBOM immagine OCI
pacchetti OS and runtime"]
F["SBOM fornitore
riconciliata"]
V["VEX prodotto v3.4"]
P -->|"externalReference type=bom (BOM-Link)"| S1
P -->|"externalReference type=bom (BOM-Link)"| S2
P -->|"externalReference type=bom (BOM-Link)"| S3
S1 -->|CONTAINS| O1
S2 -->|CONTAINS| O2
S3 -->|CONTAINS| O3
F -.->|"input riconciliato, non link diretto"| P
P --> V
```
Gli archi trasportano riferimenti, non contenuti copiati: la root BOM resta l'unico documento autorevole per la release, e ogni foglia conserva la propria firma. Il nodo laterale è il punto meno ovvio: la SBOM del fornitore non entra come link opaco verso un URL di terzi, perché in quel caso l'evidenza dipenderebbe dalla disponibilità di un endpoint che non controlliamo. Va riconciliata prima, come spiegato più sotto.
## Come si costruisce la SBOM di prodotto dentro la pipeline?
Ogni scelta qui va agganciata a un requisito: si genera dall'artefatto perché l'evidenza deve riflettere ciò che è stato spedito, si normalizzano gli identificatori perché il tracciamento per componente lo esige, si firma perché l'integrità dell'evidenza conservata è parte della documentazione tecnica.
### Generare dall'artefatto costruito, non dal sorgente
Regola operativa: la Build SBOM si genera dall'immagine OCI o dal binario prodotto dalla pipeline, e si confronta con lock-file e sorgente per rilevare divergenze. Dove il tooling non riesce a inferire, come per binari statici, firmware o dipendenze vendorizzate, si aggiungono record manuali tracciati e datati.
```bash
# syft 1.x, trivy 0.5x - si usa il digest, non il tag
IMAGE="registry.example.com/checkout-service@sha256:9f2a...c41d"
DIGEST="9f2a...c41d"
# generatore primario: CycloneDX JSON su file versionato per servizio e digest
syft "$IMAGE" -o cyclonedx-json="sbom/checkout-service-${DIGEST}.cdx.json"
# secondo scanner sullo stesso artefatto, per confronto del set di componenti
trivy image --format cyclonedx \
--output "sbom/checkout-service-${DIGEST}.trivy.cdx.json" "$IMAGE"
```
Nota onesta: due generatori sullo stesso artefatto non producono set identici. Syft e Trivy divergono tipicamente su binari compilati staticamente e su pacchetti installati fuori dal package manager. Il delta non è un bug, è informazione sulla copertura degli analizzatori: va registrato accanto alla SBOM, e sicuramente non nascosto scegliendo il tool che restituisce meno righe.
### Normalizzare l'identità dei componenti prima di comporre
Il compose funziona solo se un componente è identificabile in modo stabile fra documenti generati da tool diversi, in momenti diversi. I **campi minimi**, coerenti con gli elementi minimi CISA[^8] e con la guideline tecnica BSI TR-03183[^9], sono:
* nome del componente e versione esatta;
* fornitore o autore;
* **Package URL (purl)**[^10], oppure CPE[^11] dove il purl non è applicabile;
* hash dell'artefatto (SHA-256);
* relazione con il componente padre.
Il problema è concreto: lo stesso pacchetto compare come `openssl` fra i pacchetti OS, come `libssl3` con il nome della distribuzione, e come dipendenza embedded di un binario Go. Senza purl normalizzato la query di triage sul prodotto restituisce tre entità distinte, e la risposta all'autorità o al cliente è incompleta pur essendo formalmente prodotta. La **normalizzazione** va eseguita in pipeline, come step deterministico e versionato, mai a mano in fase di audit.
### Assemblare, firmare, pubblicare
Il job di release del prodotto costruisce la root BOM con `metadata.component` valorizzato su prodotto e versione, i componenti applicativi per ogni servizio e i riferimenti esterni alle SBOM già pubblicate.
```json
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:8f7c1c1e-6a3e-4c0b-9e1a-2d5b7f0a11c4",
"version": 1,
"metadata": {
"component": {
"bom-ref": "prod-retail-3.4.0",
"type": "application",
"name": "retail-platform",
"version": "3.4.0"
}
},
"components": [
{
"bom-ref": "svc-checkout-2.11.3",
"type": "application",
"name": "checkout-service",
"version": "2.11.3",
"externalReferences": [
{
"type": "bom",
"url": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1"
}
]
}
],
"dependencies": [
{ "ref": "prod-retail-3.4.0", "dependsOn": ["svc-checkout-2.11.3"] },
{ "ref": "svc-checkout-2.11.3", "dependsOn": [] }
]
}
```
Quando il consumatore non risolve i riferimenti, la via alternativa è un merge gerarchico, che almeno preserva l'annidamento dei componenti:
```bash
# cyclonedx-cli 0.32.x - merge gerarchico, conserva la struttura ad assembly.
# Merge solo delle SBOM canoniche e normalizzate dei servizi del prodotto.
# Una per servizio: non il glob grezzo, che includerebbe sia l'output Syft
# sia quello Trivy dello stesso artefatto.
cyclonedx merge --hierarchical \
--input-files \
sbom/canonical/api-gateway.cdx.json \
sbom/canonical/checkout-service.cdx.json \
sbom/canonical/frontend.cdx.json \
--name retail-platform --version 3.4.0 \
--output-file product-3.4.0.cdx.json
# cosign 2.x - firma keyless via OIDC, bundle verificabile accanto al documento
cosign sign-blob --yes product-3.4.0.cdx.json \
--bundle product-3.4.0.cdx.json.bundle
```
L'automazione di questi passaggi dentro CI/CD, con **scanner e firma** (ad esempio tramite **Cosign[^12]**) come step nativi e non come job opzionali, è la parte del lavoro DevSecOps [che abbiamo descritto parlando di tooling e integrazione nelle pipeline cloud](/it/blog/cloud-devsecops/). La **SBOM firmata** finisce poi in **storage immutabile**, e il riferimento al file entra nella documentazione tecnica della release insieme al nome del tool, alla sua versione e alla data di generazione.
```mermaid
flowchart TD
A["Pipeline servizio
build immagine OCI"] --> B["Syft + Trivy
Build SBOM per digest"]
B --> C["Normalizzazione purl
step deterministico"]
C --> D["Store SBOM immutabile
indirizzabile per URN"]
D --> E["Job di release prodotto
assembly root BOM"]
E --> F["Cosign: firma keyless"]
F --> G["Documentazione tecnica
retention 10 anni"]
D --> H["Ingestione a grafo
GUAC: query di triage"]
```
## SBOM dei fornitori, informazioni mancanti e ciclo di vita dell'evidenza
Due failure mode restano aperti anche nei setup ben automatizzati: i documenti che arrivano da terzi e la manutenzione dell'evidenza nel tempo.
### Le SBOM dei fornitori sono input, non l'artefatto finito
Lo scenario è ricorrente. **Un fornitore consegna CycloneDX, un secondo SPDX, un terzo un PDF con l'elenco delle librerie**; la cartella di release contiene tre link a tre portali diversi. Quello è materiale dei fornitori, non un record di prodotto, e in caso di richiesta motivata non risponde alla domanda su quale versione del nostro prodotto contenga il componente affetto.
La **riconciliazione** ha una sequenza precisa:
1. convertire o normalizzare i campi identità (purl, versione, hash) nello schema usato internamente;
2. integrare i componenti nella distinta di prodotto, oppure collegarli via BOM-Link dopo aver verificato che il riferimento sia risolvibile e persistente;
3. conservare i documenti originali upstream come supporto probatorio, con data e canale di ricezione;
4. registrare esplicitamente ciò che non è stato possibile determinare.
Il quarto punto è quello che distingue una documentazione difendibile da una lacunosa. **Quando un fornitore non consegna una SBOM completa, il componente non si omette**: si documentano i **known unknowns**, cioè evidenza contrattuale e di acquisto, campi verificabili raccolti in autonomia scansionando i binari ricevuti, hash e prova di versione, nota esplicita di ciò che non è determinabile. Un'assenza dichiarata è evidenza; un'assenza silenziosa è una non conformità.
Le implicazioni di questa catena di responsabilità sui componenti di terze parti e sulle dipendenze upstream sono un tema [che il regolamento europeo ha spostato dalla community a chi immette il prodotto sul mercato](/it/blog/cra-e-open-source/), e la riconciliazione è il punto in cui quella responsabilità diventa operativa.
### Ogni quanto si rigenera e per quanto si conserva
**La rigenerazione risponde a trigger, non a un calendario**: cambio di versione software o firmware, rilascio di una patch, variazione dello stato di sfruttabilità di una vulnerabilità con conseguente aggiornamento del **VEX** (Vulnerability Exploitability eXchange), aggiunta, rimozione o sostituzione di un componente, modifica di design rilevante, cambio degli standard applicati. **Le cadenze periodiche restano utili come rete di sicurezza**: revisione trimestrale di SBOM e stato delle vulnerabilità, revisione annuale della documentazione tecnica, freeze prima della fine del periodo di supporto.
Qui il compose mostra il suo argomento più forte. I trigger sono locali al servizio, quindi si rigenera un documento e si riemette la root BOM alla release di prodotto; nel merge, ogni trigger locale impone di ricostruire il documento intero, con il rischio di introdurre delta non voluti su componenti che nessuno ha toccato.
Sulla **conservazione il vincolo è lungo**, fissato dall'Articolo 13 del CRA[^1]: **almeno dieci anni dall'immissione sul mercato**, o l'intero periodo di supporto se superiore, con il conteggio che parte dall'ultima unità immessa. Questo **esclude la CI** come luogo di archiviazione.
Ad esempio, se il registry è Google Artifact Registry[^13], il servizio di riferimento per la composizione software è Artifact Analysis, che oltre alla scansione delle vulnerabilità supporta la generazione e la gestione delle SBOM degli artefatti archiviati[^14]: un punto di partenza solido, ma non un archivio di conformità. La retention di default e le cleanup policy del repository non sono allineate a un obbligo decennale, e vanno configurate o affiancate da uno storage dedicato.
Per gestire questa complessità nel lungo periodo, l'infrastruttura deve evolvere oltre il semplice salvataggio dei file. Vale la pena **valutare tooling specifico per fetch, storage e trasformazione dei documenti**, come Bomctl[^15], affiancato da un livello di interrogazione a grafo come GUAC[^16] per rispondere alle query di triage in tempi utili.
Ultimo punto, spesso trascurato: **la SBOM è documentazione tecnica confidenziale, non materiale pubblico**. È una mappa dei componenti utile a chi cerca un punto di ingresso. Rilascio all'autorità di sorveglianza su richiesta motivata (in Italia il ruolo di riferimento è dell'ACN), ai clienti business sotto NDA, con tracciamento di chi ha ricevuto quale versione e quando. La convergenza internazionale su questi principi è documentata nella guidance congiunta *A Shared Vision of Software Bill of Materials for Cybersecurity*[^17] pubblicata nel settembre 2025 da CISA, NSA e diciannove partner.
## Lezioni operative
La regola decisionale sta in due righe: se il prodotto ha più di un ciclo di rilascio indipendente, il compose gerarchico è l'unica strategia mantenibile; sotto quella soglia il merge costa meno e regge un audit senza problemi.
Tre cose che rifaremmo diversamente, dalla nostra esperienza su pipeline multi-servizio:
1. **Trattare lo storage delle SBOM di componente come artefatto di lungo periodo dal giorno uno**, non come output di CI con retention di default. Recuperare documenti scaduti dopo sei mesi significa rigenerarli da immagini che non esistono più.
2. **Normalizzare gli identificatori in pipeline prima che il volume renda l'operazione retroattiva.** A trecento documenti la normalizzazione a posteriori diventa un progetto, non uno step.
3. **Misurare la qualità dell'orchestrazione con una sola domanda, cronometrata**: quanto tempo serve, partendo da un CVE, per elencare le versioni di prodotto affette e i servizi impattati. Se la risposta si misura in ore, l'architettura dell'evidenza non funziona, indipendentemente dalla conformità formale del documento.
Una questione resta aperta, e va dichiarata: la maturità dei consumatori nella risoluzione dei BOM-Link è ancora disomogenea, e questo è oggi l'argomento più solido contro il compose puro. La strategia difendibile mantiene la root BOM linkata come sorgente autorevole ed è in grado di produrre su richiesta una vista appiattita come export derivato, mai come documento di riferimento.
Il prossimo e ultimo articolo della serie affronta l'observability, log, metriche e tracce, come base tecnica per rispondere agli obblighi di notifica e reporting previsti da CRA e NIS2.
Su questi temi lavoriamo quotidianamente nella nostra pratica di [software supply chain security](/it/servizi/cloud-native-services/supply-chain-security/), e contribuiamo come membri di OpenSSF[^18], CNCF e LF Europe alla definizione degli strumenti che rendono questa evidenza verificabile invece che dichiarata.
Hai bisogno di un confronto, un audit o una consulenza dedicata in ambito di sicurezza, DevSecOps, adeguamento al CRA? [Contatta i nostri esperti](/it/contatti/).
## Note e fonti
[^1]: **Cyber Resilience Act**, The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU law mandating cybersecurity requirements, including machine-readable SBOMs and 10-year documentation retention, for digital products. (fonte: )
[^2]: **Syft**, Syft is an open-source CLI tool and Go library developed by Anchore for generating Software Bill of Materials (SBOMs) from container images and filesystems. (fonte: )
[^3]: **Trivy**, Trivy is an open-source vulnerability and misconfiguration scanner by Aqua Security. It scans containers, filesystems, and repositories, and can generate SBOMs in formats like CycloneDX. (fonte: )
[^4]: **CISA**, The Cybersecurity and Infrastructure Security Agency (CISA) is the U.S. cyber defense agency that publishes official guidance on the Minimum Elements for a Software Bill of Materials (SBOM). (fonte: )
[^5]: Secondo il rapporto OSSRA 2024 (Open Source Security and Risk Analysis), il 91% dei repository di codice esaminati include componenti arretrati di 10 versioni o piu. (fonte: [SBOM: la chiave per la sicurezza software nella supply chain](/it/blog/sbom-cos-e-il-software-bill-of-materials/))
[^6]: I formati standardizzati piu comuni per documentare uno SBOM sono CycloneDX e SPDX. (fonte: [SBOM: la chiave per la sicurezza software nella supply chain](/it/blog/sbom-cos-e-il-software-bill-of-materials/))
[^7]: **BOM-Link**, BOM-Link is a formally registered URN (urn:cdx) in the CycloneDX standard that enables deep-linking to reference components, services, or vulnerabilities across different Bill of Materials (BOMs). (fonte: )
[^8]: **CISA**, The Cybersecurity and Infrastructure Security Agency (CISA) is the U.S. cyber defense agency that publishes official guidance on the Minimum Elements for a Software Bill of Materials (SBOM). (fonte: )
[^9]: **BSI TR-03183**, BSI TR-03183 is a technical guideline by the German Federal Office for Information Security (BSI) helping manufacturers implement the EU Cyber Resilience Act (CRA) requirements, including SBOMs. (fonte: )
[^10]: **Package URL (purl)**, Package URL (purl) is an Ecma standard (ECMA-427) defining a uniform URL-based syntax to reliably identify software packages across ecosystems, widely used in SBOMs and vulnerability databases. (fonte: )
[^11]: **CPE**, Common Platform Enumeration (CPE) is a standardized naming scheme maintained by NIST for identifying information technology systems, software, and hardware classes. (fonte: )
[^12]: **Cosign**, Cosign is a command-line utility from the Sigstore project used to cryptographically sign and verify software artifacts, such as container images and SBOMs, supporting a keyless signing workflow. (fonte: )
[^13]: **Google Artifact Registry**, Google Artifact Registry is a fully-managed Google Cloud service for storing, managing, and securing container images and language packages in private repositories. (fonte: )
[^14]: **Artifact Analysis**, Artifact Analysis is a Google Cloud service providing software composition analysis, vulnerability scanning, and metadata storage, including the generation and management of SBOMs. (fonte: )
[^15]: **Bomctl**, Bomctl is a format-agnostic Software Bill of Materials (SBOM) CLI tool by OpenSSF. It bridges the gap between SBOM generation and analysis by allowing users to fetch, store, and manipulate SBOMs. (fonte: )
[^16]: **GUAC**, GUAC is an open-source tool that aggregates software supply chain metadata, such as SBOMs and vulnerability reports, into a graph database to map relationships and analyze security risks. (fonte: )
[^17]: **A Shared Vision of Software Bill of Materials for Cybersecurity**, A joint guidance document released in September 2025 by CISA, NSA, and 19 international partners, outlining a global consensus on using SBOMs to enhance software supply chain transparency. (fonte: )
[^18]: **OpenSSF**, The Open Source Security Foundation is a cross-industry initiative under the Linux Foundation that brings together developers and organizations to improve open-source software security. (fonte: )
---
## Domande Frequenti
### Serve una SBOM per ogni servizio o una sola per il prodotto?
Entrambe, ma con ruoli diversi. Ogni servizio genera la propria SBOM come artefatto tecnico, mentre l'unità di evidenza richiesta dal CRA è il prodotto immesso sul mercato (Allegato I, Parte II): serve un documento autorevole per versione di prodotto che tenga insieme le SBOM dei servizi. Dieci SBOM di componente scollegate non soddisfano l'obbligo; una root BOM che le referenzia sì.
### Compose (linking) o merge: quale conviene?
Dipende dai cicli di rilascio, non dalla conformità: entrambe sono valide per il CRA. Se il prodotto ha più servizi con release indipendenti, il compose gerarchico è l'unica strategia mantenibile, perché ogni servizio si rigenera da solo e preserva firma e provenienza. Il merge piatto regge solo su prodotti sostanzialmente monolitici, con poche decine di componenti e una cadenza di rilascio unica, o quando il consumatore non sa risolvere riferimenti esterni.
### Devo pubblicare la SBOM o consegnarla ai clienti?
No. La SBOM è documentazione tecnica confidenziale, non materiale pubblico: è una mappa dei componenti utile a un attaccante. Il CRA non impone di pubblicarla; l'unico soggetto che può esigerla è un'autorità di sorveglianza del mercato, su richiesta motivata. Ai clienti business si rilascia sotto NDA, tracciando chi ha ricevuto quale versione.
### Basta la SBOM generata dal registry o dai fornitori?
È un punto di partenza, non l'artefatto finito. Le SBOM prodotte alla push da un registry (es. Artifact Analysis su Google Artifact Registry) hanno retention e cleanup policy non allineate all'obbligo decennale (Articolo 13), quindi vanno archiviate in storage dedicato. Le SBOM dei fornitori sono input da riconciliare: normalizzare gli identificatori, integrare o linkare dopo aver verificato la risolvibilità, documentare i known unknowns. Quindi non sono documenti da inoltrare così come arrivano.
### Il CRA mi obbliga a usare CycloneDX o SPDX?
No, il regolamento chiede un formato "comune e machine-readable" senza prescriverne uno. Ma CycloneDX e SPDX sono gli unici con tooling maturo per il linking gerarchico e le relazioni di dipendenza, quindi sceglierne uno ora è la copertura più sicura contro un futuro formato prescritto dalla Commissione.
---
## Articoli Correlati
- [CRA: automatizzare il monitoraggio nelle pipeline cloud native](https://www.sparkfabrik.com/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/) - Il Cyber Resilience Act trasforma la conformità in un processo continuo integrato nelle pipeline. …
- [AgentOps: governare e monitorare gli agenti AI in produzione](https://www.sparkfabrik.com/it/blog/agentops-governare-e-monitorare-gli-agenti-ai-in-produzione/) - I sistemi basati su modelli probabilistici richiedono un cambio di paradigma rispetto al …
- [Spec driven development: guida per superare il vibe-coding con l'AI](https://www.sparkfabrik.com/it/blog/guida-allo-spec-driven-development/) - Scopri lo spec driven development, il paradigma che trasforma gli LLM in alleati. Impara a guidare …
---
*Questa è una versione in Markdown dell'articolo per facilitare la lettura da parte di AI e crawler.*
*Visita [https://www.sparkfabrik.com/it/blog/orchestrare-sbom-multiple/](https://www.sparkfabrik.com/it/blog/orchestrare-sbom-multiple/) per la versione completa con immagini e formattazione.*