Cyber Resilience Act: breng verplichtingen in de productontwikkeling

De Cyber Resilience Act (de Europese cyberweerbaarheidsverordening) brengt cybersecurityverplichtingen in de levenscyclus van producten met digitale elementen die onder de verordening vallen. Voor een CTO is de praktische opgave om wat engineering bouwt, uitlevert en onderhoudt te verbinden met het bewijs dat nodig is om aan die verplichtingen te voldoen.

Die verbinding moet werken op het niveau van product en versie. Een bedrijfsbreed beveiligingsbeleid verklaart niet of een bepaalde release veilige standaardinstellingen heeft, welke afhankelijkheden erin zitten of hoe klanten een beveiligingsupdate ontvangen. Een kwetsbaarheidsticket met de status "opgelost" toont niet aan welke ondersteunde versies nog kwetsbaar zijn.

Het nuttige vertrekpunt is daarom een model van de productlevenscyclus: scope, beveiligingseisen, releasebewijs, kwetsbaarheidsbehandeling, ondersteuningstoezeggingen en besluiten waarvoor iemand verantwoordelijk is. Bouw dat model in de ontwikkeling in, in plaats van het vóór een beoordeling afzonderlijk samen te stellen.

Bepaal de productgrens voordat u beheersmaatregelen toewijst

De CRA betreft producten met digitale elementen binnen de reikwijdte ervan, waaronder hardware en software die eronder vallen. Het is geen universele regel voor elke SaaS-dienst. Een gehoste dienst en software die aan klanten wordt verstrekt, kunnen verschillende analyses vereisen, en verwerking op afstand die integraal deel uitmaakt van een product moet ook worden onderzocht.

Gebruik de CRA-richtsnoeren van de Europese Commissie als uitgangspunt en beantwoord vervolgens de productspecifieke juridische vragen. Leg de conclusie vast in plaats van te vertrouwen op een informele aanname van een team.

Stel voor elk kandidaatproduct vast:

• Wat klanten ontvangen: hardware, geïnstalleerde software, downloadbare componenten of een combinatie daarvan.
• Welke functies voor verwerking op afstand nodig zijn om het product zijn functies te laten vervullen.
• Hoe het product op de EU-markt wordt aangeboden en welke entiteit het levert.
• Uw rol als marktdeelnemer: fabrikant, importeur, distributeur of een andere relevante rol.
• Toepasselijke uitzonderingen, productspecifieke wetgeving en overwegingen rond open source.
• De productcategorie en de daaruit voortvloeiende eisen voor de conformiteitsbeoordeling.

Open source vraagt bijzondere zorg. De behandeling van software die buiten een commerciële activiteit wordt geleverd, betekent niet dat een commerciële fabrikant opensourcecomponenten in zijn product mag negeren. Maak onderscheid tussen de positie van de upstreambijdrager en uw verantwoordelijkheid voor het product dat u levert.

Het engineeringresultaat moet een korte scopevastlegging zijn met een architectuurdiagram, productidentificatoren, relevante commerciële entiteiten, aannames en een goedgekeurde conclusie. Benoem de persoon die verantwoordelijk is voor het heropenen van die conclusie wanneer functionaliteit of distributie verandert.

Een downloadbare beheerapplicatie en de bijbehorende gehoste analysedienst moeten bijvoorbeeld niet automatisch één ongedifferentieerd scopebesluit krijgen. Stel vast welke functies lokaal werken, welke van de dienst afhankelijk zijn en of die verwerking op afstand binnen de productgrens valt. Dat onderscheid beïnvloedt de risicobeoordeling, de vastlegging van afhankelijkheden en het eigenaarschap van incidenten.

Werk vanuit de actuele toepassingsdata

De Commissie noemt 11 september 2026 voor de meldverplichtingen en 11 december 2027 voor de belangrijkste CRA-eisen. Op 7 oktober 2026 is de datum voor de meldverplichtingen al verstreken. Behandel meldgereedheid als een actuele operationele eis, niet als een taak die tot de voorbereiding op conformiteit kan wachten.

Houd twee werkstromen zichtbaar:

