De EU Cyber Resilience Act (Verordening (EU) 2024/2847) is in december 2024 van kracht geworden. Hij verplicht een software bill of materials voor elk product met digitale elementen dat in de EU wordt verkocht. Maar wat detail betreft legt de wet de lat laag. Uw SBOM moet machineleesbaar zijn en ten minste de top-level-afhankelijkheden van het product dekken. Het exacte formaat en de minimale gegevensvelden worden later vastgelegd door de Europese Commissie, via uitvoeringshandelingen.
Tot die regels er zijn, geeft het Duitse BSI het meest gedetailleerde antwoord op wat een SBOM op CRA-niveau daadwerkelijk zou moeten bevatten. De technische richtlijn TR-03183 vertaalt de algemene taal van de CRA naar concrete vereisten, en deel 2 behandelt de SBOM.
Eerst: wat TR-03183 niet is
Het is geen wet. Het BSI stelt duidelijk dat de richtlijn niet bindend is, niet kan dienen als vermoeden van conformiteit en zal worden vervangen door geharmoniseerde Europese normen zodra die er zijn. De richtlijn naar de letter volgen maakt u niet automatisch CRA-conform.
Wat het wel biedt, is de helderste voorvertoning die er is van waar de formele regels naartoe gaan, geschreven als vereisten waaraan u zich vandaag al kunt toetsen. De richtlijn bestaat inmiddels uit meerdere delen:
Deel | Reikwijdte |
|---|---|
Deel 1 | Algemene vereisten voor fabrikanten en producten |
Deel 2 | Software bill of materials (het onderwerp van deze gids) |
Deel 3 | Kwetsbaarheidsrapporten en -meldingen |
Module H | Conformiteit op basis van volledige kwaliteitsborging |
Deel 2 is beschikbaar in versie 2.1.0, gepubliceerd in augustus 2025. Twee dingen om te weten over versies:
Gebruik de actuele versie om bij te blijven. De direct voorgaande versie is toegestaan tot zes maanden na het verschijnen van een nieuwe versie.
Het BSI herziet de richtlijn regelmatig. Raadpleeg bsi.bund.de voor de nieuwste versie voordat u op een bepaalde versie vertrouwt.
Formaatvereisten
Een SBOM moet machinaal verwerkbaar zijn. Dat betekent JSON of XML, in een van twee formaten:
Formaat | Versie toegewezen in v2.1.0 |
|---|---|
CycloneDX | 1.6 |
SPDX | 3.0.1 |
Versie 2.1.0 voegde veld-voor-veld-toewijzingen toe voor beide formaten, wat het oude giswerk over hoe elke vereiste waarde moet worden weergegeven sterk vermindert. Het BSI publiceert daarnaast op GitHub een CycloneDX-property-taxonomie voor de velden die specifiek zijn voor de richtlijn.
Genereer een aparte SBOM voor elke softwareversie. Een SBOM voor een bestaande versie genereert u alleen opnieuw wanneer er nieuwe componentinformatie opduikt, of wanneer u een fout in de gegevens corrigeert.
Inhoudsvereisten
De richtlijn maakt onderscheid tussen wat het document nodig heeft en wat elke component nodig heeft.
Op documentniveau:
Identificeer de maker, via e-mail of een URL als alternatief.
Leg de datum en tijd vast waarop de componentgegevens zijn verzameld.
Voor elke component:
Veld | Vereiste |
|---|---|
Naam en versie | Verplicht. SemVer of kalenderversiebeheer heeft de voorkeur. |
Afhankelijkheden | Verplicht. Leg vast op welke componenten elke component steunt, niet alleen een platte lijst. |
Licentie | Verplicht. Gebruik de SPDX-identifier. Voor licenties die niet in de SPDX-lijst staan, zijn alternatieven gedefinieerd. |
Hash | Verplicht. SHA-256. |
Bron-/uitvoerbare URI, CPE, PURL | Optioneel, maar nuttig voor matching en traceerbaarheid. |
Versie 2.1.0 herzag ook het licentiegedeelte en voegde verwerking toe voor virtuele en gerefereerde componenten. Die dekken onderdelen van een product die geen eenvoudig meegeleverde bibliotheek zijn.
Waar SBOMs en kwetsbaarheden samenkomen
TR-03183 houdt kwetsbaarheidsgegevens bewust buiten de SBOM. Om aan te geven welke kwetsbaarheden een product treffen en of ze daadwerkelijk exploiteerbaar zijn, verwijst de richtlijn naar CSAF met een VEX-profiel. De twee documenten doen verschillend werk:
Document | Beantwoordt |
|---|---|
SBOM | Welke componenten in de software zitten |
VEX / CSAF | Welke kwetsbaarheden van toepassing zijn en of ze exploiteerbaar zijn |
De reden voor de splitsing is timing. Een componentinventaris verandert nauwelijks tussen releases. De kwetsbaarheidsstatus verandert dagelijks. Aparte documenten laten elk op zijn eigen tempo bijwerken.
De splitsing is ook waar het lastige deel begint. Twee dingen moeten kloppen voordat een SBOM bruikbare kwetsbaarheidsinformatie oplevert:
Schone, machinaal te matchen identifiers (CPE of PURL) op elke component.
Volledige, accurate afhankelijkheidsrelaties.
Op het tweede punt struikelen de meeste tools. Veel generatoren produceren een lijst met componenten en laten de structuur die ze verbindt stilletjes weg. Zijn die relaties eenmaal weg, dan wordt de vraag "treft deze nieuwe CVE ons, en hoe diep reikt die" giswerk. Een conforme SBOM is het startpunt. Wat die werkelijk waard is bij een incident, hangt af van de diepte en nauwkeurigheid eronder.
Hoe dit past in uw CRA-werk
Voor elke fabrikant die aan Duitsland verkoopt, is TR-03183 de referentie om naar te ontwerpen, en het beste signaal dat beschikbaar is voor de EU-brede regels die nog worden opgesteld. De SBOM is één onderdeel van EU Cyber Resilience Act-compliance, die ook kwetsbaarheidsrapportage, secure-by-design en technische documentatie over de volledige ondersteuningsperiode van het product omvat.
Interlynk genereert, importeert en verrijkt SBOMs in CycloneDX en SPDX, lost de volledige afhankelijkheidsboom op met intacte relaties, en houdt componenten en kwetsbaarheden gekoppeld. De SBOM die u voor de richtlijn opstelt, blijft nuttig voor het kwetsbaarheidsbeheer dat zij hoort te ondersteunen.