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. 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

Il BSI 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
Il CRA richiede uno SBOM ma non elenca campi dati (Allegato I parte II (1))	TR-03183 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	TR-03183 li nomina: «CycloneDX, versione 1.6 o superiore» o «System Package Data Exchange (SPDX), versione 3.0.1 o superiore»
Il CRA richiede la segnalazione delle vulnerabilità attivamente sfruttate al CSIRT coordinatore e a ENISA senza specificare un formato pubblico per le advisory (Articolo 14)	TR-03183 allinea le advisory a CSAF 2.0 e fa 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 l'orologio di segnalazione dell'Articolo 14 che rende operativi i dati aggiornati sui componenti, si consulti segnalazione di vulnerabilità e incidenti CRA.

Campi Required, Additional e Optional

La versione v2.1.0 di TR-03183 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 di campi:

Categoria	Significato	Esempi
Required per lo SBOM stesso	Campi a livello di documento che DEVONO essere sempre presenti	Creatore dello SBOM, Timestamp
Required per ogni componente	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	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	POSSONO essere inclusi	Licenza effettiva, Hash del codice sorgente, URL del file security.txt

TR-03183 impone anche la risoluzione ricorsiva delle dipendenze: la risoluzione va eseguita per ogni componente incluso nell’ambito della fornitura, non solo per le dipendenze immediate. Questa è la sua risposta al vago limite delle «dipendenze di primo livello» previsto dall’Allegato I parte II (1) del CRA: percorrere l’intero albero delle dipendenze.

Requisiti campo per campo

I campi candidati che la maggior parte dei team richiede, con la rispettiva categoria nella v2.1.0.

Campo	Categoria	Note
Creatore dello SBOM	Required (a livello SBOM)	Email o URL del produttore
Timestamp	Required (a livello SBOM)	ISO 8601
Nome del componente	Required	Sempre presente per ogni voce
Versione del componente	Required	Versione esatta, non un intervallo
Creatore del componente	Required	Corrisponde a «Supplier» nel linguaggio precedente
Nome file del componente	Required	Spesso assente nell’output predefinito degli strumenti
Dipendenze da altri componenti	Required	Risolte ricorsivamente
Licenze di distribuzione	Required	Licenze nella forma distribuita
Hash del componente distribuibile	Required	SHA-512
Proprietà executable	Required	Booleano: il componente è eseguibile?
Proprietà archive	Required	Booleano: il componente è un archivio?
Proprietà structured	Required	Booleano: indicatore di payload strutturato
URI del codice sorgente	Additional	Obbligatorio se noto
URI del componente distribuibile	Additional	Obbligatorio se noto
Altri identificatori univoci (CPE, purl)	Additional	Obbligatori se disponibili; non incondizionatamente richiesti
Licenze originali	Additional	Licenza upstream prima della distribuzione
Licenza effettiva	Optional	Risultato della riconciliazione delle licenze
Hash del codice sorgente	Optional	Hash del sorgente prima della compilazione
URL di security.txt	Optional	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. In TR-03183 v2.1.0, 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

TR-03183 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 tratta insieme le funzionalità di SBOM e advisory sulle vulnerabilità. La regola principale è semplice: CSAF è raccomandato per le advisory ed è operativamente richiesto per la pubblicazione in security.txt. VEX non è mai imposto.

Meccanismo	Forza	Significato
CSAF 2.0 come formato di advisory	Raccomandato	«The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)»
Tag CSAF in security.txt	DEVE	Il riferimento a documenti CSAF in security.txt deve iniziare con il tag CSAF:
URI dei metadati del provider	DOVREBBE	Il fabbricante DOVREBBE fornire l’URI di provider-metadata.json per i documenti CSAF
ISO/IEC 20153:2025	Riferimento	La forma internazionale standardizzata di CSAF v2.0
VEX	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’Article 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. 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’Article 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. TR-03183 menziona VEX solo come profilo CSAF e come uno dei possibili canali per lo scambio di informazioni sulle vulnerabilità; non è mai obbligatorio. 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, e non afferma applicabilità al di fuori della Germania.

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 non esiste una specifica alternativa allineata al CRA con un livello di dettaglio comparabile, quindi i fabbricanti ricorrono a TR-03183 come riferimento pratico.

In terzo luogo, TR-03183 è costruito attorno agli stessi allegati del CRA che si devono comunque soddisfare: Allegato I, Allegato II e Allegato VII. La documentazione preparata secondo TR-03183 produce le prove tecniche che un’autorità di vigilanza del mercato dell’UE si aspetta nel fascicolo dell’Annex VII, SBOM incluso. Si consulti la documentazione tecnica per l’elenco completo dei contenuti dell’Annex VII.

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.