Je kunt geen kwetsbaarheid beheren in software waarvan je niet weet dat je hem gebruikt. Precies daarom is de SBOM een belangrijk onderdeel van de Cyber Resilience Act. In dit artikel een korte introductie: wat is een SBOM, waarvoor wordt hij gebruikt, hoe ziet hij eruit en hoe maak je er een?
Wat is een SBOM?
SBOM staat voor Software Bill of Materials. Wie fysieke producten ontwerpt kent de term BoM natuurlijk: een lijst van alle onderdelen die samen het eindproduct vormen. Voor veel software-ontwikkelaars kan dit een nieuw concept zijn. Een SBOM is in essentie hetzelfde, maar dan voor software: een gestructureerde lijst van alle libraries en afhankelijkheden in jouw applicatie.
Moderne software bestaat doorgaans voor 70% of meer uit third-party componenten. Een typisch embedded product bevat een RTOS of Linux-distributie, een TLS library, een MQTT client of andere netwerkprotocollen, en tientallen packages die elk weer hun eigen afhankelijkheden meebrengen. De SBOM is dus in essentie een ingrediëntenlijst. Die analogie wordt ook door toezichthouders gebruikt: het Duitse BSI noemt de SBOM in zijn richtlijnen voor de Cyber Resilience Act letterlijk "het equivalent van een ingrediëntenlijst voor voedsel".
Geldt dit voor mijn product?
- Heeft het een dataverbinding, direct of via een ander apparaat?
- Breng je het commercieel op de EU-markt, ook B2B of als maatwerk voor één klant?
- Valt het niet onder sectorale regelgeving zoals medisch, automotive of luchtvaart?
Drie keer ja: dan geldt de CRA, inclusief de SBOM.
Pure SaaS valt buiten de CRA en onder NIS2, maar een cloudcomponent die je apparaat nodig heeft om te werken, hoort bij het product.
Waarvoor wordt de SBOM gebruikt?
1. Vulnerability management door de fabrikant zelf
"Welke kwetsbaarheden zitten er in mijn product?"
Dit is het primaire doel binnen de CRA. Met een machine-leesbare SBOM kun je geautomatiseerd nieuw ontdekte kwetsbaarheden (CVE's) opsporen in je eigen product. Zonder SBOM is de verplichting uit de CRA ("identificeer en documenteer kwetsbaarheden in componenten") praktisch niet uitvoerbaar. Het dwingt je als fabrikant om te weten wat je levert. De SBOM is daarmee geen losstaand compliance-document, maar onderdeel van het vulnerability-managementproces.
2. Impactanalyse bij kwetsbaarheden
"Deze kwetsbaarheid is gevonden. Welke van mijn producten zijn hierdoor geraakt?"
Stel dat er een kritieke kwetsbaarheid wordt gevonden in een veelgebruikte library. Met een actuele SBOM kun je snel bepalen welke producten en firmwareversies deze component bevatten en dus mogelijk geraakt zijn.
Zonder SBOM begint zo'n onderzoek vaak met de vraag: "Gebruiken wij die library eigenlijk ergens?"
3. Toezicht en incidentrespons
"Kunnen we aantonen wat er precies in ons product zit?"
Markttoezichthouders kunnen de SBOM opvragen wanneer die nodig is om de naleving van de CRA te controleren. Een actuele SBOM maakt het mogelijk om snel en concreet aan te tonen welke softwarecomponenten onderdeel zijn van een product en welke versies daarvan worden gebruikt.
De tijdlijn
- 10 december 2024: de Cyber Resilience Act treedt in werking.
- 11 september 2026: meldplicht voor actief uitgebuite kwetsbaarheden en ernstige incidenten.
- 11 december 2027: de belangrijkste CRA-verplichtingen worden van toepassing, waaronder de verplichting om een SBOM bij te houden.
Hoe ziet een SBOM eruit?
"commonly used and machine-readable format" - aldus de CRA
Er zijn twee dominante open standaarden: SPDX en CycloneDX. Let op: dit zijn geen bestandsformaten, maar afspraken over welke informatie een SBOM bevat en hoe die samenhangt. Elke standaard kan in meerdere bestandsformaten worden opgeslagen, bijvoorbeeld JSON, XML of YAML. In de praktijk is JSON bij beide de gangbare keuze, en dat is ook wat je in de voorbeelden hieronder ziet. De CRA schrijft op dit moment geen specifieke standaard of bestandsformaat voor, maar vereist een gangbaar en machine-leesbaar formaat.
Ze vermelden per component de naam, de exacte versie, de licentie en een unieke identifier waarmee tooling het component automatisch kan koppelen aan bekende kwetsbaarheden. Daarnaast leggen ze de onderlinge afhankelijkheden vast: welk component gebruikt welk ander component.
Deze informatie vormt een graaf (graph) waarin je precies ziet hoe alle afhankelijkheden zich tot elkaar verhouden, inclusief de indirecte, die je zelf nooit bewust hebt gekozen.
SPDX (als JSON)
SPDX (Software Package Data Exchange) komt uit de Linux Foundation en is de oudste van de twee. Oorspronkelijk ontstaan om de vraag "welke open source licenties zitten er in mijn product?" te beantwoorden. Later is het security component toegevoegd in versies 2.0 en 3.0 van de standaard.
{
"spdxVersion": "SPDX-2.3",
"name": "frogwatch-firmware",
"packages": [
{
"name": "rustls",
"SPDXID": "SPDXRef-Package-rustls",
"versionInfo": "0.23.4",
"downloadLocation": "https://crates.io/crates/rustls",
"licenseConcluded": "Apache-2.0 OR MIT",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:cargo/rustls@0.23.4"
}
]
}
],
"relationships": [
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relationshipType": "DEPENDS_ON",
"relatedSpdxElement": "SPDXRef-Package-rustls"
}
]
}
Vereenvoudigd voorbeeld
CycloneDX (als JSON)
CycloneDX is een jongere standaard die vanaf het begin sterk vanuit een security- en supply-chainperspectief is ontwikkeld.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {
"component": {
"type": "firmware",
"name": "frogwatch-firmware",
"version": "2.4.1"
}
},
"components": [
{
"type": "library",
"name": "rustls",
"version": "0.23.4",
"purl": "pkg:cargo/rustls@0.23.4",
"licenses": [
{ "license": { "id": "Apache-2.0" } }
]
}
],
"dependencies": [
{
"ref": "frogwatch-firmware",
"dependsOn": ["pkg:cargo/rustls@0.23.4"]
}
]
}
Vereenvoudigd voorbeeld
De structuur van beide formaten is vergelijkbaar en op het eerste gezicht zie je nauwelijks verschil. Het leuke van CycloneDX is dat het meer kan dan alleen SBOM: er is een variant voor hardware (HBOM) en voor cryptografische afhankelijkheden (CBOM). Daarvoor kun je dan dezelfde visualisatietools gebruiken om je afhankelijkheden inzichtelijk te maken.
Hoe maak je een SBOM?
Om te beginnen: je maakt één SBOM per product, en eigenlijk per uitgebrachte versie van dat product. De SBOM beschrijft precies wat er zit in de firmware die je hebt uitgeleverd. Bestaat een product uit meerdere onderdelen, of delen twee producten dezelfde basis, dan krijgt toch elk product zijn eigen SBOM. Anders kun je bij een kwetsbaarheid niet beantwoorden welke apparaten in het veld geraakt zijn.
Afhankelijk van je manier van werken kan dit veel werk zijn of juist heel weinig. Omdat wij bij Jitter voornamelijk in Rust programmeren is de SBOM volledig automatisch te genereren via cargo cyclonedx. Dit draait mee in onze CI-pipeline: voor elke aanpassing van de software hebben wij dus automatisch een nieuwe, machine-readable SBOM.
Dat is precies hoe ik denk dat je compliance moet aanpakken: niet achteraf een document maken omdat een wet dat vraagt, maar je ontwikkelproces zo inrichten dat het document automatisch ontstaat.
Uit de praktijk: één product, twee binaries
Onze Frogwatch-sensoren draaien een eigen bootloader én een applicatiefirmware, allebei in Rust. Vanuit Cargo gezien zijn dat twee losse projecten met elk hun eigen afhankelijkheidsboom, dus cargo cyclonedx levert twee SBOMs op.
Maar de klant krijgt één product. De SBOM van het apparaat is daarom de combinatie van beide: een SBOM op productniveau die per firmwareversie verwijst naar de SBOM van de bootloader en die van de applicatie. Gedeelde crates kunnen daarin twee keer voorkomen, soms met verschillende versies. Een kwetsbaarheid in de oudere versie raakt de bootloader ook nadat de applicatie al gepatcht is.
Daar komt nog een korte lijst bij van wat Cargo niet ziet: de versie van de Rust-toolchain en binaries die niet van ons zijn, zoals de firmware van een modem of radio. Die voegen we handmatig toe.
Het genereren per crate draait al automatisch in onze pipeline. Het samenvoegen tot één product-SBOM per release is de volgende stap die we nu kunnen gaan automatiseren.
Lastiger wordt het bij oudere C-codebases met gekopieerde libraries, of bij binaire blobs van chipfabrikanten. Daar bestaat geen manifest en moet je de inventaris deels handmatig of met binaire analyse opbouwen. Daar zit voor sommige bedrijven veel werk richting 2027.
Conclusie
Vanaf 11 december 2027 gelden de belangrijkste verplichtingen uit de Cyber Resilience Act voor fabrikanten van producten met digitale elementen die op de EU-markt worden gebracht.
Dat klinkt nog ver weg, maar een SBOM is geen document dat je één keer voor de compliance-afdeling maakt. Het moet onderdeel worden van je vulnerability-managementproces.
Wie zijn buildproces nu al zo inricht dat bij iedere release automatisch een actuele SBOM ontstaat, hoeft in 2027 dus niet alsnog een compliance-project op te starten.
Je bent dan niet alleen compliant. Je weet daadwerkelijk wat er in je product zit.
Benieuwd hoe dit er voor jouw product uitziet, of wil je weten wat de CRA verder van je vraagt? Neem contact op.