BSI TR-03183: livelli di qualità SBOM e conformità CRA

Il Regolamento sulla ciberresilienza (CRA) impone un Software Bill of Materials, ma delega i dettagli tecnici ad altri strumenti. L’Allegato I, Parte II, punto (1) richiede uno SBOM leggibile automaticamente che copra almeno le dipendenze di primo livello del prodotto, e qui la specificità del Regolamento si esaurisce. Nessun elenco di campi. Nessuna versione minima di formato. Nessuno schema per le advisory. L’Ufficio federale tedesco per la sicurezza informatica (BSI) ha colmato questa lacuna con BSI TR-03183, una linea guida tecnica in tre parti che indica versioni esatte di formato, elenca ogni campo obbligatorio e collega la generazione degli SBOM alla pubblicazione delle advisory sulle vulnerabilità. La si consideri come la specifica pratica alla base dell’obbligo normativo, non una norma concorrente.

Che cos’è BSI TR-03183

BSI è l’agenzia nazionale tedesca per la cibersicurezza. La sua Linea guida tecnica TR-03183 porta il titolo completo Cyber Resilience Requirements for Manufacturers and Products, con parti numerate e versionate in modo indipendente. La linea guida è rivolta ai fabbricanti che si preparano al Regolamento sulla ciberresilienza dell’UE, traducendo gli obblighi dell’Allegato I del CRA in requisiti tecnici concreti e verificabili.

Le tre parti del documento, con le versioni correnti al momento della redazione:

Parte	Versione	Pubblicazione	Ambito
Parte 1	v0.10.0	12 settembre 2025	Requisiti generali di ciberresilienza derivanti dal CRA, dall’Allegato I, dall’Allegato II e dall’Allegato VII
Parte 2	v2.1.0	20 agosto 2025	Software Bill of Materials (SBOM): formati, campi, generazione e aggiornamenti
Parte 3	v1.0.0	20 agosto 2025	Segnalazioni e notifiche di vulnerabilità, inclusi CVD, security.txt e advisory CSAF

La Parte 1 §1 inquadra la linea guida come strumento transitorio:

"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."

Questa linea guida sarà sostituita nella forma attuale non appena i suoi contenuti saranno coperti dai risultati di normalizzazione corrispondenti previsti dalla richiesta di normalizzazione citata.

Questa affermazione orienta il modo in cui si dovrebbe considerare TR-03183. Rappresenta la lettura del BSI di come dovrebbero essere strutturati un programma SBOM e di gestione delle vulnerabilità conformi al CRA, mentre gli standard armonizzati CEN/CENELEC sono ancora in fase di elaborazione. Quando questi saranno pubblicati, gli standard armonizzati prevarranno; fino ad allora, TR-03183 è la specifica pubblica più dettagliata allineata all’Allegato I del CRA.

graph LR
    A[BSI TR-03183]
    A --- P1[Parte 1
Requisiti generali
di ciberresilienza]
    A --- P2[Parte 2
SBOM]
    A --- P3[Parte 3
Segnalazioni di
vulnerabilità]
    P2 --- F1[CycloneDX 1.6
o SPDX 3.0.1]
    P2 --- F2[Campi obbligatori, aggiuntivi
e opzionali]
    P3 --- C1[CSAF 2.0
avvisi]
    P3 --- C2[security.txt
tag CSAF]
    style A fill:#008080,stroke:#005f5f,color:#fff
    style P1 fill:#e8f4f8,stroke:#008080,color:#333
    style P2 fill:#e8f4f8,stroke:#008080,color:#333
    style P3 fill:#e8f4f8,stroke:#008080,color:#333
    style F1 fill:#f8fafc,stroke:#008080,color:#333
    style F2 fill:#f8fafc,stroke:#008080,color:#333
    style C1 fill:#f8fafc,stroke:#008080,color:#333
    style C2 fill:#f8fafc,stroke:#008080,color:#333

Le lacune del CRA che TR-03183 colma

Si può leggere il CRA dall’inizio alla fine senza scoprire quali campi devono figurare nel documento, quale versione di formato soddisfa l’obbligo, o come pubblicare le advisory risultanti. TR-03183 colma tre lacune specifiche.