Producten die vóór de belangrijkste toepassingsdatum zijn geleverd, vragen aandacht voor overgangsbepalingen en substantiële wijzigingen. Ga er niet van uit dat een ouder product niet relevant is voor de meldplicht alleen omdat de oorspronkelijke release van vóór december 2027 dateert.

Houd een gedateerd register van wettelijke eisen bij. Raadpleeg voor drempels voor gebeurtenissen, gefaseerde meldtermijnen, ontvangers en indieningsprocedures de actuele wettekst en officiële uitvoeringsrichtsnoeren. Vervang het CRA-specifieke proces niet door een generiek sjabloon voor incidentrespons.

Zet beveiligingseisen om in ontwerp- en releasecriteria

De essentiële eisen van de CRA betreffen eigenschappen van productbeveiliging en de behandeling van kwetsbaarheden. De implementatie ervan moet volgen uit de cybersecurityrisicobeoordeling van het product, en niet uit een universele checklist die zonder architectuurcontext wordt toegepast.

Begin bij de manier waarop het product schade kan veroorzaken. Beschrijf gebruikers, deploymentomgevingen, blootgestelde interfaces, geprivilegieerde operaties, gevoelige gegevens en voorzienbaar misbruik. Neem de operationele aannames van de klant mee: een appliance in een industrieel netwerk heeft een andere blootstelling en andere herstelbeperkingen dan een desktoptool.

Een praktische threat-modelingoefening kan dit werk ondersteunen; de richtlijnen van OWASP voor threat modeling bieden een beproefde aanpak. De output moet dreigingen verbinden met specifieke eisen, implementatiebesluiten en tests.

Kijk hoe bekende eisen toetsbaar worden:

Dit zijn praktische implementatievoorbeelden, geen vervanging van de toepasselijke eisen. Bepaal relevantie en toereikendheid via de risicobeoordeling.

Voeg beveiligingsacceptatiecriteria toe aan featurewerk. Een nieuwe beheer-API moet worden opgeleverd met besluiten over authenticatie, autorisatie, invoerverwerking en logging, en niet met een belofte dat security er later naar kijkt. Herzie het dreigingsmodel wanneer een interface op afstand, een geprivilegieerde component of een nieuwe vertrouwensgrens wordt toegevoegd.

De releasegoedkeuring moet openstaande kwetsbaarheden, hun misbruikbaarheid, getroffen configuraties en de behandeling benoemen. Pas de CRA-eis toe om producten op de markt aan te bieden zonder bekende misbruikbare kwetsbaarheden, rekening houdend met de risicobeoordeling en de toepasselijke essentiële eisen; het vastleggen of accepteren van een risico voldoet op zichzelf niet aan die eis. Een scannerresultaat alleen kan dat besluit niet nemen: bereikbaarheid, voorwaarden en productgedrag doen ertoe. Omgekeerd is een lage numerieke ernstscore geen voldoende reden om een kwetsbaarheid te negeren die in uw deploymentmodel wel gevolgen heeft.

De releasevastlegging moet de goedgekeurde bronrevisie, het buildartefact, de inventaris van afhankelijkheden, testresultaten en het beveiligingsbesluit met elkaar verbinden. Zo wordt de beoordeling reproduceerbaar wanneer een klant of autoriteit later naar een specifieke versie vraagt.

Maak due diligence op componenten onderdeel van het buildproces

Componenten van derden brengen verplichtingen met zich mee die niet kunnen worden afgedaan door een upstream-beveiligingsmelding door te sturen. U moet begrijpen wat u hebt uitgeleverd, of het getroffen is en hoe u het kunt herstellen.

De CRA bevat binnen de eisen voor kwetsbaarheidsbehandeling een eis voor een software bill of materials: in een gangbaar, machineleesbaar formaat dat ten minste de afhankelijkheden op het hoogste niveau omvat. Leg als praktische aanbeveling diepere informatie over afhankelijkheden vast waar uw buildtooling betrouwbare resultaten kan opleveren. Transitieve afhankelijkheden bepalen vaak de blootstelling.

Een SBOM is alleen nuttig als ze overeenkomt met een werkelijk productartefact. Koppel haar aan de release-ID en de build, en onderscheid uitgeleverde componenten van tooling die alleen voor ontwikkeling wordt gebruikt. Neem waar relevant firmware, besturingssysteempakketten, gebundelde bibliotheken en commerciële componenten op; een export uit een pakketbeheerder kan er meerdere missen.

