SBOM CycloneDX: praktische gids voor conformiteit met de CRA en NIS2

De Software Bill of Materials (SBOM) is in minder dan vijf jaar geëvolueerd van onderzoeksartefact tot wettelijke verplichting. De Cyber Resilience Act (CRA, EU 2024/2847) legt ze op voor alle producten met digitale elementen; NIS2 maakt ze tot een impliciete verwachting voor de beveiliging van de toeleveringsketen; DORA vermeldt ze als bewijs van zorgvuldigheid op het vlak van ICT. Deze gids beschrijft in detail hoe u een CycloneDX-SBOM opstelt, gebruikt en benut, het formaat dat zich in 2026 als standaard heeft opgeworpen.

Wat is een SBOM?

Een SBOM is een gestructureerde lijst van alle softwarecomponenten waaruit een product bestaat: open-sourcebibliotheken, transitieve afhankelijkheden, containerimages, licenties, leveranciers. Voor een typische SaaS gaat het om 200 tot 5.000 regels aan directe en transitieve afhankelijkheden.

Twee dominante formaten:

De CRA schrijft niet uitdrukkelijk een formaat voor, maar de uitvoeringsbepalingen van de Europese Commissie (in voorbereiding in 2026) convergeren naar CycloneDX JSON met het oog op standaardisering.

Waarom het verplicht is onder de CRA

Artikel 14.1 van Verordening (EU) 2024/2847 verplicht fabrikanten om:

"...kwetsbaarheden en componenten in het product te identificeren en te documenteren, onder meer door een software bill of materials op te stellen in een gangbaar, machineleesbaar formaat..."

Concreet betekent dit:

1. SBOM beschikbaar voor elke op de markt gebrachte versie van een PDE
2. Bijgewerkt bij elke nieuwe versie of patch
3. Machineleesbaar (gestructureerde JSON of XML)
4. Toegankelijk voor de markttoezichtautoriteiten op verzoek (15 werkdagen)

NIS2-entiteiten (krachtens art. 21.2.e over de beveiliging bij verwerving) eisen steeds vaker SBOM's van kritieke leveranciers als contractuele bijlage.

Voor een grondige analyse van het toepassingsgebied, zie onze CRA-gids: 8 contractclausules voor leveranciers.

Structuur van een CycloneDX-SBOM

