Developmnet, Featured

CRA compliance die in uw bedrijf inslaat als een (S)BOM

Geschreven door Danny Zeegers
28 juni 2026

Waarom een SBOM-proces essentieel is voor naleving van de Cyber Resilience Act

Stel je een klein softwarebedrijf voor dat een cloudgebaseerde tijdregistratieapplicatie ontwikkelt voor klanten in heel Europa. De applicatie is voornamelijk gebouwd in C# op het .NET-platform en is in de loop der jaren uitgegroeid van een eenvoudige oplossing voor urenregistratie tot een uitgebreid platform voor workforce management. Er komen voortdurend nieuwe klantverzoeken binnen en de ontwikkelprioriteiten worden grotendeels bepaald door het snel opleveren van nieuwe functionaliteit om concurrerend te blijven.

Het ontwikkelteam bestaat uit een klein aantal softwareontwikkelaars die werken in korte ontwikkelcycli. Succes wordt gemeten aan de hand van de snelheid waarmee nieuwe functionaliteiten worden opgeleverd. Daardoor worden beveiligingsactiviteiten vaak uitgesteld tot een later stadium van het ontwikkelproces. Hoewel de ontwikkelaars waar mogelijk goede programmeerpraktijken toepassen, bestaat er geen formele Secure Software Development Lifecycle (Secure SDLC) en maakt Security by Design nog geen integraal onderdeel uit van de engineeringcultuur van de organisatie.

Zoals bij veel moderne applicaties is het platform sterk afhankelijk van softwarecomponenten van derden. Open-source NuGet-packages verzorgen onder meer authenticatie, rapportage, PDF-generatie, logging, databaseconnectiviteit en diverse hulpfuncties. Daarnaast integreert de applicatie met verschillende externe diensten, waaronder salarisverwerkers, identiteitsproviders, cloudplatformen, e-mailgateways, boekhoudsystemen en HR-oplossingen.

Deze leveranciers zijn op hun beurt weer afhankelijk van andere leveranciers en softwarebibliotheken, waardoor een complexe keten van derde- en vierdepartijafhankelijkheden ontstaat die voor het ontwikkelteam grotendeels onzichtbaar blijft.

Authenticatie vormt een extra uitdaging. Het bedrijf vertrouwt op een externe firewall en een beveiligde toegangsprovider om beheerstoegang en externe verbindingen te beschermen. Hoewel Multi-Factor Authentication (MFA) is ingeschakeld, is de implementatie relatief zwak en afhankelijk van een leverancier die regelmatig problemen ondervindt met OAuth-authenticatiestromen. Deze betrouwbaarheidsproblemen hebben geleid tot tijdelijke workarounds, extra beheerlast en onzekerheid over de veerkracht van de authenticatiearchitectuur.

Hoewel deze problemen niet noodzakelijk een directe overtreding van de Cyber Resilience Act vormen, onderstrepen zij wel het belang van inzicht in afhankelijkheden van externe beveiligingsleveranciers en de risico’s die daarmee gepaard gaan.

Ook het risicomanagement binnen de organisatie is nog weinig volwassen. Beveiligingsrisico’s worden informeel besproken tijdens ontwikkelvergaderingen, maar er bestaat geen gestructureerde productrisicobeoordeling, geen gedocumenteerd proces voor dreigingsmodellering en geen systematische evaluatie van risico’s binnen de softwaretoeleveringsketen. Beveiligingsmaatregelen worden meestal reactief ingevoerd, nadat kwetsbaarheden zijn ontdekt of klanten zorgen hebben geuit, in plaats van proactief op basis van een formeel risicobeheerproces.

Nu de Cyber Resilience Act steeds dichter bij volledige inwerkingtreding komt, realiseert de organisatie zich dat deze werkwijze niet langer volstaat. De CRA legt verplichtingen op die van softwarefabrikanten verlangen dat zij inzicht hebben in de componenten waaruit hun producten bestaan, kwetsbaarheden gedurende de volledige levenscyclus beheren, technische documentatie onderhouden en kunnen aantonen dat cybersecurity vanaf de vroegste ontwikkelfase is meegenomen.

