Cyber Resilience Act: få forpligtelserne ind i produktudviklingen

Cyber Resilience Act, på dansk forordningen om cyberrobusthed, bringer cybersikkerhedsforpligtelser ind i livscyklussen for omfattede produkter med digitale elementer. For en CTO er den praktiske opgave at forbinde det, udviklingsafdelingen bygger, leverer og vedligeholder, med den evidens, der skal til for at påvise disse forpligtelser.

Den forbindelse skal fungere på produkt- og versionsniveau. En virksomhedsdækkende sikkerhedspolitik forklarer ikke, om en bestemt release har sikre standardindstillinger, hvilke afhængigheder den indeholder, eller hvordan kunderne vil modtage en sikkerhedsopdatering. En sårbarhedsticket markeret som “rettet” fastslår ikke, hvilke understøttede versioner der fortsat er eksponeret.

Det nyttige udgangspunkt er derfor en model for produktets livscyklus: anvendelsesområde, sikkerhedskrav, releaseevidens, sårbarhedshåndtering, supportforpligtelser og ansvarlige beslutninger. Byg modellen ind i udviklingen i stedet for at samle den separat før en vurdering.

Definér produktets grænse, før kontroller tildeles

CRA vedrører produkter med digitale elementer inden for forordningens anvendelsesområde, herunder omfattet hardware og software. Den er ikke en universel regel for enhver SaaS-tjeneste. En hostet tjeneste og software, der distribueres til kunder, kan kræve forskellige analyser, og fjerndatabehandling, der er en integreret del af et produkt, skal også undersøges.

Brug Europa-Kommissionens vejledning om CRA som udgangspunkt, og afklar derefter de produktspecifikke juridiske spørgsmål. Registrér konklusionen i stedet for at forlade jer på et teams uformelle antagelse.

Fastslå for hvert kandidatprodukt:

• Hvad kunderne modtager: hardware, installeret software, komponenter, der kan downloades, eller en kombination.
• Hvilke fjerndatabehandlingsfunktioner der er nødvendige, for at produktet kan udføre sine funktioner.
• Hvordan produktet gøres tilgængeligt på EU-markedet, og hvilken enhed der leverer det.
• Jeres rolle som erhvervsdrivende: fabrikant, importør, distributør eller en anden relevant rolle.
• Gældende undtagelser, produktspecifik lovgivning og overvejelser om open source.
• Produktkategorien og de deraf følgende krav til overensstemmelsesvurdering.

Open source kræver særlig omhu. Behandlingen af software, der leveres uden for erhvervsmæssig virksomhed, betyder ikke, at en kommerciel fabrikant kan se bort fra open source-komponenter, der er indlejret i produktet. Skeln mellem den opstrøms bidragyders position og jeres ansvar for det produkt, I leverer.

Den tekniske leverance bør være en kort registrering af anvendelsesområdet med et arkitekturdiagram, produktidentifikatorer, relevante kommercielle enheder, antagelser og en godkendt konklusion. Navngiv den person, der er ansvarlig for at genåbne konklusionen, når funktionalitet eller distribution ændres.

For eksempel bør en administrationsapplikation, der kan downloades, og dens hostede analysetjeneste ikke automatisk få én udifferentieret afgørelse om anvendelsesområdet. Identificér, hvilke funktioner der kører lokalt, hvilke der afhænger af tjenesten, og om fjerndatabehandlingen hører inden for produktets grænse. Den sondring påvirker risikovurdering, registrering af afhængigheder og ejerskab af hændelser.

Arbejd ud fra de aktuelle anvendelsesdatoer

Kommissionen angiver 11. september 2026 for indberetningsforpligtelserne og 11. december 2027 for CRA's hovedkrav. Pr. 7. oktober 2026 er datoen for indberetning allerede passeret. Behandl indberetningsparathed som et aktuelt driftskrav og ikke som en opgave, der udskydes til forberedelsen af overensstemmelse.

Hold to arbejdsspor synlige:

