BSI TR-03183: SBOM-kwaliteitsniveaus en CRA-compliance

De Cyberweerbaarheidsverordening verplicht een Software Bill of Materials, maar laat de technische uitwerking aan anderen over. Het vereist een machineleesbare SBOM die ten minste de directe afhankelijkheden van het product bestrijkt, en daarmee eindigt de specificiteit van de verordening. Geen veldlijst, geen minimum formaatversie, geen adviesschema. Het Duitse Federale Bureau voor Informatiebeveiliging (BSI) heeft de lacune opgevuld met BSI TR-03183, een driedelige technische richtlijn die exacte formaatversies benoemt, alle verplichte velden opsomt en de SBOM-generatie koppelt aan de publicatie van kwetsbaarheidsadviezen. Beschouw het als de praktische specificatie onder de wettelijke verplichting, niet als een concurrerende verordening.

Wat BSI TR-03183 is

Het BSI is het nationale cyberbeveiligingsagentschap van Duitsland. Zijn Technische Richtlijn TR-03183 draagt de volledige titel Cyber Resilience Requirements for Manufacturers and Products, met afzonderlijke delen die onafhankelijk genummerd en versiebeheerd worden. De richtlijn richt zich op fabrikanten die zich voorbereiden op de EU-Cyberweerbaarheidsverordening en vertaalt de verplichtingen uit Bijlage I van de CRA naar concrete, toetsbare technische vereisten.

De drie delen van het document, met de versies die geldig waren ten tijde van het schrijven:

Deel	Versie	Gepubliceerd	Reikwijdte
Deel 1	v0.10.0	12 september 2025	Algemene CRA-cyberweerbaarheidsvereisten, afgeleid van Bijlage I, Bijlage II en Bijlage VII
Deel 2	v2.1.0	20 augustus 2025	Software Bill of Materials (SBOM): formaten, velden, generatie en updates
Deel 3	v1.0.0	20 augustus 2025	Kwetsbaarheidsrapporten en -meldingen, inclusief CVD, security.txt en CSAF-advisories

Het BSI positioneert de richtlijn als een tijdelijk instrument:

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

Dit betekent dat de richtlijn het BSI-perspectief vertegenwoordigt op hoe een CRA-conforme SBOM en een kwetsbaarheidsprogramma eruit moeten zien, zolang de geharmoniseerde CEN/CENELEC-normen nog in concept zijn. Zodra die normen worden gepubliceerd, hebben zij voorrang. Tot die tijd is TR-03183 de meest gedetailleerde publiek beschikbare specificatie die is afgestemd op Bijlage I van de CRA.

graph LR
    A[BSI TR-03183]
    A --- P1[Deel 1
Algemene CRA-
cyberweerbaarheidsvereisten]
    A --- P2[Deel 2
SBOM]
    A --- P3[Deel 3
Kwetsbaarheidsmeldingen]
    P2 --- F1[CycloneDX 1.6
of SPDX 3.0.1]
    P2 --- F2[Vereiste, aanvullende
en optionele velden]
    P3 --- C1[CSAF 2.0
adviezen]
    P3 --- C2[security.txt
CSAF-tag]
    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-lacunes die TR-03183 opvult

U kunt de SBOM-bepalingen van de CRA van begin tot eind lezen zonder te weten welke velden uw document moet bevatten, welke formaatversie aan de verplichting voldoet of hoe u de resulterende advisories publiceert. TR-03183 vult drie specifieke lacunes.

Lacune in de CRA-tekst	Wat TR-03183 specificeert
De CRA vereist een SBOM maar noemt geen datavelden (Bijlage I deel II (1))	TR-03183 somt Required-, Additional- en Optional-velden op voor zowel het SBOM-document als elk onderdeel
De CRA stelt dat formaten "gangbaar en machineleesbaar" moeten zijn zonder er een te noemen	TR-03183 benoemt ze: "CycloneDX, version 1.6 or higher" of "System Package Data Exchange (SPDX), version 3.0.1 or higher"
De CRA vereist melding van actief misbruikte kwetsbaarheden aan het coördinerend CSIRT en ENISA, zonder een publiek adviesformaat te specificeren (Artikel 14)	TR-03183 richt advisories op CSAF 2.0 en verwijst naar ISO/IEC 20153:2025

Zie voor de CRA-kant van die verplichtingen CRA SBOM-vereisten. Voor de Artikel 14-meldingsklok die actuele componentgegevens operationeel belangrijk maakt, zie CRA-kwetsbaarheids- en incidentmelding.

Required-, Additional- en Optional-velden

TR-03183 v2.1.0 gebruikt de woorden "Basic", "Standard" en "Comprehensive" niet. Elk leverancierdiagram of elke samenvatting die drie benoemde "kwaliteitsniveaus" met die labels presenteert, introduceert een structuur die de specificatie niet bevat. Het conformiteitsmodel in v2.1.0 is binair op veldniveau: een veld is Required (altijd aanwezig), Additional (verplicht als de data bestaat) of Optional.