Bouw de componentreview op rond vragen die engineeringbesluiten veranderen:

• Wordt de component onderhouden en past de ondersteunde levensduur bij de onze?
• Kunnen we tijdig kwetsbaarheidsinformatie en beveiligingsupdates verkrijgen?
• Hebben we toegang tot de broncode, een patchroute via de leverancier of een vervangingsstrategie?
• Introduceert de component geprivilegieerde uitvoering of een nieuwe externe verbinding?
• Kan het product nog worden onderhouden als de leverancier de ondersteuning stopzet?

Voor commerciële componenten moet inkoop beveiligingscontacten, afspraken over meldingen en toegang tot oplossingen vastleggen. De timing van de leverancier moet ruimte laten voor uw eigen beoordeling en meldverplichtingen. De productfabrikant heeft nog steeds een interne escalatieroute nodig wanneer de reactie van een leverancier onvolledig is.

Bewaar voor opensourceafhankelijkheden de herkomst en een realistisch onderhoudsplan. Dat een repository openbaar toegankelijk is, bewijst niet dat iemand tijdens uw ondersteuningsperiode een compatibele patch zal leveren.

Ontwerp de ondersteuningsperiode en het updatemechanisme samen

Ondersteuning is een engineeringtoezegging met commerciële gevolgen. De CRA vereist in het algemeen een ondersteuningsperiode van ten minste vijf jaar, tenzij de verwachte gebruiksduur van het product korter is. Bepaal de toepasselijke periode aan de hand van de criteria van de verordening in plaats van een willekeurige datum te kiezen die bij de roadmap past.

Leg de onderbouwing vast, communiceer de vereiste ondersteuningsinformatie aan klanten en verbind die met onderhouden productversies. De ondersteuningstoezegging moet rekening houden met het vermogen om beveiligingsupdates te leveren, niet alleen met het aanhouden van een helpdeskadres.

Vraag voordat u het ondersteuningsplan van een product goedkeurt of u:

• Oudere ondersteunde branches opnieuw kunt bouwen met onderhouden toolchains.
• Beveiligingsupdates veilig kunt produceren, authenticeren en distribueren.
• Oplossingen kunt testen op ondersteunde hardware en deploymentconfiguraties.
• Ondertekeningssleutels kunt onderhouden en veilig kunt herstellen na compromittering van een sleutel.
• Update- en beveiligingsinformatie voor klanten beschikbaar kunt houden.
• Afhankelijkheden kunt afhandelen waarvan de upstreamondersteuning eerder eindigt dan de uwe.

Beveiligingsupdates moeten tijdens de ondersteuningsperiode in het algemeen kosteloos worden verstrekt, behoudens de bepalingen van de verordening. Elke beveiligingsupdate die in die periode wordt uitgebracht, moet beschikbaar blijven gedurende ten minste tien jaar na uitgifte of gedurende de resterende ondersteuningsperiode, afhankelijk van welke langer is. Plan beveiligingsoplossingen los van featureontwikkeling, zodat klanten niet onnodig tot ongerelateerde functionele wijzigingen worden gedwongen.

Test meer dan het ideale scenario. Een onderbroken installatie, onvoldoende opslagruimte, verlopen inloggegevens en mislukte verificatie kunnen van een geldige patch een beschikbaarheidsprobleem maken. Bepaal welke herstelmechanismen nodig zijn voor het risicoprofiel van het product.

Aan het einde van de ondersteuning moeten klantcommunicatie en interne vastleggingen met elkaar overeenstemmen. Laat geen downloadpagina bestaan die doorlopend beveiligingsonderhoud suggereert terwijl het productregister vermeldt dat de toezegging is beëindigd.

Bouw een meldrunbook dat bestand is tegen onzekerheid

Een gewone kwetsbaarheidsbevinding, een actief misbruikte kwetsbaarheid en een ernstig beveiligingsincident zijn niet uitwisselbaar. Het CRA-meldproces vereist een gedocumenteerde beoordeling van de relevante aanleiding: niet het automatisch melden van elke scannerwaarschuwing, en ook niet het automatisch terzijde schuiven van alles zonder afgerond forensisch onderzoek.