Produkter, der er bragt i omsætning før hovedanvendelsesdatoen, kræver opmærksomhed på overgangsbestemmelser og væsentlige ændringer. Gå ikke ud fra, at et ældre produkt er irrelevant for indberetning, blot fordi dets oprindelige release ligger før december 2027.

Vedligehold et dateret register over lovkrav. For tærskler for hændelser, trinvise indberetningsfrister, modtagere og indsendelsesprocedurer skal den aktuelle lovtekst og den officielle vejledning om gennemførelse kontrolleres. Erstat ikke den CRA-specifikke proces med en generisk skabelon for hændelsesrespons.

Omsæt sikkerhedskrav til design- og releasekriterier

CRA's væsentlige krav omfatter egenskaber vedrørende produktsikkerhed og sårbarhedshåndtering. Implementeringen bør følge produktets cybersikkerhedsrisikovurdering i stedet for en universel tjekliste, der anvendes uden arkitektonisk kontekst.

Start med, hvordan produktet kan forårsage skade. Beskriv brugere, driftsmiljøer, eksponerede grænseflader, privilegerede operationer, følsomme data og forudsigeligt misbrug. Medtag kundens driftsforudsætninger: en appliance, der er placeret i et industrielt netværk, har en anden eksponering og andre gendannelsesbegrænsninger end et skrivebordsværktøj.

En praktisk øvelse i trusselsmodellering kan understøtte arbejdet; OWASP's vejledning om trusselsmodellering giver en etableret tilgang. Outputtet bør forbinde trusler med konkrete krav, implementeringsbeslutninger og test.

Overvej, hvordan velkendte krav bliver testbare:

Det er praktiske implementeringseksempler, ikke en erstatning for de gældende krav. Fastslå relevans og tilstrækkelighed gennem risikovurderingen.

Tilføj sikkerhedsmæssige acceptkriterier til arbejdet med funktioner. Et nyt administrativt API bør komme med beslutninger om autentificering, autorisation, inputhåndtering og logning, ikke med et løfte om, at sikkerhedsfolkene vil se på det senere. Genbesøg trusselsmodellen, når der tilføjes en fjerngrænseflade, en privilegeret komponent eller en ny tillidsgrænse.

Releasegodkendelsen bør identificere uafklarede sårbarheder, deres udnyttelighed, berørte konfigurationer og behandling. Anvend CRA's krav om at gøre produkter tilgængelige på markedet uden kendte udnyttelige sårbarheder under hensyntagen til risikovurderingen og de gældende væsentlige krav; at registrere eller acceptere en risiko opfylder ikke i sig selv det krav. Et scannerresultat alene kan ikke træffe den beslutning: tilgængelighed, forudsætninger og produktets adfærd har betydning. Omvendt er en lav numerisk alvorlighedsscore ikke en tilstrækkelig grund til at se bort fra en sårbarhed, der har konsekvenser i jeres udrulningsmodel.

Releaseregistreringen bør forbinde den godkendte kildekoderevision, buildartefaktet, afhængighedsfortegnelsen, testresultaterne og sikkerhedsbeslutningen. Det gør vurderingen reproducerbar, når en kunde eller en myndighed senere spørger til en bestemt version.

Gør due diligence af komponenter til en del af buildprocessen

Tredjepartskomponenter skaber forpligtelser, der ikke kan opfyldes ved at videresende en opstrøms sikkerhedsmeddelelse. I skal forstå, hvad I har leveret, om det er berørt, og hvordan I kan afhjælpe det.

CRA indeholder et krav om en softwarestykliste (SBOM) i kravene til sårbarhedshåndtering: et almindeligt anvendt, maskinlæsbart format, der som minimum dækker afhængighederne på øverste niveau. Som praktisk anbefaling bør I indsamle dybere oplysninger om afhængigheder, hvor jeres buildværktøjer kan levere pålidelige resultater. Transitive afhængigheder afgør ofte eksponeringen.

En SBOM er kun nyttig, når den svarer til et faktisk produktartefakt. Knyt den til releaseidentifikatoren og buildet, og skeln mellem leverede komponenter og værktøjer, der kun bruges i udviklingen. Medtag firmware, pakker til operativsystemet, medfølgende biblioteker og kommercielle komponenter, hvor det er relevant; en eksport fra en pakkemanager kan overse flere af disse.

