Het grootste deel van een softwareproduct met digitale elementen is code die de fabrikant niet heeft geschreven: bibliotheken, frameworks, een besturingssysteem, een database, een clouddienst. De Cyber Resilience Act, Verordening (EU) 2024/2847, maakt de fabrikant niet verantwoordelijk voor de eigen naleving van die componenten. Zij maakt hem verantwoordelijk voor het product als geheel, en verbindt drie plichten aan de componenten erin. Artikel 13(5): zorgvuldigheid betrachten bij het integreren ervan. Artikel 13(6): kwetsbaarheden die u erin vindt melden aan de beheerder, en de fixes die u schrijft delen. Bijlage I, deel I, punt 2(a), gelezen met artikel 13(1): het product in de handel brengen zonder bekende uitbuitbare kwetsbaarheden. De verordening formuleert elk in één zin. De richtsnoeren van de Commissie van 27 juli 2026, C(2026) 5252, delen 3.4, 7.3 en 9.2, zeggen wat elk vergt, en dit artikel is die delen, met de FAQ van de Commissie over de uitvoering, versie 1.4, deel 5.4, waar die iets toevoegt.

Wie verantwoordelijk is voor een component: alleen wie het in de handel brengt

Punt 87 van de richtsnoeren beslecht de vraag die beheerders en integratoren beiden stellen: "Of de CRA op een bepaald FOSS-component van toepassing is, hangt uitsluitend af van de vraag of de natuurlijke of rechtspersoon die het publiceert het in de handel brengt." Het integreren van een component in een te gelde gemaakt product "heeft geen invloed op de status van dat FOSS-component", en punt 86 voegt toe dat fabrikanten "niet verantwoordelijk worden voor de individuele naleving van de CRA door die componenten, zelfs wanneer de fabrikanten broncode bijdragen aan het onderhoud ervan". Wanneer een project in de handel wordt gebracht is een vraag voor de uitgever ervan. Wat de integrator verschuldigd is, staat in punt 88: naleving "voor hun eigen producten met digitale elementen", zorgvuldigheid onder artikel 13(5) "jegens de FOSS-componenten die zij integreren", en de meldingen en fixes van artikel 13(6).

Zorgvuldigheid, artikel 13(5): bepaal wat u van het component nodig hebt, en verifieer dat

Deel 7.3 trekt de grens tussen de risicobeoordeling en de zorgvuldigheid. De risicobeoordeling van artikel 13(2) dekt het product en de risico's die het van buitenaf bereiken, "zoals externe netwerken, omgevingsfactoren of andere externe aspecten", en daarvoor "vereist de CRA niet dat fabrikanten de externe omgeving beheersen of besturen", alleen "dat zij die risico's identificeren en beperken door het ontwerp en de ontwikkeling van het product" (punt 168). Het voorbeeld in punt 169 is een backend die geen deel is van het product maar gebruikt zou kunnen worden om het kwaadaardige opdrachten te sturen: het antwoord ligt op productniveau, "cryptografische authenticatie van opdrachten op afstand, verificatie van de integriteit van configuratiewijzigingen of het genereren van beveiligingsrelevante logs", en de verordening "legt geen verplichtingen op over hoe de backend-infrastructuur is georganiseerd, bemand of beheerd".

Zorgvuldigheid is de andere plicht, en zij "heeft betrekking op elementen die deel uitmaken van het product met digitale elementen zelf, met name geïntegreerde software- of hardwarecomponenten van een derde" (punt 170). De inhoud ervan staat in één zin van hetzelfde punt: zij "kan alleen worden bereikt door te bepalen wat het product met digitale elementen van zijn componenten nodig heeft om zijn cyberbeveiligingsdoelstellingen te halen, en op risicogebaseerde wijze te verifiëren dat die componenten aan de behoeften van het product voldoen". Punt 171 maakt het concreet: als het product "steunt op cryptografische functies, updatemechanismen of beveiligde communicatie die een component levert, moet de fabrikant als onderdeel van zijn zorgvuldigheid die behoeften identificeren en verifiëren dat het component eraan voldoet". Het bewijs "kan bestaan uit documentatie verkregen van de fabrikant van het component, zoals technische specificaties, beveiligingsdocumentatie of relevante conformiteits- of zekerheidsdocumentatie", en "in voorkomend geval kan de fabrikant ook tests uitvoeren".

Twee gevolgen voor een afhankelijkhedenlijst. Ten eerste is zorgvuldigheid evenredig en specifiek: zij vraagt wat elk component voor de beveiliging van het product doet en controleert dat, niet alles over elk pakket. Een logbibliotheek en een TLS-bibliotheek krijgen niet hetzelfde dossier. Ten tweede vindt de controle plaats "bij integratie" (punt 172), en worden de componenten behandeld "als extern geleverde componenten waarvan de eigenschappen door zorgvuldigheid worden geverifieerd", niet herontworpen. Punt 173: "Waar de fabrikant zelf functies ontwikkelt, moet hij de essentiële eisen rechtstreeks toepassen. Waar de fabrikant door anderen ontwikkelde componenten integreert, moet hij door zorgvuldigheid waarborgen dat die componenten zo kunnen worden gebruikt dat het product met digitale elementen als geheel kan voldoen."