Een minimalistisch CycloneDX JSON-bestand ziet er als volgt uit:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "metadata": {
    "timestamp": "2026-04-18T10:00:00Z",
    "component": {
      "type": "application",
      "name": "MyProduct",
      "version": "2.3.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Cruciale velden voor CRA-conformiteit:

• purl (Package URL): universele identificatie van een component, onmisbaar voor de kruiscontrole met CVE's
• licenses: voor open-sourceconformiteit en juridische traceerbaarheid
• hashes: cryptografische integriteit van de component (aanbevolen)
• supplier: de entiteit die de component heeft geproduceerd, nuttig voor de cascade in de toeleveringsketen

Automatisch een SBOM genereren

Node.js / JavaScript

npm install --save-dev @cyclonedx/cyclonedx-npm
npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.json

Python

pip install cyclonedx-bom
cyclonedx-py -e -o sbom.json

Docker-containers

syft packages docker:myimage:latest -o cyclonedx-json > sbom.json

Java / Maven

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.7.11</version>
</plugin>

Goede praktijk: genereer de SBOM in de CI/CD-pipeline bij elke release-build. Bewaar ze samen met de geversioneerde artefacten (Git-tag + SBOM = reproduceerbaarheid).

Kruiscontrole met CVE-databanken

Een ruwe SBOM heeft pas waarde als ze wordt vergeleken met gekende kwetsbaarheden. Drie bronnen om te raadplegen:

Raadpleeg voor elke component met een purl een van deze databanken en haal de lijst van toepasselijke CVE's met hun CVSS-score op. Automatiseerbaar via publieke API's, voorbeeld met OSV:

curl -X POST https://api.osv.dev/v1/query \
  -d '{"package":{"purl":"pkg:npm/lodash@4.17.21"}}'

In ResiPlan voert de SBOM-module deze kruiscontrole automatisch uit en worden waarschuwingen in het CRA-dashboard geactiveerd wanneer een nieuwe kritieke CVE een component van uw geregistreerde producten treft.

SBOM's van uw leveranciers ontvangen

Als u integrator bent (producten van derden in uw eigen SaaS inbouwt), moet u van elke kritieke leverancier een SBOM eisen. Voorbeeld van een contractclausule:

"De Leverancier verstrekt een SBOM in CycloneDX- of SPDX-formaat, bijgewerkt bij elke geleverde versie, die alle softwarecomponenten omvat, met inbegrip van open-source- en transitieve afhankelijkheden."

Raadpleeg onze volledige gids over de 8 CRA-clausules voor de redactie.

Concrete operationele voordelen:

• Zicht op de toeleveringsketen (wie gebruikt wat)
• Snelle reactie op zero-days die een gemeenschappelijke component treffen (zoals Log4Shell in 2021)
• Onderhandeling over beveiligingsondersteuning op basis van objectieve gegevens
• Klaar voor audits door NIS2-/CRA-autoriteiten

Uw SBOM aan klanten bezorgen

Drie modaliteiten, afhankelijk van de vertrouwelijkheid:

1. Publieke SBOM (aanbevolen voor open source en commerciële SaaS)

Publiceer de SBOM bij elke release in een publieke Git-repository:

https://github.com/myorg/myproduct/releases/download/v2.3.1/sbom.cdx.json

2. SBOM onder overeenkomst (vertrouwelijke producten)

Host ze op een beveiligd portaal met authenticatie (Vault, Artifactory). Gecontroleerde verspreiding onder NDA.

3. SBOM op verzoek (kritieke of geclassificeerde producten)

Verstrek ze binnen 15 werkdagen na elk legitiem verzoek (klant, autoriteit). Traceerbaarheid van elke verstrekking.

De CRA schrijft geen modaliteit voor, maar vereist wel de beschikbaarheid van de informatie. Met ResiPlan kunt u verstrekkingen en inkomende verzoeken traceren.

Veelvoorkomende valkuilen

1. "Oppervlakkige" SBOM zonder transitieve afhankelijkheden

Een SBOM die enkel directe afhankelijkheden vermeldt, mist 90% van de werkelijke inhoud. Zorg ervoor dat uw generator de volledige boom doorloopt (optie --include-transitive, afhankelijk van de tool).

2. Verouderde SBOM

Een SBOM die 6 maanden geleden werd gegenereerd, klopt vandaag niet meer. CI/CD-automatisering is verplicht, met vernieuwing bij elke release-build.

3. Incompatibel formaat

Wie CycloneDX XML genereert terwijl de klant JSON verwacht, maakt het bestand moeilijk te verwerken. Kies vast voor CycloneDX JSON 1.5+ (of SPDX JSON).

4. Componenten zonder purl

Zonder Package URL is een automatische kruiscontrole met CVE-databanken onmogelijk. Alle moderne generatoren produceren purls, maar handmatig opgestelde SBOM's laten ze vaak weg.

5. Geen opvolging op lange termijn

Genereren ≠ benutten. Zonder tooling die waarschuwt wanneer een nieuwe CVE uw portefeuille treft, blijft de SBOM een statisch artefact.

Hoe ResiPlan uw SBOM operationeel maakt

Onze module SBOM-beheer omvat:

• Import via drag-and-drop van CycloneDX + SPDX (JSON/XML)
• Automatische parsing van componenten, purls, licenties, hashes
• Continue kruiscontrole met CVE's voor elke component, met waarschuwingen
• Diff tussen versies van SBOM's (nieuwe component, versiewijziging)
• Inname van SBOM's van leveranciers met normalisatie en traceerbaarheid
• Globaal dashboard: X componenten, Y kwetsbaarheden, Z kritiek
• Export klaar voor klanten, met maskering van gevoelige componenten indien nodig

In combinatie met de modules PDE-register, CVD en Bijlage I van de CRA Compliance-suite krijgt u een end-to-end beeld van uw productbeveiligingsniveau.

Meer weten

• CRA: 8 contractclausules voor PDE-leveranciers
• CRA Compliance-suite: 7 ResiPlan-modules
• Oplossing voor de Product Security Officer
• AI-analyse van contracten voor DORA/NIS2/CRA