De drie veldcategorieën:

Categorie	Betekenis	Voorbeelden
Required voor de SBOM zelf	Velden op documentniveau die ALTIJD aanwezig moeten zijn	Maker van de SBOM, tijdstempel
Required voor elk onderdeel	Velden op onderdeelniveau die ALTIJD aanwezig moeten zijn	Onderdeelnaam, onderdeelversie, distributiebeheer, hash (SHA-512), afhankelijkheden van andere onderdelen, bestandsnaam, uitvoerbare eigenschap, archiefeergenschap, gestructureerde eigenschap, maker van het onderdeel
Additional voor elk onderdeel	Verplicht als de data bestaat, anders weglaten	URI van de broncode, URI van de inzetbare vorm van het onderdeel, andere unieke identificatoren (CPE, purl), originele licenties
Optional voor elk onderdeel	MAG worden opgenomen	Effectieve licentie, hashwaarde van de broncode, URL van de security.txt

TR-03183 vereist ook recursieve afhankelijkheidsresolutie: afhankelijkheden worden opgelost voor elk onderdeel dat valt binnen de reikwijdte van de levering, niet alleen de directe. Dat is het antwoord van de specificatie op de vage "directe afhankelijkheden"-ondergrens van de CRA in Bijlage I deel II (1): doorloop de volledige afhankelijkheidsboom.

Veld-voor-veld vereisten

De velden waar de meeste teams naar vragen, met hun v2.1.0-categorie.

Veld	Categorie	Toelichting
Maker van de SBOM	Required (SBOM-niveau)	E-mail of URL van de producent
Tijdstempel	Required (SBOM-niveau)	ISO 8601
Onderdeelnaam	Required	Altijd ingevuld voor elk onderdeel
Onderdeelversie	Required	Exacte versie, geen bereik
Maker van het onderdeel	Required	Komt overeen met "Supplier" in oudere terminologie
Bestandsnaam van het onderdeel	Required	Vaak afwezig in standaard tool-uitvoer
Afhankelijkheden van andere onderdelen	Required	Recursief opgelost
Distributiebeheer	Required	Licenties zoals gedistribueerd
Hash van het inzetbare onderdeel	Required	SHA-512
Uitvoerbare eigenschap	Required	Boolean: is het onderdeel uitvoerbaar?
Archiefeergenschap	Required	Boolean: is het onderdeel een archief?
Gestructureerde eigenschap	Required	Boolean: indicator voor gestructureerde payload
URI van de broncode	Additional	Verplicht als bekend
URI van het inzetbare onderdeel	Additional	Verplicht als bekend
Andere unieke identificatoren (CPE, purl)	Additional	Verplicht als beschikbaar; niet onvoorwaardelijk vereist
Originele licenties	Additional	Upstream-licentie vóór distributie
Effectieve licentie	Optional	Resultaat van licentieafstemming
Broncodehash	Optional	Hash van de broncode vóór bouwen
URL van security.txt	Optional	Verwijzing naar het meldpunt voor kwetsbaarheden

De meest verrassende rij voor veel teams is andere unieke identificatoren (CPE, purl). Teams beschouwen package-URL's als de primaire sleutel van een SBOM. Onder TR-03183 v2.1.0 valt purl in de categorie Additional: verplicht als de data bestaat. De onvoorwaardelijke componentidentificator is de SHA-512-hash van het inzetbare artefact, gecombineerd met naam en versie. Als uw tooling geen purl kan berekenen voor een privé-interne bibliotheek, vormt dat geen complianceprobleem. Als het geen SHA-512 kan berekenen, wel. Zie veelgemaakte SBOM-fouten voor gerelateerde veldlacunes.

CycloneDX- en SPDX-ondersteuning

TR-03183 noemt de toegestane formaten en minimumversies:

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

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

De versienotes van v2.1.0 documenteren ook het upgradepad: v2.0.0 (20 september 2024) verhoogde CycloneDX van 1.4 naar 1.5 en SPDX naar 2.2.1. v2.1.0 (20 augustus 2025) verhoogde CycloneDX van 1.5 naar 1.6 en SPDX van 2.2.1 naar 3.0.1.

De praktische consequentie is dat tools die standaard CycloneDX 1.4-uitvoer genereren (nog steeds gangbaar in oudere CI-configuraties) niet voldoen onder v2.1.0. CycloneDX 1.6 introduceerde verfijnde ondersteuning voor cryptografische activa en ML BOM; SPDX 3.0.1 is een ingrijpende herziening met een nieuw payload-model. Uw CI-baseline heeft een expliciete vlag --spec-version 1.6 of equivalent nodig. Zie CycloneDX vs. SPDX voor een vergelijking van de twee formaten en toolvolwassenheid.

Een TR-03183-conform CycloneDX 1.6-skelet, met de Required-velden op documentniveau ingevuld:

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