Stroomopwaarts melden en fixes delen, artikel 13(6): vier grenzen die de richtsnoeren stellen

Artikel 13(6) vereist dat een fabrikant die een kwetsbaarheid in een geïntegreerd component vaststelt, deze meldt "aan de persoon of entiteit die het component vervaardigt of onderhoudt", en elke fix deelt die hij ontwikkelt. Deel 9.2.1 bakent de plicht op vier manieren af.

Alleen de versie die u integreert, via het kanaal van de beheerder, en niet twee keer. Punt 223: fabrikanten "zijn alleen verplicht stroomopwaarts te melden met betrekking tot de versie van het component die zij integreren"; waar de beheerder "beveiligingsbeleid, processen voor gecoördineerde openbaarmaking van kwetsbaarheden of aangewezen kanalen" heeft, gaat de melding daarlangs; en "fabrikanten zijn niet verplicht stroomopwaarts te melden wanneer zij kunnen bevestigen dat de persoon of entiteit die een component vervaardigt of onderhoudt op de hoogte is van het bestaan van een kwetsbaarheid". De richtsnoeren vragen fabrikanten "openbaar toegankelijke kwetsbaarheidsdatabanken, projectspecifieke beveiligingsadviezen of gevestigde issue-trackers te raadplegen alvorens stroomopwaarts te melden", om beheerders dubbele meldingen te besparen.

Alleen kwetsbaarheden in het component, niet in uw integratie ervan. Punt 224: de plicht dekt "die kwetsbaarheden die in het geïntegreerde component zelf bestaan, en niet kwetsbaarheden die het gevolg zijn van de integratie tussen het component en andere door de fabrikant ontwikkelde code". Waar de integratie een gedrag van het component aan het licht brengt dat geïsoleerd niet zichtbaar was, wordt het informeren van de beheerder aangemoedigd, niet vereist.

Niet waar er geen beheerder is. Punt 225: geen stroomopwaartse melding is verschuldigd "waar het component geen beheerder meer heeft, of waar de fabrikant voor nieuwe versies of beveiligingsfixes niet langer op de oorspronkelijke beheerder steunt"; het informeren van de gebruikers van het component via "bestaande gemeenschapsmechanismen (zoals mailinglijsten of issue-tickets) of via openbare kwetsbaarheidsregisters" wordt in plaats daarvan aangemoedigd.

Deel de fix; u hoeft hem niet gemerged te krijgen. Punten 226 tot 229: een fix die u voor een componentkwetsbaarheid ontwikkelt, moet stroomopwaarts worden gedeeld, "in voorkomend geval in een machineleesbaar formaat" en, voor een opensourcecomponent, "op een wijze die verenigbaar is met de licentie van dat component". Maar fabrikanten "zijn onder de CRA niet verplicht ervoor te zorgen dat hun beveiligingsfixes noodzakelijkerwijs worden aanvaard" of "in de coderepository van het component worden opgenomen", zijn niet verplicht op hun beurt de fix van de beheerder te aanvaarden, en waar zij de kwetsbaarheid beperken door iets anders in hun eigen systeem te wijzigen, "vereist de CRA niet dat de fabrikant de wijziging van een ander deel van het systeem stroomopwaarts deelt".

Wanneer de kwetsbaarheid van een component door u aan de autoriteiten moet worden gemeld

De verplichte melding van artikel 14 is een andere plicht dan de stroomopwaartse melding, en de twee worden gemakkelijk verward. Punt 218 van de richtsnoeren en FAQ 5.4 trekken de grens: een fabrikant meldt een actief uitgebuite kwetsbaarheid "in zijn product"; waar de kwetsbaarheid van een component van een derde "niet kan worden uitgebuit in zijn product met digitale elementen (bijvoorbeeld omdat de kwetsbare code niet bereikbaar is)" of "niet is uitgebuit in zijn product", valt zij "voor die fabrikant niet onder de verplichte melding". De FAQ voegt toe dat de fabrikant van het component haar ook meldt, "als dat component in de handel is gebracht", en dat de integrator "die kwetsbaarheid nog steeds vrijwillig kan melden, overeenkomstig artikel 15". Een gelijste CVE in een afhankelijkheid start dus twee dingen: de bereikbaarheidsbeoordeling die beslist of de 24-uursklok is gestart, en, als u iets hebt gevonden wat de beheerder niet weet, de melding van artikel 13(6).

Bekende uitbuitbare kwetsbaarheden op het moment dat u uitlevert

