Supply chain security is het geheel van maatregelen waarmee een organisatie de integriteit, herkomst en kwetsbaarhedenstatus bewaakt van alle softwarecomponenten in haar informatieomgeving, van het besturingssysteem tot de kleinste npm-package. Met de komst van de Cyber Resilience Act (Verordening 2024/2847) en de uitgebreide scope van NIS-2 is dit geen intern IT-vraagstuk meer, maar een afdwingbare wettelijke verplichting voor duizenden Europese organisaties.
Wat is een SBOM en welke wet verplicht u er een bij te houden?
Een Software Bill of Materials (SBOM) is een gestructureerde, machineleesbare inventarislijst van alle softwarecomponenten, bibliotheken, afhankelijkheden en hun versienummers die samen een applicatie of systeem vormen. Vergelijkbaar met een ingrediëntenlijst op een voedselverpakking maakt een SBOM inzichtelijk wat er precies “in” uw software zit.
De Cyber Resilience Act (CRA, Verordening 2024/2847), in oktober 2024 aangenomen door de Raad van de Europese Unie, verplicht fabrikanten van producten met digitale elementen om gedurende de gehele levenscyclus van een product een actuele SBOM bij te houden en beschikbaar te stellen. De CRA geldt voor hardware en software die in de EU op de markt wordt gebracht en heeft directe werking in alle lidstaten. Organisaties die als “essentieel” of “belangrijk” zijn geclassificeerd onder NIS-2 (Richtlijn 2022/2555) zijn daarnaast verplicht toeleveringsketenrisico’s systematisch te beheersen, wat in de praktijk het opvragen en beoordelen van SBOMs van leveranciers vereist.
“An SBOM is not a compliance checkbox. It is the foundation on which you build your entire vulnerability management programme.” — Allan Friedman, senior-adviseur CISA en grondlegger van het SBOM-raamwerk (bron: CISA SBOM-documentatie, cisa.gov)
Risico’s van Amerikaanse open-source afhankelijkheden
De meeste moderne softwareomgevingen zijn doordrenkt van componenten die worden beheerd of gehost door Amerikaanse partijen, van Node.js-packages op npm tot Python-bibliotheken op PyPI. Dit brengt specifieke risico’s mee voor Europese organisaties die streven naar digitale soevereiniteit.
Ten eerste zijn er juridische risico’s. De Amerikaanse CLOUD Act (2018) en de Foreign Intelligence Surveillance Act (FISA) geven Amerikaanse autoriteiten de bevoegdheid om van in de VS gevestigde bedrijven, waaronder de beheerders van npm en PyPI, informatie te vorderen of zelfs stille toegang te verplichten. Als een update-server of telemetriedienst van een component die u gebruikt onder Amerikaans recht valt, kunt u niet uitsluiten dat er gegevens worden doorgegeven zonder uw medeweten.
Ten tweede zijn er operationele integriteitsrisico’s. Het aantal kwaadaardige packages dat in 2023 werd ontdekt op npm en PyPI steeg met circa 200 procent ten opzichte van het jaar daarvoor, aldus het OpenSSF-rapport “State of Open Source Security 2023” (openssf.org). Aanvallers plaatsen packages met namen die lijken op legitieme bibliotheken (typosquatting) of compromitteren de accounts van legitieme beheerders. Zonder SBOM weet u niet welke versies u gebruikt en kunt u niet snel reageren op een compromittering.
| Risicocategorie | Voorbeeld | Mitigatie via SBOM |
|---|---|---|
| Juridische blootstelling (CLOUD Act) | Update-server van component onder US-jurisdictie | Identificeer en vervang of isoleer componenten met US-afhankelijkheden |
| Kwaadaardige packages (typosquatting) | Valse npm-package met nagenoeg identieke naam | Pin exacte versies en verifieer checksums via SBOM |
| Licentie-risico | GPL-component in propriëtair product | Automatische licentiecheck via OpenChain ISO/IEC 5230 |
| End-of-life afhankelijkheden | Niet meer ondersteunde bibliotheek met bekende CVEs | Continue monitoring van SBOM-componenten tegen CVE-databases |
Risicoanalyse van uw softwaretoeleveringsketen
Een effectieve risicoanalyse van de supply chain begint met volledige inventarisatie en eindigt met een continu monitoringproces. De stappen hieronder zijn afgestemd op de vereisten van de CRA en NIS-2.
Stap 1: Genereer een volledige SBOM
Gebruik geautomatiseerde tooling zoals Syft, Trivy of OWASP Dependency-Track om voor elke applicatie en infrastructuurcomponent een SBOM te genereren in SPDX- of CycloneDX-formaat. Beide formaten zijn door ENISA erkend. Voer dit niet eenmalig uit, maar integreer het in uw CI/CD-pipeline zodat de SBOM bij elke release automatisch wordt bijgewerkt.
Stap 2: Koppel SBOM-data aan CVE-feeds
Koppel de gegenereerde SBOM aan het National Vulnerability Database (NVD) van NIST en de ENISA-kwetsbaarhedendatabank. Stel drempelwaarden in op basis van CVSS-scores: kwetsbaarheden met een score van 9 of hoger vereisen onmiddellijke actie. Volgens ENISA was in 2024 meer dan 60 procent van de significante cyberincidenten bij Europese organisaties te herleiden tot een kwetsbaarheid in de softwaretoeleveringsketen (ENISA Threat Landscape 2024, enisa.europa.eu).
Stap 3: Beoordeel herkomst en juridische jurisdictie
Documenteer per kritieke component: waar is de beherende organisatie gevestigd, onder welk recht valt de updateinfrastructuur, en bestaat er een history van gedwongen medewerking aan overheidsdiensten? Voor on-premise en Europees gehoste oplossingen is dit bijzonder relevant wanneer componenten afhankelijk zijn van Amerikaanse telemetrie- of activatieservers.
“Supply chain attacks have become the new norm. Organisations that cannot enumerate what software components they run are flying blind when a new critical vulnerability emerges.” — Juhan Lepassaar, uitvoerend directeur ENISA (bron: ENISA Threat Landscape 2024 persbericht, enisa.europa.eu)
Verplichtingen onder de Cyber Resilience Act: updates en kwetsbaarhedenbeheer
De CRA legt fabrikanten van digitale producten verplichtingen op die verder gaan dan het produceren van een SBOM. Kwetsbaarheden moeten actief worden bijgehouden en gerapporteerd: de CRA (Verordening 2024/2847) stelt fabrikanten verplicht kwetsbaarheden actief te rapporteren binnen 24 uur na ontdekking aan ENISA en de nationale CSIRT (eur-lex.europa.eu). Dit heeft directe gevolgen voor organisaties die eigen software ontwikkelen of bestaande open-source software bundelen en als product uitleveren.
Voor afnemers betekent dit dat u van uw leveranciers contractueel moet vastleggen dat zij tijdig patches uitbrengen, dat de SBOM bij elke update wordt bijgewerkt, en dat kwetsbaarhedenmeldingen aan u worden doorgegeven. Wie dit niet regelt, loopt risico dat een bekende kwetsbaarheid in een geleverd product maandenlang onopgemerkt blijft.
Aantonen dat uw softwareketen vrij is van achterdeurtjes
Volledige zekerheid is technisch nooit haalbaar, maar er zijn aantoonbare maatregelen die u kunt nemen en die worden erkend door toezichthouders en auditors.
Ten eerste is er auditeerbare broncode. Open-source software waarvan de broncode openbaar beschikbaar is en regelmatig onafhankelijk wordt geauditeerd, biedt meer transparantie dan gesloten software. Initiatieven zoals de Linux Foundation Core Infrastructure Initiative (CII) financieren beveiligingsaudits van kritieke open-source projecten.
Ten tweede is er reproduceerbare builds. Een reproduceerbare build garandeert dat een specifieke versie van broncode altijd resulteert in een identiek binair bestand. Dit maakt het onmogelijk om na compilatie stille wijzigingen in te voegen. Debian GNU/Linux en de Tor Browser zijn voorbeelden van projecten die reproduceerbare builds actief implementeren.
Ten derde biedt OpenChain ISO/IEC 5230 een erkend raamwerk voor open-source compliance. Certificering conform OpenChain toont aan dat u systematisch licentie- en beveiligingsverplichtingen beheert voor alle open-source componenten, wat richting auditors en aanbestedende diensten geldt als bewijs van een gecontroleerde softwareketen (openchainproject.org).
Ten vierde kunt u bij kritieke infrastructuur eisen dat leveranciers verklaren onder welk recht zij vallen, of zij ooit verplicht zijn meegewerkt aan inlichtingenverzoeken, en of zij een “canary statement” publiceren. Zwitserland en de EU kennen geen equivalent van de Amerikaanse National Security Letter, waardoor Europees of Zwitsers gehoste en ontwikkelde software een lagere juridische blootstelling heeft.
Europese initiatieven voor soevereine open-source infrastructuur
De erkenning dat kritieke open-source infrastructuur onderfinancierd is en daarmee een strategisch risico vormt, heeft geleid tot concrete Europese initiatieven.
Het Sovereign Tech Fund (Duitsland) investeert in de beveiliging, moderne ontwikkelpraktijken en duurzaamheid van open-source infrastructuur die breed wordt gebruikt maar onvoldoende middelen heeft. Denk aan bibliotheken als curl, OpenSSH en kritieke cryptografische tools. Het fonds richt zich bewust op fundamentele infrastructuurcomponenten die in vrijwel elke softwareketen voorkomen (sovereigntechfund.de).
IPCEI-CIS (Important Project of Common European Interest, Cloud Infrastructure and Services) is een grootschalig Europees samenwerkingsprogramma dat als doel heeft een Europese cloud- en edge-infrastructuur te ontwikkelen die niet afhankelijk is van niet-Europese technologiebedrijven. Deelnemende landen financieren gezamenlijk de ontwikkeling van interoperabele, soevereine cloudoplossingen die voldoen aan de hoogste Europese normen voor beveiliging en gegevensbescherming (ec.europa.eu).
Daarnaast financiert de Europese Commissie via Horizon Europe en het programma Digital Europe specifiek onderzoek naar kwantumveilige cryptografie, open-source beveiligingsauditcapaciteit en de verdere ontwikkeling van SBOM-standaarden. Deze financiering is gericht op het verkleinen van de strategische afhankelijkheid van niet-Europese technologie, niet alleen op het niveau van data maar ook op het niveau van de onderliggende softwareketen.
Van beleid naar praktijk: migratie naar een soevereine softwareketen
Organisaties die migreren van Amerikaanse clouddiensten naar Europese of on-premise alternatieven, zoals van Microsoft 365 naar een Nextcloud-omgeving gehost in de EU of Zwitserland, lossen niet automatisch hun supply chain security-vraagstuk op. Nextcloud is open-source en auditeerbaar, maar ook Nextcloud maakt gebruik van PHP-bibliotheken, JavaScript-componenten en systeempakketten die hun eigen afhankelijkheden hebben. Een SBOM die de gehele stack dekt, is ook voor open-source omgevingen noodzakelijk.
De praktische aanpak voor compliance officers en IT-beslissers is: begin met een volledige SBOM van uw huidige en toekomstige omgeving, koppel die aan continue kwetsbaarheidsmonitoring, eis SBOM-documentatie contractueel van al uw softwareleveranciers, en zorg dat uw updateproces aantoonbaar en auditeerbaar is. Dit is de basis waarop u zowel NIS-2- als CRA-compliance kunt aantonen en waarbij u ook juridisch kunt onderbouwen dat uw omgeving vrij is van bekende afhankelijkheden van buitenlandse inlichtingendiensten.
Veelgestelde vragen
Moet iedere organisatie een SBOM produceren of alleen softwarefabrikanten?
De Cyber Resilience Act legt de primaire verplichting bij fabrikanten van producten met digitale elementen. Organisaties die uitsluitend software afnemen, moeten wél van hun leveranciers eisen dat zij een actuele SBOM aanleveren. Onder NIS-2 zijn essentiële en belangrijke entiteiten bovendien verplicht de risico’s in hun toeleveringsketen te beheersen, wat het opvragen en beoordelen van SBOMs in de praktijk noodzakelijk maakt.
Zijn open-source componenten per definitie veiliger dan propriëtaire software?
Niet per definitie. Open-source code is inspecteerbaar, wat onafhankelijke audit mogelijk maakt, maar veel veelgebruikte packages worden onderhouden door één vrijwilliger zonder formeel beveiligingsproces. De Log4Shell-kwetsbaarheid in 2021 illustreerde dat zelfs breed gebruikte open-source bibliotheken jarenlang kritieke fouten kunnen bevatten. Transparantie en gemeenschapsgrootte zijn betere indicatoren dan het open- of gesloten karakter van de code.
Welk SBOM-formaat wordt aanbevolen: SPDX of CycloneDX?
Beide formaten zijn door ENISA en de Europese Commissie erkend. SPDX (ISO/IEC 5962) is de ISO-norm en sterk in licentie-informatie; CycloneDX is lichter en wijdverspreid in DevSecOps-toolchains. De Cyber Resilience Act schrijft geen specifiek formaat voor, maar verlangt machineleesbare en actuele documentatie. Veel organisaties genereren beide formaten automatisch via tooling zoals Syft of Trivy.
Wat betekent de CLOUD Act concreet voor een Europese organisatie die Amerikaanse open-source tools gebruikt?
De CLOUD Act geeft Amerikaanse autoriteiten de bevoegdheid om van Amerikaanse bedrijven toegang te eisen tot data, ongeacht waar die data fysiek is opgeslagen. Als uw on-premise omgeving afhankelijk is van update-servers, telemetrie of licentievalidatie bij een Amerikaans bedrijf, bestaat er een juridisch risico op gedwongen informatieverstrekking. Een SBOM helpt u te identificeren welke componenten dergelijke afhankelijkheden hebben, zodat u bewuste keuzes kunt maken.
Hoe helpt OpenChain ISO/IEC 5230 bij het aantonen van supply chain compliance?
OpenChain ISO/IEC 5230 specificeert de minimumvereisten voor een effectief open-source complianceprogramma binnen een organisatie. Certificering toont aan dat u systematisch licentie- en beveiligingsverplichtingen beheert voor alle open-source componenten in uw producten. Dit is erkend bewijs richting auditors, inkopers en toezichthouders dat uw softwareketen gecontroleerd en gedocumenteerd is.