Lacuna nel testo del CRA	Cosa specifica TR-03183
L’Allegato I, Parte II, punto (1) richiede uno SBOM ma non elenca campi dati	La Parte 2 §5.2 enumera i campi Required, Additional e Optional sia per il documento SBOM che per ogni componente
Il CRA indica che i formati devono essere «comunemente usati e leggibili automaticamente» senza nominarne alcuno	La Parte 2 §4 stabilisce: «CycloneDX, versione 1.6 o superiore» o «System Package Data Exchange (SPDX), versione 3.0.1 o superiore»
L’Articolo 14 richiede la segnalazione delle vulnerabilità attivamente sfruttate a ENISA senza specificare un formato pubblico per le advisory	La Parte 3 §4.2.8 e §5.1.6 allineano le advisory a CSAF 2.0 e fanno riferimento alla norma ISO/IEC 20153:2025

Per il dettaglio degli obblighi del CRA relativi a questi aspetti, si consulti Requisiti SBOM del CRA. Per il contesto delle scadenze e delle sanzioni che ne determina l’urgenza, si consulti Scadenze e sanzioni per la conformità SBOM.

Campi Required, Additional e Optional nella Parte 2

La versione v2.1.0 della Parte 2 non utilizza le parole «Basic», «Standard» o «Comprehensive». Qualsiasi diagramma o sintesi di un fornitore che presenti tre «livelli di qualità» con queste denominazioni introduce una struttura che la specifica non contiene. Il modello di conformità della v2.1.0 è binario a livello di campo: un campo è Required (sempre presente), Additional (obbligatorio quando i dati esistono) o Optional.

Le tre categorie, mappate alle sezioni della specifica:

Categoria	Sezione della specifica	Significato	Esempi
Required per lo SBOM stesso	§5.2.1	Campi a livello di documento che DEVONO essere sempre presenti	Creatore dello SBOM, Timestamp
Required per ogni componente	§5.2.2	Campi a livello di componente che DEVONO essere sempre presenti	Nome del componente, Versione del componente, Licenze di distribuzione, Hash (SHA-512), Dipendenze da altri componenti, Nome file, Proprietà executable, Proprietà archive, Proprietà structured, Creatore del componente
Additional per ogni componente	§5.2.4	Obbligatori se i dati esistono, omessi altrimenti	URI del codice sorgente, URI della forma distribuibile del componente, Altri identificatori univoci (CPE, purl), Licenze originali
Optional per ogni componente	§5.2.5	POSSONO essere inclusi	Licenza effettiva, Hash del codice sorgente, URL del file security.txt

La Parte 2 impone anche un requisito di risoluzione ricorsiva alla §5.1: la risoluzione delle dipendenze DEVE essere eseguita per ogni componente incluso nell’ambito della fornitura. Questa è la risposta della specifica al vago limite delle «dipendenze di primo livello» previsto dall’Allegato I, Parte II, punto (1) del CRA: TR-03183 richiede di percorrere l’intero albero delle dipendenze, non di fermarsi alle dipendenze immediate.

Requisiti campo per campo

La mappatura completa dei campi candidati che la maggior parte dei team richiede, rispetto alle sezioni della specifica v2.1.0.

Campo	Categoria	Sezione specifica	Note
Creatore dello SBOM	Required (a livello SBOM)	§5.2.1	Email o URL del produttore
Timestamp	Required (a livello SBOM)	§5.2.1	ISO 8601
Nome del componente	Required	§5.2.2	Sempre presente per ogni voce
Versione del componente	Required	§5.2.2	Versione esatta, non un intervallo
Creatore del componente	Required	§5.2.2	Corrisponde a «Supplier» nel linguaggio precedente
Nome file del componente	Required	§5.2.2	Spesso assente nell’output predefinito degli strumenti
Dipendenze da altri componenti	Required	§5.2.2	Ricorsive ai sensi della §5.1
Licenze di distribuzione	Required	§5.2.2	Licenze nella forma distribuita
Hash del componente distribuibile	Required	§5.2.2	SHA-512
Proprietà executable	Required	§5.2.2	Booleano: il componente è eseguibile?
Proprietà archive	Required	§5.2.2	Booleano: il componente è un archivio?
Proprietà structured	Required	§5.2.2	Booleano: indicatore di payload strutturato
URI del codice sorgente	Additional	§5.2.4	Obbligatorio se noto
URI del componente distribuibile	Additional	§5.2.4	Obbligatorio se noto
Altri identificatori univoci (CPE, purl)	Additional	§5.2.4	Obbligatori se disponibili; non incondizionatamente richiesti
Licenze originali	Additional	§5.2.4	Licenza upstream prima della distribuzione
Licenza effettiva	Optional	§5.2.5	Risultato della riconciliazione delle licenze
Hash del codice sorgente	Optional	§5.2.5	Hash del sorgente prima della compilazione
URL di security.txt	Optional	§5.2.5	Puntatore al punto di accesso per la divulgazione delle vulnerabilità