De velden authors, timestamp en SHA-512 hashes zijn de Required-velden op document- en onderdeelniveau die het vaakst ontbreken in CI-standaardinstellingen. Valideer ze met cyclonedx-cli validate --input-version 1.6 voordat u een uitvoer als TR-03183-conform beschouwt.

De relatie tussen TR-03183, CSAF en VEX

TR-03183 behandelt de SBOM- en kwetsbaarheidsadvieslogica samen. De hoofdregel is eenvoudig: CSAF wordt aanbevolen voor advisories en is operationeel verplicht voor publicatie via security.txt. VEX is nooit verplicht.

Mechanisme	Kracht	Betekenis
CSAF 2.0 als adviesformaat	Aanbevolen	"The recommended format for distributing vulnerability information is CSAF (including also VEX as a profile)"
security.txt CSAF-tag	MOET	De security.txt-verklaring die verwijst naar CSAF-documenten moet beginnen met de tag CSAF:
URI van providermetadata	ZOU MOETEN	Fabrikant ZOU de URI van provider-metadata.json voor CSAF-documenten moeten opgeven
ISO/IEC 20153:2025	Referentie	De internationale norm voor CSAF v2.0
VEX	Informatief	VEX verschijnt als een CSAF-profiel en als een van de "should"-kanalen voor kwetsbaarheidsinformatie

CSAF (Common Security Advisory Framework) versie 2.0 is een OASIS-standaard gepubliceerd op 18 november 2022, met Errata 01 uitgebracht op 26 januari 2024. Het definieert een JSON-schema voor machineleesbare beveiligingsadvisories. Duitse CERT's (BSI-CERT, CERT-Bund) publiceren en consumeren CSAF standaard, en de Secvisogram-editor plus de OASIS CSAF-validator zijn de standaardtools.

De verbinding met Artikel 14 is subtieler dan sommige commentatoren suggereren. Article 14 van de CRA stelt meldingstermijnen voor ENISA en de coördinerende CSIRT (24 uur voor de vroege waarschuwing, 72 uur voor de kwetsbaarheidsmelding, en een eindrapport 14 dagen nadat een fix beschikbaar is voor een actief misbruikte kwetsbaarheid, of een maand na de melding bij een ernstig incident). Het specificeert geen publiek adviesformaat. TR-03183 vult die lacune: zodra u ENISA heeft gemeld, is het CSAF-document dat u publiceert via uw security.txt het operationele artefact dat klanten inlezen. Zonder CSAF-tooling vóór 11 september 2026 kunt u nog steeds Article 14 naleven, maar u voldoet niet aan de inkoopeisen en security.txt-verwachtingen die voortvloeien uit TR-03183.

VEX verdient een aparte toelichting. TR-03183 noemt VEX alleen als een CSAF-profiel en als een van de mogelijke kanalen voor het delen van kwetsbaarheidsinformatie; het is nooit verplicht. Vanuit CRA-perspectief is VEX nuttig voor not_affected-verklaringen op onderdeelniveau die alarmmoeheid voorkomen wanneer een SBOM een bibliotheek bevat met een bekende CVE die feitelijk niet bereikbaar is vanuit uw code. Het is geen TR-03183-verplichting. Gebruik het waar het zijn waarde bewijst.

Geldt TR-03183 buiten Duitsland?

TR-03183 is een Duitse nationale technische richtlijn uitgegeven door het BSI, geen EU-brede verordening, en stelt geen toepasselijkheid buiten Duitsland.

In de praktijk maken drie factoren TR-03183 relevant voor fabrikanten buiten Duitsland.

Ten eerste is de Duitse markt de grootste van de EU, en de inkoop van grote Duitse ondernemingen verwijst steeds vaker expliciet naar TR-03183. Verkoopt u aan een Duitse klant, dan kunt u TR-03183-taal verwachten in beveiligingsvragenlijsten en leverancierscontracten.

Ten tweede bestaat er op dit moment geen alternatieve, CRA-afgestemde specificatie met vergelijkbare diepgang, dus fabrikanten grijpen naar TR-03183 als praktische referentie.

Ten derde is TR-03183 opgebouwd rond dezelfde CRA-bijlagen waaraan u toch al moet voldoen: Bijlage I, Bijlage II en Bijlage VII. Documentatie opgesteld conform TR-03183 produceert het technische bewijs dat een EU-markttoezichtautoriteit in uw Annex VII-dossier verwacht, inclusief de SBOM. Zie de technische documentatie voor de volledige inhoudslijst van Annex VII.

TR-03183 vrijwillig implementeren is een verdedigbare technische keuze, maar geen wettelijke verplichting buiten Duitsland. Als uw producten geen hardwarecomponent bevatten, eindigt de redenering hier. Bevatten ze dat wel, dan kan hetzelfde document uw HBOM-vermeldingen naast de softwareonderdelen bevatten.

Wat u nu kunt doen