Het runbook moet beginnen bij de intake. Onderzoekers, klantenservice, leveranciers en engineeringteams hebben een bekende route naar de productbeveiligingsfunctie nodig. Bewaar de oorspronkelijke melding en leg vast wanneer relevante informatie bekend werd; zet tijdstempels van kennisname niet opnieuw wanneer een ticket van team wisselt.

Verzamel bij mogelijk meldplichtige gebeurtenissen:

• Productidentificatoren en getroffen ondersteunde versies.
• Bewijs van misbruik of van de impact van het incident, met de mate van zekerheid en onzekerheden.
• Bekende aanvalsvoorwaarden, getroffen functies en deploymentaannames.
• Beschikbare mitigaties en de status van corrigerende maatregelen.
• De beoordeling van de aanleiding, de eigenaar van de melding en de berekening van de toepasselijke termijnen.
• Ingediende meldingen, ontvangstbevestigingen, latere updates en klantcommunicatie.

Controleer de gefaseerde meldtermijnen, de eisen aan het eindverslag, de ontvangers en de actuele meldprocedure aan de hand van officiële bronnen. Actief misbruikte kwetsbaarheden en ernstige incidenten kennen verschillende meldvereisten; één gekopieerd veld voor de termijn is niet genoeg.

Wijs een primaire eigenaar van de melding aan en een plaatsvervanger met de bevoegdheid om engineering, juridische zaken en klantcommunicatie te coördineren. Regel vooraf toegang tot het toepasselijke meldmechanisme. Juridische review moet binnen het meldvenster beschikbaar zijn in plaats van een onbegrensde goedkeuringswachtrij te worden.

Oefen het proces met onvolledige informatie. Een nuttige oefening begint met een geloofwaardige melding van misbruik, een onzekere lijst van getroffen versies en een componentleverancier die niet bereikbaar is. Het team moet tijdig een gedocumenteerd meldbesluit kunnen nemen terwijl het onderzoek doorloopt.

Melden onder de CRA vervangt geen andere toepasselijke verplichtingen. Een productgebeurtenis kan ook een beoordeling vereisen onder het gegevensbeschermingsrecht of een klantcontract. Coördineer die beoordelingen, maar bewaar hun afzonderlijke aanleidingen, ontvangers en besluitvastleggingen.

Bevestig de classificatie voordat u het beoordelingsplan kiest

De productclassificatie bepaalt welke route voor de conformiteitsbeoordeling beschikbaar is. Ga er niet van uit dat elk verbonden product dezelfde externe beoordeling nodig heeft, of dat elke fabrikant kan volstaan met een interne beoordeling.

Bepaal de toepasselijke categorie op basis van de functies van het product en de definities en bijlagen van de verordening. Bevestig vervolgens de toegestane route, inclusief eventuele voorwaarden rond geharmoniseerde normen, erkende specificaties, certificeringsregelingen of beoordeling door een derde partij.

Normenplanning vereist een expliciet register van afhankelijkheden: welke referenties van toepassing zijn, wat hun actuele status is en wat er verandert als een verwachte route niet beschikbaar is. Voorkom dat het releaseplan afhangt van een onbevestigde aanname over normen of beoordelingscapaciteit.

Herzie de classificatie wanneer de functionaliteit verandert. Het toevoegen van functies voor beveiligingsbeheer of netwerkcontrole kan de analyse beïnvloeden, maar een featurenaam alleen bepaalt geen categorie. Beoordeel de werkelijke functie en documenteer de conclusie.

Houd de classificatie, de gekozen route en de conformiteitsresultaten verbonden met de technische documentatie. CE-markering en de conformiteitsverklaring moeten het toepasselijke proces volgen; ze vervangen niet de implementatie van de onderliggende eisen.

Onderhoud een bewijspakket dat een release kan verklaren

Technische documentatie moet zowel het product beschrijven als de redenering achter de beveiligingsbesluiten. Bewaar risicobeoordelingen en documentatie terwijl het product verandert, en pas de wettelijke bewaartermijnen toe op de relevante vastleggingen.