La riga che sorprende maggiormente molti team è quella degli altri identificatori univoci (CPE, purl). I team trattano gli URL di pacchetto come chiave primaria di uno SBOM. Nella Parte 2 v2.1.0 di TR-03183, il purl ricade nella categoria Additional, obbligatorio solo quando i dati esistono. L’identificatore di componente incondizionato è l’hash SHA-512 dell’artefatto distribuibile, abbinato a nome e versione. Se gli strumenti utilizzati non riescono a calcolare il purl per una libreria interna privata, la conformità non viene compromessa. Se non riescono a calcolare l’hash SHA-512, sì. Si consulti Errori comuni negli SBOM per le lacune relative ai campi.

Supporto CycloneDX e SPDX

La Parte 2 §4 indica i formati accettati e le versioni minime:

"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"

Uno SBOM generato o aggiornato DEVE essere in formato JSON o XML e deve essere uno SBOM valido in base a una delle seguenti specifiche nelle versioni indicate: CycloneDX, versione 1.6 o superiore.

"System Package Data Exchange (SPDX), version 3.0.1 or higher"

System Package Data Exchange (SPDX), versione 3.0.1 o superiore.

Le note di rilascio della v2.1.0 documentano anche il percorso di aggiornamento: la v2.0.0 (20 settembre 2024) ha portato CycloneDX dalla versione 1.4 alla 1.5 e SPDX da versioni precedenti alla 2.2.1. La v2.1.0 (20 agosto 2025) ha portato CycloneDX dalla 1.5 alla 1.6 e SPDX dalla 2.2.1 alla 3.0.1.

L’implicazione pratica è che gli strumenti che producono output CycloneDX 1.4 per impostazione predefinita (ancora comuni in configurazioni CI datate) non sono conformi alla v2.1.0. CycloneDX 1.6 ha introdotto un supporto più raffinato per asset crittografici e ML BOM; la versione 3.0.1 di SPDX è una rivisitazione importante con un nuovo modello di payload. La configurazione CI richiede un flag esplicito --spec-version 1.6 o equivalente. Per un confronto tra i due formati e la maturità degli strumenti disponibili, si consulti CycloneDX vs SPDX.

Un esempio di struttura CycloneDX 1.6 allineata a TR-03183, con i campi Required a livello di documento compilati:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2027-01-15T10:00:00Z",
    "tools": [
      { "vendor": "Example", "name": "syft", "version": "1.10.0" }
    ],
    "authors": [
      { "name": "Example GmbH security team", "email": "security@example.de" }
    ],
    "component": {
      "type": "firmware",
      "name": "SmartSensor Pro",
      "version": "2.4.1",
      "supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
      "purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-512", "content": "ddaf35a193617aba..." }
      ],
      "supplier": { "name": "OpenSSL Software Foundation" },
      "properties": [
        { "name": "executable", "value": "true" },
        { "name": "archive", "value": "false" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
      "dependsOn": ["pkg:generic/openssl@3.0.12"]
    }
  ]
}

Le voci authors, timestamp e hashes SHA-512 sono i campi Required a livello di documento e di componente che più spesso mancano nelle configurazioni CI predefinite. Prima di considerare un output conforme a TR-03183, lo si validi con cyclonedx-cli validate --input-version 1.6.

TR-03183, CSAF e VEX

TR-03183 separa le funzionalità di SBOM e advisory sulle vulnerabilità tra la Parte 2 e la Parte 3. La regola principale è semplice: CSAF è raccomandato nella Parte 2 ed è operativamente richiesto per la pubblicazione in security.txt nella Parte 3. VEX non è mai imposto.