De eerste essentiële eis van bijlage I, deel I, punt 2(a), is het product beschikbaar te stellen "zonder bekende uitbuitbare kwetsbaarheden", en deel 9.2.2 beantwoordt de twee woorden die de verordening open laat. "Uitbuitbaar" is artikel 3(41): "een kwetsbaarheid die onder praktische operationele omstandigheden daadwerkelijk door een tegenstander kan worden gebruikt", die punt 231 afzet tegen kwetsbaarheden die "alleen onder theoretische omstandigheden (bijvoorbeeld in een laboratorium of een simulatie)" uitbuitbaar zijn. "Bekend" zijn de punten 233 en 234, en dat is ruim: een kwetsbaarheid "moet als bekend worden beschouwd wanneer zij is opgenomen in relevante openbaar toegankelijke kwetsbaarheidsdatabanken, zoals de Europese kwetsbaarhedendatabank" of "andere vooraanstaande kwetsbaarheidsdatabanken"; wanneer de fabrikant "ervan op de hoogte is gebracht via niet-openbare informatie, bijvoorbeeld via gecoördineerde openbaarmaking door een beveiligingsonderzoeker of via de eigen interne tests en analyses van de fabrikant, met inbegrip van bijvoorbeeld het gebruik van AI-gestuurde diensten"; en "wanneer zij publiekelijk en prominent is gemeld in betrouwbare media".

Punt 235 houdt het evenredig: een melding "betekent op zichzelf niet dat zij in de praktijk uitbuitbaar is of op het specifieke product van toepassing is", de fabrikant "zal haar moeten onderzoeken en de juistheid van die informatie en de toepasselijkheid bevestigen", en "er kan een beperkte periode verstrijken tussen de eerste melding van de kwetsbaarheid en de bevestiging ervan". De punten 236 en 237 gaan over de release die een dag weg is wanneer een nieuwe CVE in een afhankelijkheid opduikt: de verplichting "geldt op het moment van het in de handel brengen", zij is "een risicogebaseerde verplichting", en de fabrikant beslist op basis van "de ernst, uitbuitbaarheid en mogelijke impact van de kwetsbaarheid" of het product in de handel kan worden gebracht of de kwetsbaarheid eerst moet worden verholpen, en "kan ook rekening houden met de risico's van het uitstellen van de release", bijvoorbeeld waar de release andere uitbuitbare kwetsbaarheden verhelpt. Eenmaal op de markt gelden de behandelingsplichten van bijlage I, deel II, hoe dan ook.

Varianten en productfamilies

Een kort deel dat het meeste werk bespaart. Deel 7.4: waar producten "dezelfde architectuur, hetzelfde beveiligingsrelevante ontwerp en hetzelfde beoogde doel delen, en aan dezelfde cyberbeveiligingsrisico's zijn blootgesteld", mag de fabrikant "steunen op (i) één cyberbeveiligingsrisicobeoordeling", "(ii) één set technische documentatie; en (iii) één conformiteitsbeoordelingsprocedure", en "één EU-conformiteitsverklaring" afgeven die "duidelijk aangeeft op welke productvarianten zij van toepassing is" (punt 175). Punt 176 geeft de toets: verschillen in "kleur, vormfactor, geheugengrootte of andere niet-beveiligingsrelevante kenmerken" splitsen de familie niet; verschillen in "communicatie-interfaces, softwarestacks, updatemechanismen of connectiviteit op afstand" wel, en die moeten in de documenten terugkomen.

Wat u per component bewaart

De registratie die aan alle drie de plichten voldoet, past in de SBOM die u al maakt voor bijlage I, deel II, punt 1, één rij per component:

  1. Naam, geïntegreerde versie, en het beveiligingscontact of openbaarmakingskanaal van de beheerder.
  2. Wat het product ervan nodig heeft voor de beveiliging, in de zin van punt 171: niets, of cryptografie, updates, authenticatie, transport, enzovoort.
  3. Het bewijs dat u voor die behoefte hebt en wanneer u het verkreeg: de documentatie van de beheerder, een zekerheidsdocument, uw eigen test.
  4. De bereikbaarheid van de bekende kwetsbaarheden van het component in uw product, en de datum van de laatste controle tegen de databanken die punt 233 noemt.
  5. Gedane stroomopwaartse meldingen en gedeelde fixes, met datums, of de bevestiging dat de beheerder het al wist.

Die tabel is het zorgvuldigheidsdossier, de invoer voor de bereikbaarheidsbeoordeling wanneer een CVE verschijnt, en het deel van het technisch dossier dat een autoriteit als eerste leest als de vraag luidt "wist u ervan".

Bronnen

  • Verordening (EU) 2024/2847, artikel 3(41), artikel 13(1), (2), (5) en (6), artikel 14(1), artikel 15, bijlage I deel I punt 2(a) en deel II punt 1, overweging 34.
  • Europese Commissie, richtsnoeren van de Commissie over de toepassing van Verordening (EU) 2024/2847, C(2026) 5252 final van 27 juli 2026, bijlage, deel 3.4 (punten 85 tot 88), delen 7.3 en 7.4 (punten 167 tot 177), deel 9.1 punt 218, delen 9.2.1 en 9.2.2 (punten 222 tot 237).
  • Europese Commissie, FAQ over de Cyber Resilience Act, versie 1.4 van 4 september 2026, deel 5.4.

Dit is geen juridisch advies. De delen 7.3 en 9.2 beslaan samen zeven pagina's en beantwoorden de afhankelijkhedenvraag preciezer dan de pagina van welke toolleverancier ook; lees ze met uw lockfile open.