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. Bilaga I, del II, punkt (1) 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

Part 1 §1 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
Bilaga I, del II, punkt (1) kräver en SBOM men listar inga datafält	Part 2 §5.2 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	Part 2 §4 anger: "CycloneDX, version 1.6 or higher" eller "System Package Data Exchange (SPDX), version 3.0.1 or higher"
Artikel 14 kräver rapportering av aktivt utnyttjade sårbarheter till ENISA utan att ange ett offentligt rådgivningsformat	Part 3 §4.2.8 och §5.1.6 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 den tidsfrister- och påföljdskontext som motiverar brådskan, se SBOM-efterlevnadsfrister och påföljder.

Required, Additional och Optional fält i Part 2

Part 2 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 kategorierna, mappade mot spec-avsnitt:

Kategori	Spec-avsnitt	Vad det innebär	Exempel
Required för SBOM:en i sig	§5.2.1	Fält på dokumentnivå som ALLTID måste finnas	Skapare av SBOM:en, tidsstämpel
Required för varje komponent	§5.2.2	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	§5.2.4	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	§5.2.5	FÅR inkluderas	Effektiv licens, hash för källkoden, URL till security.txt

Part 2 ställer också ett krav på rekursiv upplösning i §5.1: beroendeupplösning MÅSTE utföras för varje komponent som ingår i leveransomfånget. Det är specifikationens svar på CRA:s vaga "beroenden på toppnivå" i Bilaga I, del II, punkt (1): TR-03183 förväntar sig att du går igenom hela beroendeträdet, inte stannar vid de omedelbara beroendena.

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

Fullständig mappning av de kandidatfält de flesta team frågar om, mot v2.1.0:s spec-avsnitt.

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

Part 2 §4 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 fördelar mekaniken för SBOM och sårbarhetsrådgivning över Part 2 och Part 3. Huvudregeln är enkel: CSAF rekommenderas i Part 2 och är operativt obligatoriskt för security.txt-publicering i Part 3. VEX är aldrig obligatoriskt.

Mekanism	TR-03183-plats	Styrka	Vad det innebär
CSAF 2.0 som rådgivningsformat	Part 2 §8.1.14	Rekommenderat	"The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
security.txt CSAF-tagg	Part 3 §4.2.8 (b)	MUST	security.txt-posten som refererar till CSAF-dokument måste börja med taggen CSAF:
URI för leverantörsmetadata	Part 3 §4.2.8 (a)	SHOULD	Tillverkaren BÖR ange URI:n för provider-metadata.json för CSAF-dokument
ISO/IEC 20153:2025	Part 3 §5.1.6	Referens	Den internationella standardformen av CSAF v2.0
VEX	Part 2 §1 och §8.1.14	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, med Errata 01 utfärdad 26 januari 2024. 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 Artikel 14 fastställer rapporteringsfrister till ENISA och den samordnande CSIRT (24 timmar för den tidiga varningen, 72 timmar för sårbarhetsaviseringen och 14 dagar för slutrapporten). Den anger inget offentligt rådgivningsformat. TR-03183 Part 3 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 Artikel 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. Part 2 §8.1.14 nämner VEX som en CSAF-profil, och Part 2 §1 nämner det som en möjlig kanal för "utbyte av sårbarhetsinformation". Part 3 nämner inte VEX alls. 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. Ingen av dess tre delar hävdar tillämpbarhet utanför Tyskland. Part 1 §1 förutser uttryckligen att riktlinjen kommer att ersättas av CEN/CENELEC:s harmoniserade standarder när dessa publiceras under CRA-standardiseringsuppdraget.

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 alternativ CRA-anpassad specifikation med jämförbar detaljeringsnivå vid skrivtillfället. CEN/CENELEC:s harmoniserade standarder under CRA-standardiseringsuppdraget är fortfarande under framtagning. TR-03183 är den närmaste tillgängliga proxyn.

För det tredje mappar Part 1 av TR-03183 explicit mot CRA:s Bilaga I, Bilaga II och Bilaga VII. En tillverkare som bygger dokumentation utifrån TR-03183 producerar Bilaga VII-innehåll (punkt 2(b) och punkt 8 med SBOM:ar i synnerhet) som vilken EU-marknadskontrollmyndighet som helst kan läsa. Se Bilaga VII teknisk dokumentation för den fullständiga innehållslistan.

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