Meccanismo	Posizione in TR-03183	Forza	Significato
CSAF 2.0 come formato di advisory	Parte 2 §8.1.14	Raccomandato	«The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)»
Tag CSAF in security.txt	Parte 3 §4.2.8 (b)	DEVE	Il riferimento a documenti CSAF in security.txt deve iniziare con il tag CSAF:
URI dei metadati del provider	Parte 3 §4.2.8 (a)	DOVREBBE	Il fabbricante DOVREBBE fornire l’URI di provider-metadata.json per i documenti CSAF
ISO/IEC 20153:2025	Parte 3 §5.1.6	Riferimento	La forma internazionale standardizzata di CSAF v2.0
VEX	Parte 2 §1 e §8.1.14	Informativo	VEX compare come profilo CSAF e come uno dei possibili canali «should» per le informazioni sulle vulnerabilità

CSAF (Common Security Advisory Framework) versione 2.0 è uno standard OASIS pubblicato il 18 novembre 2022, con Errata 01 rilasciata il 26 gennaio 2024. Definisce uno schema JSON per le advisory di sicurezza leggibili automaticamente. I CERT tedeschi (BSI-CERT, CERT-Bund) pubblicano e consumano CSAF per impostazione predefinita; l’editor Secvisogram e il validatore OASIS CSAF sono gli strumenti standard.

Il collegamento con l’Articolo 14 è più sfumato di quanto alcune analisi lascino intendere. L’Articolo 14 del CRA stabilisce le scadenze per la segnalazione a ENISA e al CSIRT coordinatore (24 ore per l’avviso preliminare, 72 ore per la notifica della vulnerabilità, 14 giorni per il rapporto finale). Non specifica un formato pubblico per le advisory. La Parte 3 di TR-03183 colma questa lacuna: dopo aver notificato ENISA, il documento CSAF pubblicato tramite il file security.txt è l’artefatto operativo che i clienti acquisiscono. Senza una pipeline per le advisory CSAF attiva prima dell'11 settembre 2026, si può ancora soddisfare l’Articolo 14, ma non le aspettative relative ai contratti di fornitura e al security.txt che derivano da TR-03183.

Una nota a parte su VEX. La Parte 2 §8.1.14 cita VEX come profilo CSAF, e la Parte 2 §1 lo menziona come possibile canale per «lo scambio di informazioni sulle vulnerabilità». La Parte 3 non menziona VEX. Dal punto di vista del CRA, VEX è utile per dichiarazioni not_affected a livello di componente che evitano il rumore di allarme quando uno SBOM contiene una libreria con una CVE nota che non è effettivamente raggiungibile dal proprio codice. Non è un obbligo TR-03183. Lo si utilizzi dove aggiunge chiarezza.

TR-03183 si applica al di fuori della Germania?

TR-03183 è una linea guida tecnica nazionale tedesca emessa dal BSI, non un regolamento a livello UE. Nessuna delle tre parti afferma applicabilità al di fuori della Germania. La Parte 1 §1 anticipa esplicitamente di essere sostituita dagli standard armonizzati CEN/CENELEC, man mano che questi vengono pubblicati nell’ambito della richiesta di normalizzazione del CRA.

In pratica, tre fattori rendono TR-03183 rilevante per i fabbricanti con sede al di fuori della Germania.

In primo luogo, il mercato tedesco è il più grande dell’UE e gli acquisti delle imprese tedesche fanno sempre più riferimento esplicito a TR-03183. Se si vende a un cliente tedesco, ci si aspetti linguaggio relativo a TR-03183 nei questionari di sicurezza e nei contratti di fornitura.

In secondo luogo, al momento della redazione non esiste una specifica alternativa allineata al CRA con un livello di dettaglio comparabile. Gli standard armonizzati CEN/CENELEC nell’ambito della richiesta di normalizzazione del CRA sono ancora in fase di elaborazione. TR-03183 è il riferimento più vicino disponibile.

In terzo luogo, la Parte 1 di TR-03183 mappa esplicitamente sull’Allegato I, sull’Allegato II e sull’Allegato VII del CRA. Un fabbricante che costruisce la documentazione rispetto a TR-03183 produrrà contenuti dell’Allegato VII (in particolare gli SBOM ai punti 2(b) e 8) che qualsiasi autorità di vigilanza del mercato dell’UE può esaminare. Si consulti Documentazione tecnica dell’Allegato VII per l’elenco completo dei contenuti.

Adottare TR-03183 volontariamente è una scelta ingegneristica difendibile, ma non un requisito legale al di fuori della Germania. Se i propri prodotti non includono un componente hardware, la questione si chiude qui. Se lo includono, lo stesso documento può contenere le voci HBOM accanto ai componenti software.