BSI TR-03183: SBOM-kvalitetsnivåer och CRA-efterlevnad

Förordning (EU) 2024/2847 (cyberresiliensförordningen) kräver en Software Bill of Materials men överlåter de tekniska detaljerna till andra. Den kräver en maskinläsbar SBOM som täcker åtminstone produktens beroenden på toppnivå, och där slutar förordningens preciseringar i stort sett. Ingen fältlista. Inget formatversionsgolv. Inget schema för säkerhetsrådgivning. Tysklands federala myndighet för informationssäkerhet (BSI) har fyllt luckan med BSI TR-03183, en teknisk riktlinje i tre delar som anger exakta formatversioner, listar varje obligatoriskt fält och kopplar samman SBOM-generering med publicering av sårbarhetsrådgivning. Behandla den som den praktiska specifikationen under den rättsliga skyldigheten, inte som en konkurrerande förordning.

Vad BSI TR-03183 är

BSI är Tysklands nationella cybersäkerhetsmyndighet. Dess tekniska riktlinje TR-03183 bär den fullständiga titeln Cyber Resilience Requirements for Manufacturers and Products, med separata delar numrerade och versionshanterade oberoende av varandra. Riktlinjen riktar sig till tillverkare som förbereder sig inför EU:s cyberresiliensförordning och översätter skyldigheterna i Bilaga I till konkreta, testbara tekniska krav.

Dokumentets tre delar, med de versioner som gällde vid skrivtillfället:

Del	Version	Publicerad	Omfattning
Part 1	v0.10.0	2025-09-12	Allmänna krav på cyberresiliens under CRA, härledda från Bilaga I, Bilaga II och Bilaga VII
Part 2	v2.1.0	2025-08-20	Software Bill of Materials (SBOM): format, fält, generering och uppdateringar
Part 3	v1.0.0	2025-08-20	Sårbarhetrapporter och -aviseringar, inklusive CVD, security.txt och CSAF-rådgivning

BSI framställer riktlinjen som ett övergångsdokument:

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

Den meningen anger hur du bör förhålla dig till TR-03183. Det är BSI:s tolkning av hur en CRA-kompatibel SBOM och ett sårbarhetsprogram bör se ut medan CEN/CENELEC:s harmoniserade standarder fortfarande är under framtagning. När de väl publiceras tar de harmoniserade standarderna över. Fram till dess är TR-03183 den mest detaljerade offentligt tillgängliga specifikation som är anpassad till CRA:s Bilaga I.

graph LR
    A[BSI TR-03183]
    A --- P1[Del 1
Allmänna krav på
cyberresiliens under CRA]
    A --- P2[Del 2
SBOM]
    A --- P3[Del 3
Sårbarhetsrapporter]
    P2 --- F1[CycloneDX 1.6
eller SPDX 3.0.1]
    P2 --- F2[Obligatoriska, ytterligare
och valfria fält]
    P3 --- C1[CSAF 2.0
säkerhetsmeddelanden]
    P3 --- C2[security.txt
CSAF-tagg]
    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

De CRA-luckor som TR-03183 fyller

Du kan läsa CRA:s SBOM-klausuler från början till slut utan att lära dig vilka fält som hör hemma i ditt dokument, vilken formatversion som uppfyller skyldigheten eller hur du publicerar de resulterande rådgivningarna. TR-03183 fyller tre specifika luckor.

Lucka i CRA-texten	Vad TR-03183 anger
CRA kräver en SBOM men listar inga datafält (Bilaga I del II (1))	TR-03183 räknar upp Required, Additional och Optional fält för både SBOM-dokumentet och varje komponent
CRA anger att format måste vara "allmänt använda och maskinläsbara" utan att namnge några	TR-03183 anger: "CycloneDX, version 1.6 or higher" eller "System Package Data Exchange (SPDX), version 3.0.1 or higher"
CRA kräver rapportering av aktivt utnyttjade sårbarheter till den samordnande CSIRT och ENISA utan att ange ett offentligt rådgivningsformat (Artikel 14)	TR-03183 anpassar rådgivningar till CSAF 2.0 och hänvisar till ISO/IEC 20153:2025

För detaljerna om CRA:s skyldigheter på dessa punkter, se CRA SBOM-krav. För Artikel 14-rapporteringsklockan som gör aktuella komponentdata operativt viktiga, se CRA-rapportering av sårbarheter och incidenter.

Required, Additional och Optional fält

TR-03183 v2.1.0 använder inte orden "Basic", "Standard" eller "Comprehensive". Varje leverantörsdiagram eller sammanfattning som presenterar tre namngivna "kvalitetsnivåer" med dessa beteckningar inför en struktur som specifikationen inte innehåller. Efterlevnadsmodellen i v2.1.0 är binär på fältnivå: ett fält är antingen Required (alltid obligatoriskt), Additional (obligatoriskt när data finns) eller Optional.