Een van de eerste fundamentele capaciteiten die het bedrijf daarom moet ontwikkelen, is een Software Bill of Materials (SBOM)-proces. Een SBOM biedt een volledig overzicht van alle gebruikte softwarecomponenten, versies, licenties en leveranciers binnen de applicatie. Hiermee kan de organisatie snel bepalen welke producten worden geraakt wanneer nieuwe kwetsbaarheden worden gepubliceerd, de blootstelling binnen de softwaretoeleveringsketen beoordelen, gecoördineerd kwetsbaarheden beheren en de technische documentatie onderhouden die nodig is voor naleving van wet- en regelgeving.

De implementatie van een SBOM vormt echter slechts één onderdeel van een veel bredere compliance-reis. Om aan de verwachtingen van de CRA te voldoen, moet de organisatie daarnaast een gestructureerde Secure SDLC invoeren, periodieke risicobeoordelingen uitvoeren, identiteits- en toegangsbeheer versterken, leveranciersbeheer professionaliseren, beveiligingsmaatregelen formaliseren en security integreren in iedere fase van de softwareontwikkeling.

Samen leveren deze maatregelen het bewijs dat Cybersecurity by Design daadwerkelijk wordt toegepast en maken zij continue naleving gedurende de volledige levenscyclus van het product mogelijk.

Tijd om wakker te worden

De onderneming groeit snel en het management is tevreden met het toenemende aantal klanten. De ontwikkeling verloopt volgens een agile-methodiek met sprints van twee weken, waarbij de belangrijkste succesfactor het tijdig opleveren van nieuwe functionaliteiten is.

Beveiliging wordt als belangrijk beschouwd, maar zelden als urgent.

Zoals een van de ontwikkelaars gekscherend opmerkt:

“Als de klant het niet ziet, haalt het de sprint waarschijnlijk niet.”

Helaas heeft deze manier van denken geleidelijk geleid tot een technische schuld die grotendeels onzichtbaar is gebleven voor zowel het management als de klanten.

De applicatie is afhankelijk van veel meer software dan iemand zich realiseert

Ontwikkelaars installeren routinematig NuGet-packages om de ontwikkeling te versnellen.

Vandaag de dag bevat de applicatie meer dan 180 externe packages, waaronder:

Entity Framework
Newtonsoft.Json
Serilog
AutoMapper
Identity-bibliotheken
Rapportagecomponenten
PDF-generatoren
Azure SDK’s
E-mailbibliotheken
Authenticatieframeworks

Veel van deze packages zijn op hun beurt weer afhankelijk van tientallen andere bibliotheken.

Niemand beheert een volledig overzicht van alle afhankelijkheden.

Niemand weet precies welke versies daadwerkelijk in productie draaien.

Niemand weet welke componenten niet langer worden onderhouden.

Wanneer een nieuwe kwetsbaarheid wordt gepubliceerd, zoeken ontwikkelaars handmatig door projectbestanden in de hoop dat hun applicatie niet getroffen is.

De softwaretoeleveringsketen blijft groeien

TimeTrack Pro is uitgegroeid tot een sterk geïntegreerd platform dat gegevens uitwisselt met tal van externe organisaties.

Voorbeelden hiervan zijn:

Microsoft Azure
Microsoft Entra ID
Salarisverwerker
HR-platform
Boekhoudsoftware
Betaalprovider
SMTP-mailprovider
SMS-notificatieprovider
Identity Federation Services
Externe API Gateway

Elke leverancier introduceert nieuwe afhankelijkheden.

Veel leveranciers vertrouwen zelf weer op cloudproviders, managed services en open-sourcecomponenten die TimeTrack Solutions nooit heeft beoordeeld.

Hierdoor ontstaat een steeds complexer netwerk van derde- en vierdepartijleveranciers binnen de softwaretoeleveringsketen.

De gevaarlijke aanname

Het management gaat ervan uit dat deze leveranciers hun eigen beveiliging wel op orde hebben.

Maar niemand heeft ooit vastgelegd:

leveranciersrisico’s;
contractuele beveiligingseisen;
procedures voor het melden van kwetsbaarheden;
eigenaarschap van softwarecomponenten;
zekerheid over de beveiliging van leveranciers.

Deze aannames kunnen leiden tot aanzienlijke risico’s binnen de software supply chain.

Secure Development bestaat… min of meer

Ontwikkelaars voeren code reviews uit.

Maar…

Soms.

Sommige projecten maken gebruik van statische codeanalyse, andere niet.

Beveiligingstesten zijn grotendeels afhankelijk van de ervaring van individuele ontwikkelaars.

Wat ontbreekt is onder andere:

een formele Secure SDLC;
gedocumenteerde richtlijnen voor veilig programmeren;
dreigingsmodellering;
security gates binnen het ontwikkelproces;
een goedkeuringsproces voor nieuwe softwareafhankelijkheden;
beveiligingsreviews van de softwarearchitectuur.

Beveiligingsactiviteiten vinden meestal na de ontwikkeling plaats, in plaats van tijdens de ontwikkeling.

Wanneer deadlines onder druk staan, worden beveiligingstaken doorgeschoven naar “de volgende sprint”.

In de praktijk wordt die volgende sprint vrijwel altijd gevuld met nieuwe functionaliteit.

Risicomanagement

Wanneer het management wordt gevraagd naar de cyberbeveiligingsrisico’s van het product, luidt het antwoord vaak optimistisch:

“We kennen onze risico’s.”

Maar wanneer vervolgens wordt gevraagd waar deze risico’s zijn gedocumenteerd…

…valt het stil.

Risicobeoordelingen bestaan uitsluitend uit gesprekken tijdens vergaderingen.

Er is:

geen gedocumenteerde risicobeoordelingsmethodiek;
geen productrisicoregister;
geen leveranciersrisicoregister;
geen beoordeling van kans en waarschijnlijkheid;
geen impactanalyse;
geen behandel- of mitigatieplan.

Hierdoor kan het management niet aantonen dat beslissingen over cybersecurity zijn gebaseerd op een gestructureerde en objectieve risicoanalyse.

Wanneer een auditor vraagt:

“Kunt u uw Software Bill of Materials tonen en uitleggen hoe u voldoet aan de Cyber Resilience Act?”

kan de organisatie fundamentele vragen niet met zekerheid beantwoorden, zoals:

Welke software bevindt zich in ons product?
Welke leverancier heeft deze component geïntroduceerd?
Welke versies bevatten bekende kwetsbaarheden?
Wie is eigenaar van het bijbehorende risico?
Welke klanten worden hierdoor geraakt?
Hoe snel kunnen wij reageren?

Zonder antwoord op deze vragen wordt het aantonen van naleving van de Cyber Resilience Act bijzonder moeilijk.

Het begin van de reis

In plaats van alle problemen tegelijkertijd te willen oplossen, besluit TimeTrack Solutions een gestructureerde aanpak te volgen.

Het bedrijf introduceert het CATS Framework:

C – Classify
Breng producten, leveranciers en softwarecomponenten volledig in kaart.

A – Assess
Beoordeel risico’s, de volwassenheid van de organisatie en eventuele compliance-gaten.

T – Track
Volg softwarecomponenten, kwetsbaarheden, bewijsmateriaal en technische documentatie met behulp van een geautomatiseerd SBOM-proces.

S – Sustain
Borg compliance door middel van veilige softwareontwikkeling, continue monitoring en lifecycle management.

Beveiliging integreren in de dagelijkse softwareontwikkeling

Na verloop van tijd bleek dat de grootste verandering niet technisch, maar cultureel van aard was.

Beveiliging was niet langer iets dat pas werd uitgevoerd nadat de ontwikkeling was afgerond. Het werd een integraal onderdeel van het ontwikkelproces.

Nieuwe functionaliteiten begonnen voortaan met een lichte vorm van dreigingsmodellering (threat modeling). Ontwikkelaars beoordeelden de risico’s van nieuwe softwareafhankelijkheden voordat extra packages werden toegevoegd. Leveranciersbeoordelingen werden onderdeel van het inkoopproces, terwijl beheeraccounts beter werden beschermd met phishingbestendige Multi-Factor Authentication (MFA) en verbeterd Identity & Access Management.

