Open-source softwareafhankelijkheden zijn componenten van derden, bibliotheken en raamwerken die een applicatie nodig heeft om te functioneren, maar die worden ontwikkeld en beheerd buiten de eigen organisatie. In soevereine werkplekarchitecturen, zoals een on-premise Nextcloud-omgeving bedoeld om jurisdictierisico’s van Amerikaanse cloudproviders te vermijden, introduceren deze afhankelijkheden nieuwe, vaak onzichtbare risico’s op het gebied van geopolitieke afhankelijkheid, eigendomsstructuur en bijdragersdiversiteit. De Cyber Resilience Act (CRA) en de NIS-2-richtlijn verplichten organisaties nu voor het eerst systematisch verantwoording af te leggen over deze risico’s.
Waarom “open source” geen garantie is voor soevereiniteit
Een vrije licentie garandeert toegang tot de broncode, maar zegt niets over de juridische of geopolitieke context waarbinnen de software wordt ontwikkeld en onderhouden.
Een Nextcloud-installatie steunt op tientallen onderliggende open-source componenten: de PHP-runtime, de database-abstractielaag Doctrine DBAL, cryptografische bibliotheken zoals OpenSSL, en samenwerkingsprotocollen zoals CalDAV en CardDAV. Veel van deze componenten worden primair onderhouden door ontwikkelaars bij Amerikaanse technologiebedrijven, of door individuen in landen buiten de EU zonder formele governance-structuren.
De Europese Commissie liet dit in kaart brengen via haar studie naar kritieke open-source componenten in het kader van de EU Open Source Strategy 2026. De conclusie was ongemakkelijk: meer dan de helft van de door de EC onderzochte kritieke OSS-projecten heeft een bijdragersbasis die gedomineerd wordt door niet-EU-landen, waaronder de VS en China (Europese Commissie, studie ‘Open Source Software Country of Origin and Supply Chain Risks’, 2023). Voor een overheidsorganisatie die bewust kiest voor Nextcloud om de CLOUD Act te vermijden, betekent dit dat de toeleveringsketen van de software zelf een restrisico vormt dat apart geadresseerd moet worden.
Concentratie- en jurisdictierisico’s in soevereine architecturen
Concentratierisico ontstaat wanneer meerdere kritieke systemen afhankelijk zijn van dezelfde bovenliggende component of hetzelfde ecosysteem, met als gevolg dat een enkele kwetsbaarheid of geopolitieke verstoring een keten van systemen treft.
In de context van soevereine werkplekken zijn vier categorieën van bijzonder belang:
| Componentcategorie | Voorbeelden | Typisch jurisdictierisico |
|---|---|---|
| Cryptografische bibliotheken | OpenSSL, BoringSSL, LibreSSL | BoringSSL beheerd door Google (VS); OpenSSL Foundation formeel internationaal maar kernbijdragers grotendeels VS |
| Containerisatie en orchestratie | containerd, runc, Kubernetes | Kubernetes governance via CNCF, gevestigd in de VS; meeste Steering Committee-leden werken bij Amerikaanse techbedrijven |
| Identiteits- en authenticatiebibliotheken | Keycloak, LDAP-bibliotheken, SAML-parsers | Keycloak wordt primair gesponsord door Red Hat (onderdeel van IBM, VS) |
| Pakketregisters en build-tooling | npm, PyPI, Composer | npm beheerd door GitHub (Microsoft, VS); PyPI door Python Software Foundation (VS) |
Het risico zit niet uitsluitend in de code zelf, maar ook in de update- en distributie-infrastructuur. Wanneer een kritieke beveiligingspatch via een Amerikaans pakketregister wordt gedistribueerd, loopt een Europese overheidsorganisatie theoretisch het risico dat de integriteit van die update via buitenlandse juridische instrumenten wordt beïnvloed.
CRA en NIS-2: de wettelijke verankering van SBOM-transparantie
De Cyber Resilience Act (Verordening (EU) 2024/2847) introduceert voor het eerst een Europese wettelijke verplichting rond Software Bills of Materials (SBOM’s) voor producten met digitale elementen.
Artikel 13 CRA verplicht fabrikanten om een nauwkeurige en actuele documentatie bij te houden van alle softwarecomponenten, inclusief open-source afhankelijkheden. Artikel 14 CRA verplicht hen deze informatie beschikbaar te stellen aan nationale autoriteiten en, na een kwetsbaarheid, aan betrokken partijen. Het Europees Parlement en de Raad formuleerden dit als volgt:
“De CRA verplicht fabrikanten van producten met digitale elementen om een nauwkeurige software bill of materials bij te houden en beschikbaar te stellen, zodat kwetsbaarheden in de toeleveringsketen snel kunnen worden gelokaliseerd en verholpen.” (Cyber Resilience Act, Verordening (EU) 2024/2847)
Voor inkopers en compliance officers betekent dit concreet: elke leverancier van software die in een soevereine architectuur wordt geïntegreerd, moet aantoonbaar een SBOM kunnen aanleveren. De aanbevolen technische standaard hiervoor is CycloneDX, ontwikkeld door OWASP. CycloneDX is bijzonder geschikt voor security-use cases omdat het naast componentinformatie ook kwetsbaarhedenreferenties (via VEX-documenten) en exploitability-metadata bevat.
NIS-2 artikel 21 verplicht essentiële en belangrijke entiteiten tot het beheersen van beveiligingsrisico’s in hun toeleveringsketen. Artikel 22 biedt de Europese Commissie de bevoegdheid om per sector aanvullende eisen vast te stellen voor kritieke afhankelijkheden. ENISA werkte dit verder uit in haar Supply Chain Cybersecurity Good Practices (2023), waarin staat dat circa 60% van de onderzochte organisaties geen volledige inventarisatie heeft van open-source componenten in hun toeleveringsketen (ENISA, 2023). Dit tekort maakt het onmogelijk om tijdig te reageren op kwetsbaarheden zoals de Log4Shell-crisis in 2021.
Niet-technische risicofactoren voor compliance officers
Naast de technische samenstelling van een open-source component zijn er drie niet-technische risicofactoren die een compliance officer systematisch moet beoordelen bij kritieke systemen.
Eigendomsstructuur en rechtspersoon: Is het project ondergebracht bij een stichting (zoals de Apache Software Foundation of de Linux Foundation), een commercieel bedrijf, of bestaat er geen formele rechtspersoon? Commerciële stewardship brengt een concentratierisico mee als die organisatie wordt overgenomen of onderhevig is aan buitenlandse wetgeving.
Bijdragersdiversiteit en nationaliteitsspreiding: Projecten waarbij één werkgever of één land meer dan 50% van de actieve commits levert, kennen een feitelijk monopolie op de ontwikkelrichting. De EC-studie naar kritieke open-source componenten gebruikte commit-analyse als een van de primaire indicatoren voor geopolitiek afhankelijkheidsrisico.
Financieringsbronnen en subsidiëring: Software die primair gefinancierd wordt door Amerikaanse techbedrijven, overheidscontracten uit de VS, of durfkapitaal onder Amerikaans recht, heeft een structurele afhankelijkheid die losstaat van de licentie. ENISA benadrukt in haar Good Practices (2023) dat financieringstransparantie een vereiste is voor risicobeoordeling van open-source afhankelijkheden in kritieke infrastructuur.
“Open-source software is de ruggengraat van het digitale ecosysteem, maar het ontbreken van systematisch beheer van afhankelijkheden vormt een structureel risico voor de weerbaarheid van kritieke infrastructuur in Europa.” (ENISA, Supply Chain Cybersecurity Good Practices, 2023)
Europese governancemodellen als tegenwicht
De Europese Commissie en lidstaten ontwikkelen verschillende mechanismen om de geopolitieke afhankelijkheidsrisico’s van kritieke open-source infrastructuur te verminderen.
Het Digital Commons EDIC (European Digital Infrastructure Consortium) is een samenwerkingsmodel waarbij EU-lidstaten gezamenlijk kritieke open-source infrastructuur kunnen financieren, onderhouden en besturen. Binnen een EDIC kunnen overheden als mede-eigenaar optreden van de governance-structuur, zodat beslissingen over de software-roadmap niet uitsluitend afhangen van commerciële partijen buiten de EU.
De EU-beheerde fork is een meer radicale optie: wanneer een kritiek project onvoldoende bestuurlijk onafhankelijk is, kan een Europees consortium een eigen beheerde tak van de broncode aanhouden, met eigen releaseprocessen, auditverplichtingen en security patches. Dit vergroot de inspanningsdrempel aanzienlijk, maar biedt de hoogste mate van bestuurlijke onafhankelijkheid.
Bug-bountyprogramma’s vormen een meer pragmatische aanvulling. De Europese Commissie financierde eerder via het programma FOSSA (Free and Open Source Software Audit) gerichte beveiligingsaudits en bug-bounties voor kritieke open-source projecten die door EU-instellingen worden gebruikt. Dit model verbetert de beveiligingskwaliteit zonder dat een volledig fork nodig is.
Ten slotte biedt de EU Open Source Strategy 2026 een beleidsraamwerk dat de Europese Commissie verplicht om open-source alternatieven te overwegen bij elke significante softwareaanschaf, en om bij te dragen aan de projecten waarvan ze afhankelijk is. Dit “give back”-principe is nog niet uniform geïmplementeerd, maar vormt een precedent voor publiek medebestuur van kritieke digitale infrastructuur.
Volgens het Synopsys OSSRA-rapport 2024 bevat 74% van de geanalyseerde codebases kwetsbaarheden in open-source componenten (Synopsys, 2024). Dit maakt duidelijk dat soevereiniteitsrisico en beveiligingsrisico bij open-source afhankelijkheden twee kanten zijn van dezelfde munt: een onbeheerd component is zowel een kwetsbaarheidsvector als een onbekende jurisdictievariabele.
Praktische stappen voor compliance officers en IT-beslissers
Organisaties in de overheid, de rechtssector en andere gereguleerde sectoren die een soevereine werkplek inrichten, kunnen de volgende concrete stappen nemen om open-source afhankelijkheden te beheersen in lijn met CRA en NIS-2.
Vereis als eerste stap bij elke softwareleverancier een actuele CycloneDX SBOM bij elke release. Integreer SBOM-verificatie in uw inkoopcontracten als contractuele vereiste, niet als vrijblijvend verzoek. Koppel deze SBOM vervolgens aan een geautomatiseerde kwetsbaarhedenscan via een tool zoals Dependency-Track (ook open-source, beheerd door OWASP).
Beoordeel bij de selectie van nieuwe open-source componenten de bijdragersdiversiteit via platform-analytische tools op GitHub of GitLab. Een project waarbij één werkgever meer dan 60% van de commits levert, verdient een extra risicoclassificatie in uw toeleveringsketenbeheer conform NIS-2 artikel 21.
Monitor ten slotte de voortgang van het Digital Commons EDIC en de EU Open Source Strategy 2026 om te beoordelen welke kritieke componenten in aanmerking komen voor Europees medebeheer, en stem uw eigen governance-beslissingen hier op af.
FAQ: open-source afhankelijkheden, soevereiniteitsrisico en compliance
Geldt de CRA-SBOM-verplichting ook voor organisaties die open-source software intern inzetten, niet als commercieel product?
De CRA richt zich primair op fabrikanten en importeurs die producten met digitale elementen op de EU-markt brengen. Organisaties die software uitsluitend intern gebruiken vallen buiten de directe fabrikantverplichtingen. NIS-2 artikel 21 verplicht hen echter wel tot beheer van toeleveringsketensecurity, wat impliceert dat zij de open-source componenten die zij van leveranciers afnemen systematisch moeten beoordelen.
Wat maakt een open-source component risicovol vanuit soevereiniteitsperspectief, ook als de licentie vrij is?
Een vrije licentie zegt niets over de jurisdictie waaronder de ontwikkelende organisatie, de dominante bijdragers of de financieringsbronnen vallen. Een component waarvan 80% van de commits afkomstig is van ontwikkelaars bij een Amerikaanse techgigant kan via buitenlandse wetgeving onder druk worden gezet, ook als de code zelf open is en uw servers in Europa staan.
Hoe verschilt CycloneDX van SPDX als SBOM-formaat, en welke kiest u voor NIS-2-compliance?
Beide formaten zijn bruikbaar en worden breed ondersteund. CycloneDX is sterker gericht op security-use cases zoals kwetsbaarhedenbeheer en exploitability-analyse, terwijl SPDX traditioneel sterker staat in licentiecompliance. Voor NIS-2 en CRA-contexten heeft CycloneDX in de praktijk de voorkeur vanwege de rijkere beveiligingsmetadata en de directe koppeling met VEX-documenten voor kwetsbaarheidsstatus.
Wat is het Digital Commons EDIC en hoe draagt het bij aan soevereiniteit van open-source infrastructuur?
Het EDIC voor Digital Commons is een samenwerkingsvorm waarmee EU-lidstaten gezamenlijk kritieke open-source infrastructuur kunnen financieren en besturen. Dit vermindert afhankelijkheid van commerciële aanbieders buiten de EU en zorgt dat Europese publieke belangen structureel vertegenwoordigd zijn in de besluitvorming over software die voor overheden en kritieke sectoren essentieel is.
Moet een overheidsorganisatie die Nextcloud on-premise draait toch een SBOM bijhouden?
Ja, om twee redenen. NIS-2 artikel 21 vereist dat essentiële en belangrijke entiteiten de beveiligingsrisico’s in hun toeleveringsketen beheren, wat een componenteninventarisatie impliceert. Daarnaast schrijft modern inkoopbeleid voor kritieke systemen steeds vaker voor dat leveranciers bij elke release een actuele SBOM aanleveren, zodat de organisatie zelf kwetsbare componenten kan identificeren zonder te hoeven wachten op een leveranciersadvies.
