Open source is een buitenbeentje in de CRA opzet wat leidt tot de open-source paradox onder de digitale productaansprakelijkheid
Op donderdag 4 juni 2026 organiseerde de Cyber Security Coalition de Application Security Experience Sharing Day in Leuven, in samenwerking met SecAppDev. Het event bracht onderzoek, praktijkervaring en beleidsontwikkelingen rond applicatiebeveiliging samen, met in de namiddag een bijzonder relevante discussie over de Cyber Resilience Act of CRA. Het event vond plaats in de Faculty Club in Leuven en liep van 9:30 tot 19:00.
Een van de interessantste panelgesprekken ging over de plaats van FOSS — Free and Open Source Software — binnen de CRA. De kernvraag: wie draagt de verantwoordelijkheid wanneer commerciële software gebouwd is op open-sourcecomponenten, zoals bijvoorbeeld het Xen Project, en daar later een zero day in blijkt te zitten?
De CRA maakt hier een fundamenteel onderscheid. Niet-gecommercialiseerde open-sourceontwikkeling valt in principe buiten de zware verplichtingen van de CRA. De verordening stelt dat enkel FOSS die in het kader van een commerciële activiteit op de markt wordt gebracht, binnen de CRA-scope valt. Vrijwillige ontwikkelaars of contributors die code bijdragen aan software die niet onder hun verantwoordelijkheid wordt vermarkt, vallen dus niet onder dezelfde aansprakelijkheidslogica als fabrikanten.
Daar wringt het schoentje. De vrijwilligers gaan juridisch grotendeels vrijuit, maar commerciële softwarebedrijven die deze componenten integreren in een product met digitale elementen krijgen het digitale liability-aapje doorgeschoven. Als er een zero day in een open-sourcecomponent zit, blijft de fabrikant verantwoordelijk voor risicoanalyse, kwetsbaarhedenbeheer, updates, documentatie en conformiteit van het eindproduct. De CRA vraagt immers dat producten met digitale elementen veilig worden ontworpen, ontwikkeld en onderhouden op basis van het risico.
De SBOM wordt het bewijsstuk, niet zomaar een inventaris
Daarom wordt de Software Bill of Materials een essentieel controlemiddel. De CRA definieert een SBOM als een formeel register met details en supply-chainrelaties van componenten die in de software-elementen van een product zitten. De fabrikant moet kwetsbaarheden en componenten identificeren en documenteren, minstens voor de top-level dependencies, in een algemeen gebruikt en machineleesbaar formaat.
Een CRA-gerichte SBOM zou minimaal moeten bevatten:
| Onderdeel | Wat moet erin staan |
|---|---|
| Productidentificatie | Productnaam, versie, build, leverancier, release datum |
| Componentenlijst | Alle directe softwarecomponenten en, waar mogelijk, transitieve dependencies |
| Componentmetadata | Naam, versie, leverancier, package URL of andere unieke identificator |
| Licentie-informatie | Open-source- of commerciële licenties per component |
| Relaties | Welke component bouwt op welke andere component voort |
| Hashes/integriteit | Cryptografische hashes waar relevant |
| Kwetsbaarheidskoppeling | CPE, PURL, CVE-koppelingen of vulnerability references |
| Herkomst | Repository, leverancier, build pipeline of package registry |
| Supportstatus | Maintained, deprecated, end-of-life, forked of intern gepatcht |
| Risicotoelichting | Bekende risico’s, onzekerheden, zero-day exposure, niet-gepatchte componenten |
| Updatebeleid | Hoe updates worden opgevolgd en verspreid |
| Attestatie | Datum, tool, verantwoordelijke partij en scope van de SBOM |
Voor het formaat noemt de CRA vandaag nog geen exclusieve standaard. Wel vereist ze dat de SBOM commonly used en machine-readable is. In de praktijk betekent dit dat SPDX en CycloneDX de voornaamste kandidaten zijn. De Commissie kan later via uitvoeringshandelingen het exacte formaat en de verplichte elementen verder specificeren.
De SBOM moet dus niet alleen zeggen: “wij gebruiken component X”. Ze moet ook duidelijk maken wat het securityverhaal is achter die component. Bij FOSS hoort daar expliciet bij: wie onderhoudt het project, hoe snel worden kwetsbaarheden opgepikt, is er een security policy, is er een maintainer-risico, en wat gebeurt er als er een zero day opduikt zonder commerciële partij achter het project?
Het maturiteitsgat in de CRA
Mijn belangrijkste bezorgdheid na het panelgesprek is dat de CRA tot vandaag geen expliciet maturiteitsniveau oplegt. De CRA zegt dat risicobeheer, vulnerability handling, secure development en documentatie moeten bestaan, maar ze bepaalt niet duidelijk hoe diep dat moet gaan.
Daardoor ontstaat een reëel risico op de papieren CRA-tijger: een fabrikant kan procedures, verklaringen, templates en een CE-dossier opbouwen zonder dat duidelijk is of de onderliggende SDLC werkelijk volwassen genoeg is. Een productteam kan op papier voldoen, terwijl de praktijk beperkt blijft tot dependency scanning, een generieke policy en een jaarlijks securitymoment.
De CRA bevat wel technische en procesmatige verplichtingen, zoals vulnerability handling, beveiligingsupdates, testen en reviews, maar ze vertaalt die niet naar een volwassenheidsladder zoals “basic”, “managed”, “measured” of “optimized”. In de officiële CRA-tekst komt het begrip “maturity” zelfs niet voor.
Voor application security is dat problematisch. De echte vraag is niet alleen: “heb je een SBOM?” De vraag is: “welke diepgang heeft je secure SDLC, hoe snel detecteer je componentrisico’s, hoe bewijs je exploitability analysis, hoe beheer je forks, hoe test je patches, en wie neemt de beslissing om een kwetsbare open-sourcecomponent te blijven gebruiken?”
De rol van de 41 CRA-standaarden en ETSI
De Europese Commissie heeft standaardisatieverzoek M/606 aangenomen. Dat omvat volgens de Commissie een set van 41 standaarden ter ondersteuning van de CRA. Die standaarden zijn zowel horizontaal als verticaal. Horizontale standaarden bieden een gemeenschappelijk kader, onder meer voor vulnerability handling. Verticale of productspecifieke standaarden moeten helpen om per productcategorie een vermoeden van conformiteit met de CRA te geven.
Tijdens het panel werd verwezen naar ETSI-werk rond technische standaarden. De officiële ETSI-informatie spreekt over CYBER-EUSR, de ETSI-werkgroep die verticale standaarden ontwikkelt voor de CRA. Die werkgroep dekt 18 digitale productcategorieën en moet cybersecurity-eisen specificeren die kunnen leiden tot een vermoeden van conformiteit met de essentiële CRA-eisen.
Belangrijk is dat die ETSI-standaarden niet zomaar “nice to have” zijn. Zodra geharmoniseerde standaarden in het Publicatieblad van de EU worden geciteerd, kunnen ze een praktisch pad worden om conformiteit aan te tonen. Maar ook hier blijft de vraag: zullen deze standaarden voldoende maturiteitsdiepte opleggen, of vooral minimale technische eisen formuleren?
EN 40000: niet ISO 40000, maar het horizontale CRA-kompas
Een kleine terminologische correctie is belangrijk: het gaat hier niet om “ISO 40000”, maar om de Europese EN 40000-reeks, ontwikkeld binnen CEN/CENELEC JTC 13/WG 9 als horizontale standaardenset voor CRA-compliance. CEN/CLC/JTC 13/WG 9 is verantwoordelijk voor de horizontale standaarden onder M/606, items 1 tot 15.
De kernopzet van EN 40000 is om de algemene CRA-verplichtingen te vertalen naar een werkbaar kader voor fabrikanten van producten met digitale elementen. De reeks behandelt onder meer:
| EN 40000-onderdeel | Kernfunctie |
|---|---|
| Vocabulary | Gemeenschappelijke termen en definities |
| Cyber resilience principles | Security-by-design, security-by-default en lifecycle-denken |
| Vulnerability handling | Detectie, documentatie, remediatie, disclosure en updates |
| Generic security requirements | Generieke beveiligingseisen voor producten met digitale elementen |
| Product security controls | Controles die fabrikanten kunnen gebruiken om CRA-eisen aantoonbaar te maken |
Volgens publieke overzichten is de EN 40000-reeks bedoeld als horizontale basis voor alle producten met digitale elementen. Ze moet een gemeenschappelijk referentiekader bieden voor risicobeoordeling, securityprincipes, vulnerability handling en technische documentatie.
Conclusie: CRA-compliance moet meer worden dan documentbeheer
De CRA zet een noodzakelijke stap: software- en hardwarefabrikanten kunnen cybersecurity niet langer als vrijblijvende best effort behandelen. Maar het FOSS-debat toont aan dat de realiteit van software supply chains complexer is dan klassieke productregulering.
Open source is geen zwakke schakel op zich. Integendeel, FOSS is vaak de ruggengraat van moderne digitale infrastructuur. Maar als commerciële partijen open-sourcecomponenten integreren, moeten ze ook de risico’s dragen, analyseren en documenteren. Een SBOM zonder risicotoelichting wordt dan onvoldoende. Een CRA-dossier zonder aantoonbare SDLC-maturiteit wordt gevaarlijk.
De grote uitdaging voor Europa is nu om CRA-conformiteit niet te laten verworden tot een papieren oefening. De komende ETSI- en EN 40000-standaarden zullen moeten aantonen of ze fabrikanten werkelijk richting geven in risicobeheer, secure development, supply-chain governance en vulnerability response. Anders krijgen we CE-markering op producten waarvan de beveiligingsvolwassenheid onduidelijk blijft.
En net daar ligt de les van het panel: de CRA mag geen compliance-label worden. Ze moet een maturity driven beleid voor cyberweerbaarheid worden.