De tre fältkategorierna:

Kategori	Vad det innebär	Exempel
Required för SBOM:en i sig	Fält på dokumentnivå som ALLTID måste finnas	Skapare av SBOM:en, tidsstämpel
Required för varje komponent	Fält på komponentnivå som ALLTID måste finnas	Komponentnamn, komponentversion, distributionslicenser, hash (SHA-512), beroenden till andra komponenter, filnamn, egenskapen körbar, egenskapen arkiv, egenskapen strukturerad, komponentens skapare
Additional för varje komponent	Obligatoriskt om data finns, utelämnas annars	URI till källkod, URI till komponentens driftsättbara form, andra unika identifierare (CPE, purl), ursprungliga licenser
Optional för varje komponent	FÅR inkluderas	Effektiv licens, hash för källkoden, URL till security.txt

TR-03183 ställer också ett krav på rekursiv beroendeupplösning: beroenden MÅSTE upplösas för varje komponent som ingår i leveransomfånget, inte bara de omedelbara. Det är specifikationens svar på CRA:s vaga "beroenden på toppnivå" i Bilaga I del II (1): gå igenom hela beroendeträdet.

Fält-för-fält-krav

De kandidatfält de flesta team frågar om, med deras kategori i v2.1.0.

Fält	Kategori	Anmärkningar
Skapare av SBOM:en	Required (SBOM-nivå)	E-post eller URL till producenten
Tidsstämpel	Required (SBOM-nivå)	ISO 8601
Komponentnamn	Required	Alltid ifyllt för varje post
Komponentversion	Required	Exakt version, inte ett intervall
Komponentens skapare	Required	Motsvarar "Supplier" i äldre terminologi
Komponentens filnamn	Required	Saknas ofta i verktygens standardutdata
Beroenden till andra komponenter	Required	Upplöses rekursivt
Distributionslicenser	Required	Licenser i distribuerad form
Hash för den driftsättbara komponenten	Required	SHA-512
Egenskapen körbar	Required	Booleskt: är komponenten körbar?
Egenskapen arkiv	Required	Booleskt: är komponenten ett arkiv?
Egenskapen strukturerad	Required	Booleskt: indikator för strukturerad nyttolast
URI till källkod	Additional	Obligatoriskt när känt
URI till den driftsättbara komponenten	Additional	Obligatoriskt när känt
Andra unika identifierare (CPE, purl)	Additional	Obligatoriskt när tillgängligt; inte villkorslöst obligatoriskt
Ursprungliga licenser	Additional	Uppströmslicens före distribution
Effektiv licens	Optional	Resultat av licensavstämning
Källkodshash	Optional	Hash för källkoden före bygge
URL till security.txt	Optional	Pekare till ingångspunkten för sårbarhetsinformation

Den rad som förvånar flest team är Andra unika identifierare (CPE, purl). Team behandlar paket-URL:er som SBOM:ens primärnyckel. Under TR-03183 v2.1.0 finns purl i kategorin Additional, obligatoriskt bara när data finns. Den villkorslösa komponentidentifieraren är SHA-512-hashen för den driftsättbara artefakten, kombinerad med namn och version. Om dina verktyg inte kan beräkna purl för ett privat internt bibliotek bryter det inte mot efterlevnaden. Om de inte kan beräkna SHA-512-hashen, däremot, gör det det. Se vanliga SBOM-misstag för relaterade fältluckor.

Stöd för CycloneDX och SPDX

TR-03183 anger de godkända formaten och minimiversionerna:

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

Med andra ord kräver specifikationen att ett nytt eller uppdaterat SBOM-dokument ska vara i JSON- eller XML-format och vara en giltig SBOM enligt CycloneDX version 1.6 eller högre.

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

Specifikationen accepterar också SPDX version 3.0.1 eller högre som alternativt format.

Versionshistoriken i v2.1.0 dokumenterar också uppgraderingsvägen: v2.0.0 (2024-09-20) höjde CycloneDX från 1.4 till 1.5 och SPDX från tidigare versioner till 2.2.1. v2.1.0 (2025-08-20) höjde CycloneDX från 1.5 till 1.6 och SPDX från 2.2.1 till 3.0.1.

Den praktiska konsekvensen är att verktyg som som standard producerar CycloneDX 1.4 (fortfarande vanligt i äldre CI-konfigurationer) inte uppfyller kraven under v2.1.0. CycloneDX 1.6 introducerade förfinat stöd för kryptografiska tillgångar och ML BOM; SPDX 3.0.1 är en genomgripande omarbetning med en ny nyttolastmodell. Din CI-baslinje behöver en explicit --spec-version 1.6-flagga eller motsvarande. För en jämförelse av de två formaten och verktygens mognad, se CycloneDX vs SPDX.

