De CRA SBOM-vereisten zijn snel benoemd en gemakkelijk niet volledig in te vullen: u hebt een machineleesbare SBOM in een gangbaar formaat nodig die minstens de top-level afhankelijkheden van uw product dekt. De CRA verplicht fabrikanten daarnaast om doorlopende processen voor kwetsbaarhedenbeheer en documentatie te onderhouden, en markttoezichtautoriteiten kunnen de documentatie opvragen die nodig is om naleving aan te tonen. Het Duitse BSI TR-03183 gaat bij SBOM-formaten, -velden en -granulariteit aanzienlijk verder in technisch detail dan de CRA zelf.
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.
Verandert uw productklasse wat de SBOM moet laten zien?
De meeste producten vallen in de standaardcategorie en beoordelen zichzelf. De CRA benoemt daarnaast twee hogere groepen. Belangrijke producten (bijlage III) splitsen zich in klasse I, waartoe wachtwoordmanagers, VPN's en netwerkbeheersystemen behoren, en klasse II, die firewalls en inbraakdetectiesystemen omvat. Kritieke producten (bijlage IV) staan boven beide en omvatten hardwarebeveiligingsmodules en slimme-meter-gateways. De technische beschrijvingen voor elke groep zijn vastgelegd in Uitvoeringsverordening (EU) 2025/2392.
Uw klasse verandert niets aan de basisinhoud van de SBOM. Wat het wél verandert, is wie de SBOM leest. Een standaardproduct mag zichzelf beoordelen, dus u bent uw eigen beoordelaar. Producten van klasse II en kritieke producten hebben een aangemelde instantie nodig, en klasse I ook, tenzij u de betreffende geharmoniseerde normen hebt toegepast. Zodra een externe beoordelaar uw technische documentatie leest, is een SBOM die alleen de bovenste laag dekt en die u zelf had kunnen doorlaten, een stuk moeilijker te verdedigen. Hoe hoger uw klasse, hoe minder ruimte er is om te weinig te documenteren.
Hoe de meldingstermijn uw SBOM gebruikt
De meldingsverplichtingen van de CRA gelden sinds 11 september 2026, en hier doet een SBOM echt werk in plaats van in een map te liggen. Er kunnen twee termijnen gaan lopen. Wordt een kwetsbaarheid in uw product actief misbruikt, dan hebt u 24 uur voor een vroegtijdige waarschuwing, 72 uur voor een volledige melding en 14 dagen na het beschikbaar komen van een oplossing of workaround voor het eindrapport. Bij een ernstig incident zijn de eerste twee stappen gelijk, maar is het eindrapport één maand na de melding van 72 uur verschuldigd. De termijn begint zodra u er kennis van krijgt, niet pas wanneer u elk detail hebt bevestigd.
Dat is een krap tijdvenster om één vraag te beantwoorden: zijn we getroffen, en waar? Wanneer de volgende Log4Shell opduikt, kan een team met een actuele, doorzoekbare SBOM elk product en elke uitgeleverde versie in minuten doorzoeken. Een team zonder SBOM spit door build-logs terwijl de klok van 24 uur loopt. De SBOM maakt de termijn haalbaar.
Wat een fout in de SBOM kost
De CRA onderbouwt zijn eisen met echte boetes, en die zijn getrapt. De SBOM zit in de hoogste trap. Een overtreding van de essentiële eisen of de fabrikantverplichtingen uit de artikelen 13 en 14, waar SBOM-onderhoud, kwetsbaarhedenbeheer en technische documentatie thuishoren, kan oplopen tot 15 miljoen euro of 2,5 % van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Lichtere overtredingen kennen lagere plafonds: 10 miljoen euro of 2 % voor overige verplichtingen, en 5 miljoen euro of 1 % voor het verstrekken van onjuiste of misleidende informatie aan een autoriteit. Autoriteiten wegen de evenredigheid mee, dus een eerste misstap leidt zelden tot het maximum. Maar de SBOM is geen onbelangrijk vakje om af te vinken. Ze valt onder dezelfde plicht die de zwaarste straf draagt.
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.
Veelgestelde vragen
Vereist de CRA alleen de top-level afhankelijkheden of de volledige afhankelijkhedenboom?
Het wettelijke minimum zijn de top-level afhankelijkheden. In de praktijk houdt een SBOM die alleen de bovenste laag dekt zelden stand wanneer een klant of een auditor deze leest. Daarom documenteren de meeste fabrikanten de volledige transitieve afhankelijkhedenboom om aan te tonen dat het product daadwerkelijk gedekt is.
Welk SBOM-formaat vereist de CRA?
De tekst van de CRA vraagt alleen om een gangbaar, machineleesbaar formaat. De Duitse BSI TR-03183-2 v2.1.0, de maatgevende specificatie, noemt CycloneDX 1.6 of hoger en SPDX 3.0.1 of hoger als geaccepteerde formaten.
Vanaf wanneer gelden de SBOM-vereisten van de CRA?
De CRA is in december 2024 in werking getreden en geldt gefaseerd. De meldingsverplichtingen voor kwetsbaarheden op grond van artikel 14 gelden sinds 11 september 2026, en de volledige vereisten, waaronder de SBOM, gelden vanaf 11 december 2027.
Moet u uw SBOM onder de CRA publiceren?
Nee. De SBOM wordt bewaard in de technische documentatie en niet gepubliceerd. Markttoezichtautoriteiten kunnen deze opvragen, en u kunt deze op uw eigen voorwaarden met klanten delen.
Is de BSI TR-03183 van toepassing op de CRA?
Ja. De BSI TR-03183-2 is de Duitse technische richtlijn die de SBOM-vereiste van de CRA operationaliseert. Deze definieert de verplichte gegevensvelden, de geaccepteerde formaten en de verwachte mate van detail. Het is de praktische referentie om op het gebied van SBOM aan de CRA te voldoen.