Bij iedere software-release werd automatisch niet alleen een Software Bill of Materials (SBOM) gegenereerd, maar ook:

een geactualiseerde risicobeoordeling;
een kwetsbaarhedenrapport;
bijgewerkte technische documentatie;
auditbewijsmateriaal voor compliance.

Een jaar later…

Tijdens een interne beoordeling van de gereedheid voor de Cyber Resilience Act stelde de auditor dezelfde vraag die een jaar eerder de eerste bijeenkomst volledig had stilgelegd.

“Kunt u uitleggen welke software zich in uw product bevindt en hoe u de cybersecurity daarvan gedurende de volledige levenscyclus beheert?”

Ditmaal hoefde niemand spreadsheets of documentatie door te zoeken.

De softwarearchitect opende één centraal compliance-dashboard.

Binnen enkele minuten waren beschikbaar:

de actuele SBOM;
de bijbehorende risico’s;
leveranciersinformatie;
lifecycle-documentatie;
de status van kwetsbaarheden;
ondersteunend auditbewijsmateriaal.

Wat ooit begon als een zoektocht naar compliance was uitgegroeid tot iets veel waardevollers:

een meetbaar, reproduceerbaar en continu verbeterend proces voor softwaregovernance.

De belangrijkste les

De grootste les die het bedrijf leerde, was dat de SBOM nooit het uiteindelijke doel was geweest.

Het werkelijke doel was om inzicht te krijgen in:

de software die wordt ontwikkeld;
de leveranciers waarop wordt vertrouwd;
de risico’s die worden geaccepteerd;
de beheersmaatregelen die nodig zijn om deze risico’s te beperken.

Het CATS Framework bood hiervoor de noodzakelijke structuur.

Daardoor werd naleving van de Cyber Resilience Act niet langer gezien als een administratieve verplichting, maar als het natuurlijke resultaat van goed software-engineering, effectief risicomanagement en degelijk governance.

Het CATS CRA Framework

Het CATS CRA Framework is meer dan een compliance-methodiek.

Het is een gestructureerd project- en implementatiekader dat organisaties helpt om de eisen van de Cyber Resilience Act te vertalen naar praktische uitvoeringsactiviteiten.

Door software-inventarisatie, SBOM-generatie, objectieve risicobeoordeling, leveranciersbeheer en continue verbetering met elkaar te combineren, biedt het framework het management volledig inzicht in:

cyberbeveiligingsrisico’s;
de softwaretoeleveringsketen;
de noodzakelijke beheersmaatregelen;
de voortgang van compliance.

In plaats van beslissingen te baseren op aannames of persoonlijke meningen, introduceert het CATS Framework een evidence-based aanpak.

Hierdoor kan de organisatie:

consistente beslissingen nemen;
investeringen prioriteren op basis van bedrijfsrisico;
aantonen dat cyberrisico’s gedurende de volledige productlevenscyclus systematisch worden geïdentificeerd, beoordeeld en beheerst.

Een belangrijke waarschuwing van onze experts

Een veelvoorkomende misvatting binnen CRA-projecten is:

SBOM → Klaar.

In werkelijkheid vormt een SBOM slechts één artefact binnen een veel breder proces van Software Supply Chain Risk Management.

Voor een organisatie die volledig CRA-compliant wil zijn, bestaat dit proces uit zeven opeenvolgende fasen, elk met eigen doelstellingen, belanghebbenden, hulpmiddelen en resultaten.

Complete SBOM- en risicobeoordelingslevenscyclus

Productontwikkeling
⬇
Ontdekking & Classificatie
⬇
SBOM-generatie
⬇
Component Intelligence
⬇
Risicobeoordeling
⬇
Risicobehandeling
⬇
Continue Monitoring
⬇
Governance & Continue Verbetering

De SBOM als onderdeel van een groter geheel

Binnen het CATS CRA Framework wordt de Software Bill of Materials nooit beschouwd als een op zichzelf staand eindproduct.