Byg komponentgennemgangen op omkring spørgsmål, der ændrer tekniske beslutninger:

• Er komponenten vedligeholdt, og er dens understøttede levetid forenelig med vores?
• Kan vi hurtigt få oplysninger om sårbarheder og sikkerhedsopdateringer?
• Har vi adgang til kildekoden, en patchvej via leverandøren eller en erstatningsstrategi?
• Introducerer komponenten privilegeret eksekvering eller en ny ekstern forbindelse?
• Kan produktet stadig vedligeholdes, hvis leverandøren stopper med at understøtte komponenten?

For kommercielle komponenter bør indkøb fastlægge sikkerhedskontakter, ordninger for underretning og adgang til rettelser. Leverandørens tidsplan skal give plads til jeres egen vurdering og jeres indberetningsforpligtelser. Produktets fabrikant har stadig brug for en intern eskaleringsvej, når en leverandørs svar er ufuldstændigt.

For open source-afhængigheder skal oprindelsen og en realistisk vedligeholdelsesplan bevares. At et repository er offentligt tilgængeligt, er ikke evidens for, at nogen vil producere en kompatibel patch i løbet af jeres supportperiode.

Design supportperioden og opdateringsmekanismen samlet

Support er en teknisk forpligtelse med kommercielle konsekvenser. CRA kræver generelt en supportperiode på mindst fem år, medmindre produktets forventede brugsperiode er kortere. Fastlæg den gældende periode ud fra forordningens kriterier i stedet for at vælge en vilkårlig dato, der passer til roadmappen.

Registrér begrundelsen, kommunikér de påkrævede supportoplysninger til kunderne, og forbind dem med de vedligeholdte produktversioner. Supportforpligtelsen skal tage højde for evnen til at levere sikkerhedsopdateringer og ikke blot opretholde en helpdeskadresse.

Før en supportplan for et produkt godkendes, så spørg, om I kan:

• Genopbygge ældre understøttede branches med vedligeholdte toolchains.
• Producere, autentificere og distribuere sikkerhedsopdateringer sikkert.
• Teste rettelser på tværs af understøttet hardware og understøttede udrulningskonfigurationer.
• Vedligeholde signeringsnøgler og gendanne sikkert efter en kompromittering af nøgler.
• Holde kunderettede oplysninger om opdateringer og sikkerhed tilgængelige.
• Håndtere afhængigheder, hvis opstrøms support ophører før jeres.

Sikkerhedsopdateringer skal generelt stilles gratis til rådighed i supportperioden med forbehold for forordningens bestemmelser. Hver sikkerhedsopdatering, der udsendes i den periode, skal forblive tilgængelig i mindst ti år efter udsendelsen eller i resten af supportperioden, alt efter hvad der er længst. Planlæg sikkerhedsrettelser adskilt fra udvikling af funktioner, så kunderne ikke unødigt tvinges til at tage urelaterede funktionelle ændringer.

Test mere end den lykkelige vej. Afbrudt installation, utilstrækkelig lagerplads, udløbne legitimationsoplysninger og mislykket verifikation kan gøre en gyldig patch til et tilgængelighedsproblem. Beslut, hvilke gendannelsesmekanismer der er nødvendige for produktets risikoprofil.

Ved supportperiodens udløb bør kundekommunikation og interne registreringer stemme overens. Lad ikke en downloadside antyde fortsat sikkerhedsvedligeholdelse, når produktregistret siger, at forpligtelsen er ophørt.

Byg en runbook for indberetning, der kan klare usikkerhed

Et almindeligt sårbarhedsfund, en aktivt udnyttet sårbarhed og en alvorlig sikkerhedshændelse er ikke ensbetydende. CRA-indberetningsprocessen kræver en dokumenteret vurdering af den relevante udløser, ikke automatisk indberetning af hver scanneralarm og ikke automatisk afvisning af alt uden en afsluttet forensisk undersøgelse.

