NIS2 heeft ketenbeveiliging veranderd van goede praktijk naar wettelijke verplichting. Artikel 21(2)(d) van de richtlijn vereist dat essentiële en belangrijke entiteiten risico's beheersen die voortkomen uit leveranciers en dienstverleners, en een Software Bill of Materials (SBOM) wordt snel de praktische manier om aan te tonen dat aan deze verplichting wordt voldaan. Voor organisaties die al bezig zijn met NIS2-compliance, is SBOM-beheer vaak het ontbrekende stuk tussen een governancebeleid en bewijs dat een toezichthouder daadwerkelijk accepteert.
Deze gids zet uiteen wat NIS2 en de EU Cyber Resilience Act (CRA) daadwerkelijk vereisen op het gebied van softwaretransparantie, hoe de twee regelgevingen zich tot elkaar verhouden, wie binnen de scope valt, en de praktische stappen om SBOM-beheer te integreren in een bestaand complianceprogramma in plaats van het te behandelen als een eenmalige spreadsheetoefening.
Wat is een Software Bill of Materials (SBOM)?
Een Software Bill of Materials, of SBOM, is een gestructureerde inventarisatie van elke component waaruit een stuk software bestaat: open-sourcebibliotheken, third-partypakketten en hun specifieke versies. Simpel gezegd is het een ingrediëntenlijst voor software. Net zoals een voedseletiket elk ingrediënt in een product vermeldt zodat een consument kan controleren op allergenen, onthult een SBOM elke component in een applicatie zodat een organisatie kan controleren op bekende kwetsbaarheden.
Voor een compliance officer of CISO zit de waarde niet in het software engineering-detail; die zit in de zichtbaarheid. Moderne applicaties zijn doorgaans opgebouwd uit honderden open-source- en third-partycomponenten, waarvan de meeste door niemand in de organisatie direct zijn beoordeeld. Wanneer een kwetsbaarheid wordt bekendgemaakt, is de eerste vraag die een bestuur, een toezichthouder of een verzekeraar stelt simpel: is de organisatie getroffen, en waar? Zonder SBOM betekent het beantwoorden van die vraag handmatig elke leverancier en elk ontwikkelteam benaderen, een proces dat dagen kan duren. Met een SBOM duurt het minuten — precies het soort zichtbaarheid in de softwareketen dat NIS2 en de CRA nu van organisaties verwachten vóórdat een incident plaatsvindt, niet erna.
Wat vereist NIS2 voor SBOM's?
NIS2 zelf gebruikt de term "Software Bill of Materials" niet. De richtlijn is bewust doelgericht in plaats van voorschrijvend over specifieke tools of documenten, wat een van de redenen is waarom SBOM-vereisten vaak over het hoofd worden gezien bij eerste gap-assessments. Kijk echter naar de uitvoeringsdetails, en de verwachting wordt expliciet.
Uitvoeringsverordening (EU) 2024/2690 van de Commissie, die de technische en methodologische vereisten vastlegt voor de cybersecurity-risicomanagementmaatregelen in artikel 21, verplicht essentiële en belangrijke entiteiten die bepaalde digitale infrastructuur en ICT-diensten leveren om informatie bij te houden die de hardware- en softwarecomponenten beschrijft die worden gebruikt in de netwerk- en informatiesystemen die hun dienst ondersteunen. In de praktijk is die beschrijving in alles behalve naam een SBOM.
De onderliggende verplichting staat in artikel 21(2)(d) van NIS2, dat ketenbeveiliging — inclusief beveiligingsgerelateerde aspecten van de relaties tussen een entiteit en haar directe leveranciers of dienstverleners — vermeldt als een van de tien minimale risicomanagementmaatregelen die elke organisatie binnen de scope moet implementeren. Risico's in de softwareketen, waarbij een kwetsbaarheid in een third-party- of open-sourcecomponent een toegangspunt wordt tot de eigen systemen van een organisatie, vallen daar nadrukkelijk onder.
ENISA, het Agentschap van de Europese Unie voor cyberbeveiliging, gaat in eigen richtlijnen nog verder en omschrijft SBOM-beheer als een van de weinige daadwerkelijk effectieve methoden om softwareketenbeveiliging op schaal te beheren. Die aanbeveling weegt zwaar: nationale bevoegde autoriteiten die NIS2 handhaven, kijken naar ENISA-richtlijnen bij het beoordelen of de risicomanagementmaatregelen van een entiteit "passend en proportioneel" zijn, de wettelijke norm die artikel 21(1) stelt.
Er is ook een directe operationele link met incidentrapportage. Artikel 23 vereist dat essentiële en belangrijke entiteiten binnen 24 uur na het bekend worden van een significant incident een vroegtijdige waarschuwing indienen, gevolgd door een gedetailleerdere melding binnen 72 uur. Wanneer een nieuwe kwetsbaarheid wordt bekendgemaakt in een veelgebruikte component, heeft een organisatie zonder SBOM geen snelle manier om te bepalen of ze is getroffen. Een organisatie met een SBOM kan deze binnen enkele minuten raadplegen, elk getroffen systeem identificeren en binnen het 24-uursvenster reageren met een antwoord dat is gebaseerd op bewijs in plaats van aannames.
NIS2 vs CRA: SBOM-eisen vergeleken
NIS2 is niet de enige EU-regelgeving die softwaretransparantie raakt, en de verschillen zijn relevant bij het scopen van een complianceprogramma. Onderstaande tabel zet uiteen hoe NIS2, de Cyber Resilience Act en DORA elk omgaan met SBOM's.
| Vereiste | NIS2 | CRA | DORA |
|---|---|---|---|
| SBOM expliciet genoemd? | Nee — impliciet via art. 21(2)(d) en Uitvoeringsverordening (EU) 2024/2690 | Ja — expliciete verplichting | Nee — geadresseerd via ICT-derdenrisicobeheer |
| Wie valt binnen de scope | Essentiële en belangrijke entiteiten in 17 sectoren | Fabrikanten van producten met digitale elementen die op de EU-markt worden gebracht | Financiële entiteiten en hun kritieke ICT-leveranciers |
| Verwacht formaat | Niet voorgeschreven; in de praktijk CycloneDX of SPDX | Machineleesbaar; CycloneDX en SPDX worden aangehaald, BSI TR-03183-2 als technische baseline | Niet voorgeschreven; beoordeeld via derdenrisicoregisters |
| Belangrijkste deadline | Van kracht sinds oktober 2024 | Kwetsbaarheidsrapportage vanaf september 2026; volledige SBOM-verplichtingen vanaf december 2027 | Van kracht sinds januari 2025 |
| Vereiste diepgang | Directe leveranciersrelaties | Minimaal top-level dependencies bij eerste release | Informatieregister over alle ICT-regelingen |
De Cyber Resilience Act is van de drie het meest expliciet. Fabrikanten van "producten met digitale elementen" moeten een machineleesbare SBOM opstellen die op zijn minst de top-level dependencies van een product dekt, in CycloneDX- of SPDX-formaat. Duitsland's BSI heeft TR-03183-2 gepubliceerd als een veelgebruikte technische baseline voor wat een compliant SBOM moet bevatten, en dit wordt in toenemende mate gezien als goede praktijk in de hele EU, ook buiten Duitsland. De verplichtingen voor kwetsbaarheidsbeheer en -rapportage onder de CRA gelden vanaf september 2026, waarbij de volledige SBOM- en technische-documentatievereisten volgen vanaf december 2027.
Voor organisaties die al bezig zijn met DORA-compliance in de financiële sector, is het praktische verschil scope in plaats van intentie: DORA vouwt softwaretransparantie in binnen haar bredere ICT-derdenrisicobeheer en informatieregistervereisten, in plaats van een SBOM met naam te verplichten. Een organisatie die SBOM-capaciteit opbouwt voor NIS2 of de CRA, bouwt in feite dezelfde capaciteit op die DORA verwacht van haar gereguleerde financiële entiteiten en hun kritieke ICT-leveranciers.
Wie moet compliant zijn?
NIS2 is van toepassing op organisaties die zijn geclassificeerd als essentiële of belangrijke entiteiten in 17 sectoren, variërend van energie, transport en bankwezen tot digitale infrastructuur, gezondheidszorg en de productie van bepaalde kritieke producten. De classificatie bepaalt de intensiteit van het toezicht waaraan een organisatie is onderworpen, maar de onderliggende risicomanagementverplichtingen, waaronder ketenbeveiliging, gelden voor beide categorieën.
De scope wordt over het algemeen bepaald door omvang: middelgrote en grote entiteiten die voldoen aan of de EU-drempels overschrijden van 50 werknemers of €10 miljoen jaaromzet of balanstotaal, vallen doorgaans binnen de scope, naast specifieke categorieën entiteiten die ongeacht omvang binnen de scope vallen, zoals aanbieders van openbare elektronische-communicatienetwerken, trustdiensten en DNS-infrastructuur. Organisaties met hoofdkantoor buiten de EU zijn niet vrijgesteld: aanbieders die buiten de Unie zijn gevestigd en diensten aanbieden binnen de EU, moeten een EU-vertegenwoordiger aanwijzen en zijn onderworpen aan dezelfde verplichtingen.
Een aspect van NIS2 dat consequent de aandacht van een compliance officer trekt, is persoonlijke aansprakelijkheid. In tegenstelling tot een groot deel van het bestaande EU-regelgevingslandschap maakt NIS2 bestuursorganen direct verantwoordelijk voor het goedkeuren en toezien op cybersecurity-risicomanagementmaatregelen, waaronder ketenbeveiliging, en nationale autoriteiten hebben de bevoegdheid om individuele bestuursleden en senior management aansprakelijk te stellen voor non-compliance. Die verantwoordingsplicht is een sterke praktische reden waarom zichtbaarheid in de softwareketen, en het SBOM-programma dat dit ondersteunt, gedocumenteerd en verdedigbaar moet zijn, niet alleen technisch correct.
SBOM-beheer implementeren voor NIS2
1. Inventariseer je softwarelandschap
Voordat er voor wat dan ook een SBOM kan worden gegenereerd, heeft de organisatie een helder beeld nodig van het softwarelandschap dat daadwerkelijk bestaat: intern gebouwde applicaties, kant-en-klare commerciële software, en de clouddiensten en platformen die kritieke bedrijfsprocessen ondersteunen. Veel organisaties ontdekken in deze fase dat geen enkel team een volledige inventarisatie bezit, omdat inkoop, engineering en IT-operations vaak afzonderlijke, gedeeltelijke lijsten bijhouden. Behandel deze stap net zo goed als governance-oefening als als technische oefening: de inventarisatie moet elk systeem koppelen aan het bedrijfsproces en de NIS2-verplichting die het ondersteunt, zodat de SBOM-inspanning kan worden geprioriteerd op risico in plaats van op gemak.
2. Genereer SBOM's voor kritieke assets
In plaats van te proberen op dag één voor elk systeem een SBOM te produceren, prioriteer je assets die essentiële of belangrijke diensten ondersteunen, of die bij compromittering NIS2-incidentrapportageverplichtingen zouden triggeren. De meeste moderne buildtools en containerregisters kunnen automatisch een CycloneDX- of SPDX-SBOM genereren als onderdeel van het bestaande releaseproces, dus de praktische inspanning zit meestal in integratie in plaats van handmatige documentatie. Begin met nieuw gebouwde of actief onderhouden systemen, en werk vervolgens terug naar legacy- en third-partycomponenten, die doorgaans nauwere betrokkenheid van leveranciers vereisen.
3. Integreer met kwetsbaarhedenbeheer
Een SBOM creëert pas waarde zodra deze is gekoppeld aan een bron van kwetsbaarheidsinformatie. Het matchen van componentinventarissen met feeds zoals de National Vulnerability Database of leveranciersbeveiligingsadviezen verandert een statisch document in een early-warning-systeem: zodra een nieuwe kwetsbaarheid wordt bekendgemaakt voor een gebruikte component, zijn de getroffen systemen al bekend. Dit is de verbinding tussen SBOM-beheer en de 24-uursrapportageklok van artikel 23 van NIS2, en het is waar het grootste deel van de praktische tijdwinst wordt gerealiseerd.
4. Stel SBOM-eisen voor leveranciers vast
Artikel 21(2)(d) breidt ketenbeveiligingsverplichtingen expliciet uit naar relaties met directe leveranciers en dienstverleners. In de praktijk betekent dit dat SBOM-levering wordt ingebouwd in leverancierscontracten en onboarding: nieuwe softwareleveranciers zouden verplicht moeten worden om samen met hun product een machineleesbare SBOM te leveren, op dezelfde manier waarop van hen al wordt verwacht dat ze beveiligingsdocumentatie of een audit-recht-clausule aanleveren. Voor bestaande leveranciers is een gefaseerde aanvraagcampagne, geprioriteerd op kriticiteit, realistischer dan één blanket verzoek.
5. Koppel aan incident response-workflows
Ten slotte moet de SBOM onderdeel zijn van het incident response-proces, niet ernaast staan. Wanneer een significant incident wordt vastgesteld, moet het reagerende team de SBOM direct kunnen raadplegen om vast te stellen welke systemen en diensten zijn getroffen, wat rechtstreeks doorwerkt in de impactanalyse die vereist is voor de 24-uurs- en 72-uursrapportagetermijnen van NIS2. Wanneer SBOM-data in een spreadsheet staat, losgekoppeld van de incident management-tooling, is dit de stap die onder tijdsdruk onvermijdelijk wordt overgeslagen.
Van SBOM naar continue assurance
Een SBOM die één keer wordt geproduceerd en opgeborgen, beantwoordt een compliancevraag voor één specifiek moment. Zes maanden later, nadat nieuwe releases, nieuwe kwetsbaarheden en nieuwe leveranciers het beeld hebben veranderd, beantwoordt die SBOM de vraag niet meer. Hier maakt het behandelen van SBOM-beheer als continu proces, in plaats van een eenmalig product, het verschil tussen een document dat een auditor tolereert en bewijs dat een toezichthouder vertrouwt.