De SBOM is het resultaat van een gestructureerd proces dat technische informatie omzet in bruikbare bedrijfsinformatie en objectief risicomanagement.

Alles begint met ontdekking (Discovery).

Voordat een SBOM kan worden gegenereerd, moet een organisatie exact weten wat zij heeft gebouwd.

Daarom worden onder andere onderzocht:

GitHub- en Azure DevOps-repositories;
projectbestanden;
package managers;
containerdefinities;
Infrastructure-as-Code (IaC)-repositories;
cloudservices;
API’s;
integraties met derde partijen.

Wat aanvankelijk één softwareproduct lijkt, blijkt al snel een uitgebreid ecosysteem van softwarecomponenten, leveranciers en cloudafhankelijkheden te zijn. Deze ontdekkingsfase levert veel meer op dan alleen een inventarisatie. Zij vormt de basis voor een volledig inzicht in de softwaretoeleveringsketen en daarmee voor naleving van de Cyber Resilience Act.

SBOM-generatie: een compleet overzicht van de software

Zodra de softwareomgeving volledig in kaart is gebracht, kan de organisatie het genereren van een Software Bill of Materials (SBOM) automatiseren met behulp van standaarden zoals CycloneDX of SPDX.

De build-pipelines produceren voortaan automatisch een nauwkeurige inventaris van iedere softwarecomponent, inclusief:

de componentnaam;
de gebruikte versie;
de leverancier of uitgever;
de licentie;
de cryptografische hash of fingerprint.

Maar hiermee eindigt het proces niet.

Een SBOM geeft slechts antwoord op één fundamentele vraag:

“Welke software bevindt zich in ons product?”

De SBOM zegt echter niets over:

de betrouwbaarheid van componenten;
de onderhoudsstatus;
bekende kwetsbaarheden;
licentierisico’s;
leveranciersrisico’s.

Daarvoor is aanvullende analyse noodzakelijk.

Component Intelligence

De echte analyse begint wanneer iedere softwarecomponent wordt verrijkt met externe informatie.

Hiervoor worden onder andere geraadpleegd:

publieke kwetsbaarhedendatabases (zoals CVE en NVD);
beveiligingsadviezen van leveranciers;
open-source communities;
software intelligence-platformen;
licentie-informatiedatabases.

Hiermee kan worden vastgesteld:

of een component nog actief wordt onderhouden;
of nieuwere versies beschikbaar zijn;
welke kwetsbaarheden bekend zijn;
of licentiebeperkingen bestaan;
of er risico’s zijn verbonden aan de leverancier of maintainer.

Een eenvoudige verwijzing zoals:

Newtonsoft.Json 12.0.3

groeit hierdoor uit tot een volledig softwareprofiel waarin onder andere wordt beschreven:

de onderhoudsstatus;
bekende kwetsbaarheden;
de reputatie van de leverancier;
licentieverplichtingen;
de totale risicoclassificatie.

De SBOM verandert daarmee van een eenvoudige softwarelijst in een bron van waardevolle managementinformatie.

Objectieve risicobeoordeling

Deze verrijkte informatie vormt de basis voor de volgende — en misschien wel belangrijkste — stap:

Objectieve risicobeoordeling.

Veel organisaties maken dezelfde fout.

Zodra een scanner een Critical Vulnerability rapporteert, wordt automatisch aangenomen dat ook het bedrijfsrisico kritiek is.

Dat is lang niet altijd het geval.

Een technische kwetsbaarheid moet altijd binnen de bedrijfscontext worden beoordeeld.

Vragen die daarbij gesteld moeten worden zijn onder andere:

Is de kwetsbaarheid daadwerkelijk misbruikbaar?
Wordt de kwetsbare functionaliteit daadwerkelijk gebruikt?
Is de applicatie rechtstreeks via internet bereikbaar?
Zijn er compenserende beveiligingsmaatregelen aanwezig?
Wat zijn de operationele gevolgen bij misbruik?
Wat is de financiële impact?

Hiervoor kunnen bewezen methodieken worden gebruikt, zoals:

ISO 27005;
NIST Risk Management Framework (RMF);
FAIR;
de OWASP Risk Rating Methodology.

Elke technische bevinding wordt daarmee vertaald naar een meetbaar bedrijfsrisico.

Het eindresultaat is geen lange lijst met kwetsbaarheden meer, maar een geprioriteerd risicoregister, ondersteund door:

behandelplannen;
managementdashboards;
investeringsprioriteiten.

Hierdoor kan het management weloverwogen beslissingen nemen op basis van bedrijfsimpact, in plaats van uitsluitend te reageren op technische meldingen.

Risicobehandeling

Wanneer de risico’s objectief zijn beoordeeld, kan het management bepalen welke maatregel het meest geschikt is.

Afhankelijk van de situatie kan een risico worden:

Vermeden

Door kwetsbare software te vervangen of te upgraden.

Verminderd

Door aanvullende beveiligingsmaatregelen toe te passen, zoals:

sterkere authenticatie;
extra logging;
continue monitoring;
betere leverancierscontrole.

Geaccepteerd

Wanneer het resterende risico aantoonbaar binnen de risicobereidheid van de organisatie valt.

Overgedragen

Bijvoorbeeld via:

contractuele afspraken;
SLA’s;
cyberverzekeringen.

Iedere beslissing wordt:

gedocumenteerd;
toegewezen aan een verantwoordelijke;
opgenomen in een implementatieplanning.

Zo ontstaat duidelijke verantwoordelijkheid binnen de gehele organisatie.

Continue monitoring

Het proces stopt niet nadat de eerste risico’s zijn aangepakt.

Softwaretoeleveringsketens veranderen voortdurend.

Vrijwel dagelijks ontstaan:

nieuwe kwetsbaarheden;
software-updates;
licentiewijzigingen;
nieuwe leveranciers;
extra afhankelijkheden.

Daarom vormt continue monitoring een essentieel onderdeel van het CATS Framework.

Geautomatiseerde tools vergelijken de actuele SBOM continu met:

nieuw gepubliceerde CVE’s;
gewijzigde licentievoorwaarden;
nieuwe softwareversies;
leveranciersadviezen.

Wanneer actie nodig is, worden ontwikkelteams automatisch geïnformeerd.

Daardoor worden kwetsbaarheden niet pas tijdens een jaarlijkse audit ontdekt, maar als onderdeel van het dagelijkse ontwikkelproces.

Governance en continue verbetering

Naarmate de organisatie volwassener wordt, groeit het SBOM-proces uit tot een integraal onderdeel van de bedrijfsvoering.

Onder andere worden dan structureel ingevoerd:

periodieke leveranciersbeoordelingen;
dreigingsmodellering tijdens architectuurontwerp;
een volledig geïntegreerde Secure SDLC;
periodieke managementreviews;
KPI’s en meetbare prestatie-indicatoren.

Voorbeelden van managementindicatoren zijn:

aantal kritieke kwetsbaarheden;
leveranciersrisicoscores;
SBOM-dekking;
Mean Time To Remediate (MTTR);
compliance-status.

Hierdoor verandert compliance van een eenmalig project naar een continu managementproces dat wordt ondersteund door objectief bewijs.

Waarom de SBOM slechts het begin is

Dit laat zien waarom het CATS Framework de Software Bill of Materials beschouwt als een startpunt en niet als het einddoel.

De werkelijke waarde ligt niet in het produceren van nóg een document.

De waarde ontstaat door een herhaalbaar proces te creëren dat:

continu inzicht biedt in de softwaretoeleveringsketen;
technische bevindingen vertaalt naar bedrijfsrisico’s;
het management ondersteunt bij objectieve en verdedigbare cybersecuritybeslissingen gedurende de volledige levenscyclus van software.

Conclusie

Nu organisaties in heel Europa zich voorbereiden op de Cyber Resilience Act, is het belangrijk te beseffen dat compliance zelden wordt bereikt door simpelweg nóg een document op te stellen. Werkelijke compliance ontstaat door herhaalbare processen te implementeren die technische informatie omzetten in goed onderbouwde zakelijke beslissingen.