Runbooken bør begynde med modtagelsen. Forskere, kundesupport, leverandører og udviklingsteams har brug for en kendt vej til produktsikkerhedsfunktionen. Bevar den oprindelige rapport, og registrér, hvornår relevante oplysninger blev kendt; nulstil ikke tidsstempler for kendskab, når en ticket skifter team.

Indsaml for hændelser, der potentielt skal indberettes:

• Produktidentifikatorer og berørte understøttede versioner.
• Evidens for udnyttelse eller hændelsens påvirkning med sikkerhedsgrad og usikkerheder.
• Kendte angrebsbetingelser, berørte funktioner og forudsætninger for udrulning.
• Tilgængelige afbødende foranstaltninger og status for korrigerende foranstaltninger.
• Vurderingen af udløseren, ejeren af indberetningen og beregningen af de gældende frister.
• Indsendte underretninger, kvitteringer, efterfølgende opdateringer og kundekommunikation.

Kontrollér de trinvise underretningsfrister, kravene til den endelige rapport, modtagerne og den aktuelle indberetningsprocedure op mod officielle kilder. Aktivt udnyttede sårbarheder og alvorlige hændelser har forskellige indberetningsdetaljer; ét kopieret fristfelt er ikke nok.

Udpeg en primær ejer af indberetningen og en stedfortræder med bemyndigelse til at koordinere udvikling, jura og kundekommunikation. Sørg på forhånd for adgang til den gældende indberetningsmekanisme. Juridisk gennemgang bør være tilgængelig inden for indberetningsvinduet i stedet for at blive en ubegrænset godkendelseskø.

Øv processen med ufuldstændige oplysninger. En nyttig øvelse starter med en troværdig rapport om udnyttelse, en usikker liste over berørte versioner og en komponentleverandør, der ikke kan kontaktes. Teamet bør kunne træffe en rettidig, dokumenteret beslutning om indberetning, mens undersøgelsen fortsætter.

Indberetning efter CRA erstatter ikke andre gældende forpligtelser. En produkthændelse kan også kræve en vurdering efter databeskyttelseslovgivningen eller en kundekontrakt. Koordinér disse vurderinger, men bevar deres separate udløsere, modtagere og beslutningsregistreringer.

Bekræft klassificeringen, før vurderingsplanen vælges

Produktets klassificering påvirker den tilgængelige procedure for overensstemmelsesvurdering. Gå ikke ud fra, at ethvert forbundet produkt kræver den samme eksterne vurdering, eller at enhver fabrikant kan forlade sig på intern vurdering.

Fastlæg den gældende kategori ud fra produktets funktioner og forordningens definitioner og bilag. Bekræft derefter den tilladte procedure, herunder eventuelle betingelser vedrørende harmoniserede standarder, anerkendte specifikationer, certificeringsordninger eller tredjepartsvurdering.

Planlægningen af standarder kræver et eksplicit afhængighedsregister: hvilke referencer der gælder, deres aktuelle status, og hvad der ændres, hvis en forventet procedure ikke er tilgængelig. Undgå at gøre releaseplanen afhængig af en ubekræftet antagelse om standarder eller vurderingskapacitet.

Genbesøg klassificeringen, når funktionaliteten ændres. Tilføjelse af funktioner til sikkerhedsstyring eller netværkskontrol kan påvirke analysen, men et funktionsnavn alene fastlægger ikke en kategori. Vurdér den faktiske funktion, og dokumentér konklusionen.

Hold klassificeringen, den valgte procedure og leverancerne vedrørende overensstemmelse forbundet med den tekniske dokumentation. CE-mærkning og EU-overensstemmelseserklæringen skal følge den gældende proces; de er ikke erstatninger for implementering af de underliggende krav.

Vedligehold en evidenspakke, der kan forklare en release

Den tekniske dokumentation bør beskrive både produktet og begrundelsen bag dets sikkerhedsbeslutninger. Bevar risikovurderinger og dokumentation, efterhånden som produktet ændres, og anvend de lovbestemte opbevaringskrav på de relevante registreringer.