Ett TR-03183-anpassat CycloneDX 1.6-skelett med Required-fälten på dokumentnivå ifyllda:

{
  "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"]
    }
  ]
}

Posterna authors, timestamp och SHA-512 hashes är de fält på dokument- och komponentnivå i kategorin Required som oftast saknas i CI-standardkonfigurationer. Validera dem med cyclonedx-cli validate --input-version 1.6 innan du betraktar en utdata som TR-03183-kompatibel.

Hur TR-03183 förhåller sig till CSAF och VEX

TR-03183 täcker mekaniken för SBOM och sårbarhetsrådgivning tillsammans. Huvudregeln är enkel: CSAF rekommenderas för rådgivningar och är operativt obligatoriskt för security.txt-publicering. VEX är aldrig obligatoriskt.

Mekanism	Styrka	Vad det innebär
CSAF 2.0 som rådgivningsformat	Rekommenderat	"The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
security.txt CSAF-tagg	MUST	security.txt-posten som refererar till CSAF-dokument måste börja med taggen CSAF:
URI för leverantörsmetadata	SHOULD	Tillverkaren BÖR ange URI:n för provider-metadata.json för CSAF-dokument
ISO/IEC 20153:2025	Referens	Den internationella standardformen av CSAF v2.0
VEX	Informativt	VEX förekommer som en CSAF-profil och som en av flera "bör"-kanaler för sårbarhetsinformation

CSAF (Common Security Advisory Framework) version 2.0 är en OASIS-standard publicerad 18 november 2022. Den definierar ett JSON-schema för maskinläsbar säkerhetsrådgivning. Tyska CERT:er (BSI-CERT, CERT-Bund) publicerar och konsumerar CSAF som standard, och Secvisogram-redigeraren samt OASIS CSAF-valideraren är standardverktygen.

Kopplingen till Artikel 14 är mer subtil än en del kommentarer antyder. CRA:s Article 14 fastställer rapporteringsfrister till ENISA och den samordnande CSIRT (24 timmar för den tidiga varningen, 72 timmar för aviseringen och en slutrapport 14 dagar efter att en åtgärd finns tillgänglig för en aktivt utnyttjad sårbarhet, eller en månad efter aviseringen för en allvarlig incident). Den anger inget offentligt rådgivningsformat. TR-03183 fyller den luckan: när du väl har aviserat ENISA är det CSAF-dokumentet du publicerar under din security.txt som är den operativa artefakt som kunderna tar emot. Utan CSAF-verktyg på plats före 11 september 2026 kan du fortfarande uppfylla Article 14, men du uppfyller inte den upphandlingsterminologi och de security.txt-förväntningar som följer av TR-03183.

VEX förtjänar en separat kommentar. TR-03183 nämner VEX endast som en CSAF-profil och som en möjlig kanal för utbyte av sårbarhetsinformation; det är aldrig obligatoriskt. Ur ett CRA-perspektiv är VEX användbart för not_affected-uttalanden på komponentnivå som förebygger larmtrötthet när en SBOM innehåller ett bibliotek med ett känt CVE som faktiskt inte är nåbart från din kod. Det är inte en TR-03183-skyldighet. Använd det där det tillför värde.

Gäller TR-03183 utanför Tyskland?

TR-03183 är en tysk nationell teknisk riktlinje utfärdad av BSI, inte en EU-omfattande förordning, och den hävdar inte tillämpbarhet utanför Tyskland.

I praktiken finns det tre faktorer som gör TR-03183 relevant för tillverkare utanför Tyskland.

För det första är den tyska marknaden EU:s största, och tysk företagsupphandling refererar i allt högre grad till TR-03183 explicit. Säljer du till en tysk kund bör du förvänta dig TR-03183-formuleringar i deras säkerhetsfrågeformulär och leverantörsavtal.

För det andra finns det ingen annan CRA-anpassad specifikation med jämförbar detaljeringsnivå i dag, så tillverkare tar TR-03183 som den praktiska referensen.

För det tredje är TR-03183 byggd kring samma CRA-annex som du ändå måste uppfylla: Bilaga I, Bilaga II och Bilaga VII. Dokumentation som förbereds enligt TR-03183 producerar det tekniska underlag som en EU-marknadskontrollmyndighet förväntar sig i din Annex VII-fil, SBOM:en inkluderad. Vår guide om teknisk dokumentation listar allt som Annex VII måste innehålla.

Att frivilligt tillämpa TR-03183 är ett försvarbart tekniskt val men inte ett rättsligt krav utanför Tyskland. Om dina produkter inte inkluderar en hårdvarukomponent är det hela historien. Om de gör det kan samma dokument innehålla dina HBOM-poster vid sidan av programvarukomponenterna.

Vad du bör göra härnäst