Een nuttig productbewijspakket omvat het scopebesluit, de architectuur, de risicobeoordeling, beveiligingseisen, componentinformatie, verificatieresultaten, procedures voor kwetsbaarheidsbehandeling, de onderbouwing van de ondersteuning en conformiteitsvastleggingen. Elk onderdeel heeft een eigenaar en een identificeerbare versie nodig.

Gebruik stabiele identificatoren om deze vastleggingen te verbinden. Een kwetsbaarheidsvastlegging moet getroffen versies, blootstelling, behandeling, release en vereiste communicatie verklaren. "Opgelost" zonder versiecontext laat het productbewijs onvolledig.

Bestaande ISMS-processen kunnen nuttig bewijs leveren over governance, leveranciers en veilige ontwikkeling. ISO 27001 betreft echter een afgebakend managementsysteem voor informatiebeveiliging; certificering toont geen CRA-conformiteit van een afzonderlijk product aan. Hergebruik relevant bewijs zonder frameworkmappings als juridische gelijkwaardigheid te behandelen.

Uitgewerkt voorbeeld: een fout in een afhankelijkheid van een ondersteunde appliance

Neem een illustratieve fabrikant die een netwerkgekoppelde appliance in de EU levert. Ga ervan uit dat scope en classificatie zijn beoordeeld, dat twee releasebranches ondersteund blijven en dat een gebundelde bibliotheek elders actief wordt misbruikt.

De eerste taak is niet het afsluiten van de upstream-advisory. Engineering stelt vast welke builds van de appliance de kwetsbare bibliotheek bevatten en of de getroffen functie bereikbaar is. De SBOM suggereert dat beide branches haar bevatten, maar configuratieanalyse toont een verschillende blootstelling. Dat onderscheid wordt met ondersteunend bewijs vastgelegd.

De eigenaar van productbeveiliging beoordeelt vervolgens of de beschikbare feiten voldoen aan de toepasselijke CRA-meldaanleiding. Onzekerheid over één deploymentconfiguratie wordt vastgelegd; die rechtvaardigt niet dat de eigenaar van het besluit onbenoemd blijft. Het meldrunbook levert de actuele meldfasen en procedure.

Engineering ontwikkelt een tijdelijke mitigatie en een gepatchte build voor elke getroffen branch. Tests omvatten het kwetsbare pad, normale werking en geauthenticeerde installatie van de update. Als één branch de upstreampatch niet kan gebruiken, legt het team de alternatieve behandeling en het restrisico vast in plaats van het hele product als opgelost te markeren.

De klantcommunicatie benoemt getroffen versies, directe beschermende maatregelen en hoe de update kan worden verkregen. De timing van de openbaarmaking wordt afgestemd op de toepasselijke eisen voor kwetsbaarheidsbehandeling en eventuele gerechtvaardigde beveiligingsoverwegingen.

De afgeronde vastlegging verbindt de advisory, de analyse van getroffen builds, het meldbesluit, waar vereist de indieningen, patchcommits, testresultaten, releaseartefacten en communicatie. Een reviewer kan nu zowel de engineeringrespons als het compliancebesluit reconstrueren.

Begin met één product en één volledige bewijsketen

Kies een representatief ondersteund product en volg één recente release en één kwetsbaarheid door de levenscyclus. Ontbrekende versiekoppelingen, onduidelijke ondersteuningstoezeggingen en ontoegankelijke meldprocedures worden snel zichtbaar. Maak van elk hiaat een taak met een eigenaar en breid het model daarna uit over het portfolio.

Secani kan deze bewijsworkflow ondersteunen door eisen, bewijs, eigenaren, taken en reviewbesluiten met elkaar te verbinden. Engineeringtools blijven de operationele bronnen voor builds, releases en kwetsbaarheden; de compliancewerkruimte relateert die vastleggingen aan de toepasselijke verplichting. Houd menselijke goedkeuring expliciet voor mappings en conclusies en bewaar de herleidbaarheid naar bronnen bij het gebruik van door AI ondersteunde concepten.

De directe volgende stap is het testen van het meldrunbook. Vereis tegelijk dat de volgende productrelease een gekoppeld scopebesluit, een actuele risicobeoordeling, een componentinventaris en een beveiligingsgoedkeuring bevat. Zo ontstaat een herhaalbare engineeringpraktijk terwijl de voorbereiding op conformiteit vordert.