En nyttig evidenspakke for et produkt omfatter afgørelsen om anvendelsesområdet, arkitekturen, risikovurderingen, sikkerhedskravene, oplysninger om komponenter, verifikationsresultater, procedurer for sårbarhedshåndtering, begrundelsen for supportperioden og registreringer vedrørende overensstemmelse. Hvert element skal have en ejer og en identificerbar version.

Brug stabile identifikatorer til at forbinde disse registreringer. En sårbarhedsregistrering bør forklare berørte versioner, eksponering, behandling, release og påkrævet kommunikation. “Rettet” uden versionskontekst efterlader produktevidensen ufuldstændig.

Eksisterende ISMS-processer kan levere nyttig evidens om governance, leverandører og sikker udvikling. ISO 27001 vedrører dog et afgrænset ledelsessystem for informationssikkerhed; en certificering fastslår ikke CRA-overensstemmelse for et enkelt produkt. Genbrug relevant evidens uden at behandle frameworkmappinger som juridisk ækvivalens.

Gennemgået eksempel: en fejl i en afhængighed i en understøttet appliance

Tag en illustrativ fabrikant, der leverer en netværksforbundet appliance i EU. Antag, at anvendelsesområde og klassificering er gennemgået, at to releasebranches fortsat understøttes, og at et medfølgende bibliotek rapporteres som aktivt udnyttet andetsteds.

Den første opgave er ikke at lukke den opstrøms sikkerhedsmeddelelse. Udviklingen identificerer, hvilke builds af appliancen der indeholder det sårbare bibliotek, og om den berørte funktion kan nås. SBOM'en tyder på, at begge branches indeholder det, men konfigurationsanalysen viser forskellig eksponering. Den sondring registreres med understøttende evidens.

Ejeren af produktsikkerheden vurderer derefter, om de tilgængelige fakta opfylder den gældende CRA-udløser for indberetning. Usikkerhed om én udrulningskonfiguration registreres; den berettiger ikke, at beslutningens ejer forbliver unavngivet. Runbooken for indberetning leverer de aktuelle underretningstrin og den aktuelle procedure.

Udviklingen udvikler en midlertidig afbødning og et patchet build for hver berørt branch. Testene dækker den sårbare vej, normal drift og installation af autentificerede opdateringer. Hvis én branch ikke kan bruge den opstrøms patch, registrerer teamet den alternative behandling og restrisikoen i stedet for at markere hele produktet som rettet.

Kundekommunikationen identificerer berørte versioner, umiddelbare beskyttelsestiltag, og hvordan opdateringen fås. Tidspunktet for offentliggørelse koordineres med de gældende krav til sårbarhedshåndtering og eventuelle berettigede sikkerhedshensyn.

Den færdige registrering forbinder sikkerhedsmeddelelsen, analysen af berørte builds, beslutningen om indberetning, indsendelser, hvor det er påkrævet, patchcommits, testresultater, releaseartefakter og kommunikation. En gennemgående kan nu rekonstruere både den tekniske respons og compliancebeslutningen.

Start med ét produkt og én komplet evidenskæde

Vælg et repræsentativt understøttet produkt, og spor én nylig release og én sårbarhed gennem livscyklussen. Manglende versionslinks, uklare supportforpligtelser og utilgængelige indberetningsprocedurer bliver hurtigt synlige. Gør hvert hul til en opgave med en ejer, og udvid derefter modellen til hele porteføljen.

Secani kan understøtte denne evidensarbejdsgang ved at forbinde krav, evidens, ejere, opgaver og gennemgangsbeslutninger. Udviklingsværktøjerne forbliver de operationelle kilder til builds, releases og sårbarheder; complianceområdet relaterer disse registreringer til den gældende forpligtelse. Hold den menneskelige godkendelse af mappinger og konklusioner eksplicit, og bevar sporbarheden til kilderne, når der bruges AI-assisterede udkast.

Det umiddelbare næste skridt er at teste runbooken for indberetning. Kræv parallelt, at den næste produktrelease har en tilknyttet afgørelse om anvendelsesområdet, en aktuel risikovurdering, en komponentfortegnelse og en sikkerhedsgodkendelse. Det skaber en gentagelig teknisk praksis, mens forberedelsen af overensstemmelse skrider frem.