Cyberresiliensförordningen: för in skyldigheterna i produktutvecklingen

Cyberresiliensförordningen (Cyber Resilience Act, CRA) för in cybersäkerhetsskyldigheter i livscykeln för de produkter med digitala element som omfattas. För en CTO är den praktiska uppgiften att koppla det som teknikteamet bygger, levererar och underhåller till de underlag som behövs för att visa att skyldigheterna uppfylls.

Den kopplingen måste fungera på produkt- och versionsnivå. En företagsövergripande säkerhetspolicy förklarar inte om en viss release har säkra standardinställningar, vilka beroenden den innehåller eller hur kunderna kommer att få en säkerhetsuppdatering. Ett sårbarhetsärende som markerats som ”åtgärdat” fastställer inte vilka versioner med support som fortfarande är exponerade.

Den användbara utgångspunkten är därför en modell av produktens livscykel: tillämpningsområde, säkerhetskrav, underlag för releaser, sårbarhetshantering, supportåtaganden och beslut med tydligt ansvar. Bygg in modellen i utvecklingen i stället för att sammanställa den separat inför en bedömning.

Definiera produktgränsen innan ni tilldelar kontroller

CRA gäller produkter med digitala element inom dess tillämpningsområde, inklusive maskinvara och programvara som omfattas. Det är ingen universell regel för varje SaaS-tjänst. En värdbaserad tjänst och programvara som distribueras till kunder kan kräva olika analyser, och fjärrdatabehandling som är en integrerad del av en produkt måste också granskas.

Använd Europeiska kommissionens vägledning om CRA som utgångspunkt och reda sedan ut de produktspecifika rättsliga frågorna. Registrera slutsatsen i stället för att förlita er på ett teams informella antagande.

Fastställ för varje tänkbar produkt:

• Vad kunderna får: maskinvara, installerad programvara, nedladdningsbara komponenter eller en kombination.
• Vilka funktioner för fjärrdatabehandling som är nödvändiga för att produkten ska kunna utföra sina funktioner.
• Hur produkten tillhandahålls på EU-marknaden och vilken enhet som tillhandahåller den.
• Er roll som ekonomisk aktör: tillverkare, importör, distributör eller annan relevant roll.
• Tillämpliga undantag, produktspecifik lagstiftning och överväganden kring öppen källkod.
• Produktkategorin och de krav på bedömning av överensstämmelse som följer av den.

Öppen källkod kräver särskild noggrannhet. Hur programvara som tillhandahålls utanför kommersiell verksamhet behandlas innebär inte att en kommersiell tillverkare kan bortse från komponenter med öppen källkod som är inbyggda i dess produkt. Skilj den uppströms bidragsgivarens ställning från ert ansvar för den produkt ni tillhandahåller.

Den tekniska leveransen ska vara en kort post om tillämpningsområdet med ett arkitekturdiagram, produktidentifierare, relevanta kommersiella enheter, antaganden och en godkänd slutsats. Namnge den person som ansvarar för att öppna slutsatsen igen när funktionalitet eller distribution ändras.

Till exempel ska en nedladdningsbar administrationsapplikation och dess värdbaserade analystjänst inte automatiskt få ett enda odifferentierat beslut om tillämpningsområde. Identifiera vilka funktioner som körs lokalt, vilka som är beroende av tjänsten och om fjärrdatabehandlingen hör till produktgränsen. Den distinktionen påverkar riskbedömning, beroendeposter och ansvar för incidenter.

Utgå från de aktuella tillämpningsdatumen

Kommissionen anger 11 september 2026 för rapporteringsskyldigheterna och 11 december 2027 för CRA:s huvudsakliga krav. Per den 7 oktober 2026 har rapporteringsdatumet redan passerats. Behandla beredskapen för rapportering som ett aktuellt operativt krav, inte som en uppgift som skjuts upp tills förberedelserna för överensstämmelse.

Håll två arbetsströmmar synliga:

Produkter som tillhandahålls före det huvudsakliga tillämpningsdatumet kräver uppmärksamhet på övergångsbestämmelser och väsentliga ändringar. Anta inte att en äldre produkt saknar betydelse för rapporteringen bara för att den ursprungliga releasen skedde före december 2027.

Upprätthåll ett daterat register över rättsliga krav. För tröskelvärden för händelser, stegvisa rapporteringsfrister, mottagare och förfaranden för inlämning, kontrollera den aktuella rättsliga texten och officiell vägledning om genomförandet. Ersätt inte den CRA-specifika processen med en generisk mall för incidenthantering.

Omvandla säkerhetskraven till design- och releasekriterier

CRA:s väsentliga krav omfattar produktsäkerhetsegenskaper och sårbarhetshantering. Genomförandet ska följa produktens cybersäkerhetsriskbedömning snarare än en universell checklista som tillämpas utan arkitektoniskt sammanhang.

Börja med hur produkten kan orsaka skada. Beskriv användare, driftmiljöer, exponerade gränssnitt, privilegierade operationer, känsliga data och förutsebart missbruk. Ta med kundens driftantaganden: en enhet som installeras i ett industriellt nätverk har en annan exponering och andra återställningsbegränsningar än ett skrivbordsverktyg.

En praktisk övning i hotmodellering kan stödja arbetet; OWASP:s vägledning om hotmodellering erbjuder ett etablerat arbetssätt. Resultatet ska koppla hot till specifika krav, implementeringsbeslut och tester.

Fundera på hur välbekanta krav blir testbara:

Det här är praktiska exempel på implementering, inte en ersättning för de tillämpliga kraven. Avgör relevans och tillräcklighet genom riskbedömningen.

Lägg till säkerhetsrelaterade acceptanskriterier i funktionsarbetet. Ett nytt administrativt API ska levereras med beslut om autentisering, behörighet, hantering av indata och loggning – inte med ett löfte om att säkerhetsfunktionen ska granska det senare. Gå tillbaka till hotmodellen när ett fjärrgränssnitt, en privilegierad komponent eller en ny förtroendegräns läggs till.

Godkännandet av en release ska identifiera olösta sårbarheter, deras utnyttjbarhet, berörda konfigurationer och behandling. Tillämpa CRA:s krav på att produkter ska tillhandahållas på marknaden utan kända utnyttjbara sårbarheter, med hänsyn till riskbedömningen och tillämpliga väsentliga krav; att registrera eller acceptera en risk uppfyller inte i sig det kravet. Ett skanningsresultat ensamt kan inte fatta det beslutet: nåbarhet, förutsättningar och produktens beteende spelar roll. Omvänt är ett lågt numeriskt allvarlighetsvärde inte ett tillräckligt skäl att bortse från en sårbarhet som får betydande följder i er driftmodell.

Releaseposten ska koppla samman den godkända källkodsrevisionen, byggartefakten, beroendeförteckningen, testresultaten och säkerhetsbeslutet. Det gör bedömningen reproducerbar när en kund eller myndighet senare frågar om en specifik version.

Gör granskningen av komponenter till en del av byggprocessen

Tredjepartskomponenter skapar skyldigheter som inte kan fullgöras genom att vidarebefordra ett säkerhetsmeddelande från uppströmsleverantören. Ni behöver förstå vad ni levererade, om det är påverkat och hur ni kan åtgärda det.

CRA innehåller ett krav på en programvaruförteckning (SBOM) inom ramen för kraven på sårbarhetshantering: ett vanligt förekommande, maskinläsbart format som åtminstone omfattar beroenden på högsta nivå. Som praktisk rekommendation bör djupare beroendeinformation fångas där era byggverktyg kan ge tillförlitliga resultat. Transitiva beroenden avgör ofta exponeringen.

En SBOM är användbar bara när den motsvarar en verklig produktartefakt. Koppla den till releaseidentifieraren och bygget, och skilj levererade komponenter från verktyg som enbart används vid utveckling. Ta med firmware, operativsystemspaket, medföljande bibliotek och kommersiella komponenter där det är relevant; en export från pakethanteraren kan missa flera av dessa.

Bygg komponentgranskningen kring frågor som påverkar tekniska beslut:

• Underhålls komponenten, och är dess livslängd med support förenlig med vår?
• Kan vi snabbt få sårbarhetsinformation och säkerhetsuppdateringar?
• Har vi tillgång till källkoden, en patchväg via leverantören eller en ersättningsstrategi?
• Inför komponenten privilegierad körning eller en ny extern anslutning?
• Kan produkten fortfarande underhållas om leverantören upphör med supporten?

För kommersiella komponenter ska inköp fastställa säkerhetskontakter, arrangemang för aviseringar och tillgång till rättningar. Leverantörens tidsramar måste lämna utrymme för er egen bedömning och era rapporteringsskyldigheter. Produkttillverkaren behöver ändå en intern eskaleringsväg när en leverantörs svar är ofullständigt.

För beroenden med öppen källkod, bevara ursprungsinformation och en realistisk underhållsplan. Att ett arkiv är offentligt tillgängligt är inget belägg för att någon kommer att ta fram en kompatibel patch under er supportperiod.

Utforma supportperioden och uppdateringsmekanismen tillsammans

Support är ett tekniskt åtagande med kommersiella konsekvenser. CRA kräver generellt en supportperiod på minst fem år, om inte produktens förväntade användningstid är kortare. Fastställ den tillämpliga perioden utifrån förordningens kriterier i stället för att välja ett godtyckligt datum som passar färdplanen.

Registrera motiveringen, kommunicera den supportinformation som krävs till kunderna och koppla den till underhållna produktversioner. Supportåtagandet måste ta hänsyn till förmågan att leverera säkerhetsuppdateringar, inte bara till att en adress till kundtjänst finns kvar.

Innan en produkts supportplan godkänns, fråga om ni kan:

• Bygga om äldre grenar med support med underhållna verktygskedjor.
• Ta fram, autentisera och distribuera säkerhetsuppdateringar på ett säkert sätt.
• Testa rättningar i maskinvara och driftkonfigurationer som stöds.
• Underhålla signeringsnycklar och på ett säkert sätt återhämta er från en nyckelkompromettering.
• Hålla kundinriktad uppdaterings- och säkerhetsinformation tillgänglig.
• Hantera beroenden vars uppströmssupport upphör före er.

Säkerhetsuppdateringar ska i regel tillhandahållas kostnadsfritt under supportperioden, med förbehåll för förordningens bestämmelser. Varje säkerhetsuppdatering som utfärdas under perioden måste förbli tillgänglig i minst tio år efter utfärdandet eller under resten av supportperioden, beroende på vilken period som är längst. Planera säkerhetsrättningar separat från funktionsutveckling så att kunderna inte i onödan tvingas till orelaterade funktionella ändringar.

Testa mer än det lyckade flödet. Avbruten installation, otillräckligt lagringsutrymme, utgångna inloggningsuppgifter och misslyckad verifiering kan göra en giltig patch till ett tillgänglighetsproblem. Bestäm vilka återställningsmekanismer som behövs för produktens riskprofil.

När supporten upphör ska kundkommunikationen och de interna posterna stämma överens. Lämna inte kvar en nedladdningssida som antyder fortsatt säkerhetsunderhåll när produktregistret anger att åtagandet har upphört.

Bygg en rapporteringshandbok som klarar osäkerhet

Ett vanligt sårbarhetsfynd, en aktivt utnyttjad sårbarhet och en allvarlig incident är inte utbytbara. CRA:s rapporteringsprocess kräver en dokumenterad bedömning av den relevanta utlösande händelsen – inte automatisk rapportering av varje skannerlarm och inte automatiskt avfärdande av allt som saknar en slutförd forensisk utredning.

Handboken ska börja med mottagandet. Forskare, kundsupport, leverantörer och utvecklingsteam behöver en känd väg till produktsäkerhetsfunktionen. Bevara den ursprungliga rapporten och registrera när relevant information blev känd; återställ inte tidsstämplarna för när ni fick kännedom när ett ärende byter team.

Samla in följande för händelser som kan vara rapporteringspliktiga:

• Produktidentifierare och berörda versioner med support.
• Belägg för utnyttjande eller incidentens påverkan, med säkerhetsgrad och osäkerheter.
• Kända angreppsförutsättningar, berörda funktioner och driftantaganden.
• Tillgängliga åtgärder för att begränsa risken och status för korrigerande åtgärder.
• Bedömningen av den utlösande händelsen, rapporteringsansvarig och beräkningar av tillämpliga frister.
• Inlämnade anmälningar, mottagningsbekräftelser, senare uppdateringar och kundkommunikation.

Kontrollera de stegvisa anmälningsfristerna, kraven på slutrapport, mottagarna och det aktuella rapporteringsförfarandet mot officiella källor. Aktivt utnyttjade sårbarheter och allvarliga incidenter har olika rapporteringsdetaljer; ett enda kopierat fält för tidsfrist räcker inte.

Utse en primär rapporteringsansvarig och en ersättare med befogenhet att samordna teknik, juridik och kundkommunikation. Ordna åtkomst till den tillämpliga rapporteringsmekanismen i förväg. Juridisk granskning ska finnas tillgänglig inom rapporteringsfönstret i stället för att bli en obegränsad godkännandekö.

Öva processen med ofullständig information. En användbar övning börjar med en trovärdig rapport om utnyttjande, en osäker lista över berörda versioner och en komponentleverantör som inte går att nå. Teamet ska kunna fatta ett snabbt och dokumenterat rapporteringsbeslut medan utredningen fortsätter.

Rapportering enligt CRA ersätter inte andra tillämpliga skyldigheter. En produkthändelse kan också kräva en bedömning enligt dataskyddslagstiftningen eller ett kundavtal. Samordna bedömningarna men håll isär deras utlösande händelser, mottagare och beslutsposter.

Bekräfta klassificeringen innan bedömningsplanen väljs

Produktens klassificering påverkar vilken väg för bedömning av överensstämmelse som är tillgänglig. Anta inte att varje uppkopplad produkt behöver samma externa bedömning eller att varje tillverkare kan förlita sig på intern bedömning.

Fastställ den tillämpliga kategorin utifrån produktens funktioner och förordningens definitioner och bilagor. Bekräfta sedan den tillåtna vägen, inklusive eventuella villkor som rör harmoniserade standarder, erkända specifikationer, certifieringsordningar eller bedömning av tredje part.

Planeringen av standarder kräver ett uttryckligt beroenderegister: vilka referenser som är tillämpliga, deras aktuella status och vad som ändras om en förväntad väg inte är tillgänglig. Undvik att göra releaseplanen beroende av ett obekräftat antagande om standarder eller bedömningskapacitet.

Gå tillbaka till klassificeringen när funktionaliteten ändras. Att lägga till funktioner för säkerhetshantering eller nätverksstyrning kan påverka analysen, men ett funktionsnamn ensamt fastställer ingen kategori. Bedöm den faktiska funktionen och dokumentera slutsatsen.

Håll klassificeringen, den valda vägen och leveranserna för överensstämmelse kopplade till den tekniska dokumentationen. CE-märkning och EU-försäkran om överensstämmelse måste följa den tillämpliga processen; de ersätter inte genomförandet av de underliggande kraven.

Upprätthåll ett underlagspaket som kan förklara en release

Den tekniska dokumentationen ska beskriva både produkten och resonemanget bakom dess säkerhetsbeslut. Bevara riskbedömningar och dokumentation när produkten ändras, och tillämpa de lagstadgade kraven på lagringstid för de relevanta posterna.

Ett användbart underlagspaket för en produkt innehåller beslutet om tillämpningsområde, arkitekturen, riskbedömningen, säkerhetskraven, komponentinformationen, verifieringsresultaten, rutinerna för sårbarhetshantering, motiveringen till supportperioden och posterna om överensstämmelse. Varje del behöver en ägare och en identifierbar version.

Använd stabila identifierare för att koppla samman posterna. En sårbarhetspost ska förklara berörda versioner, exponering, behandling, release och nödvändig kommunikation. ”Åtgärdad” utan versionssammanhang lämnar produktunderlagen ofullständiga.

Befintliga ISMS-processer kan tillhandahålla användbara underlag om styrning, leverantörer och säker utveckling. ISO 27001 gäller dock ett avgränsat ledningssystem för informationssäkerhet; certifiering fastställer inte att en enskild produkt överensstämmer med CRA. Återanvänd relevanta underlag utan att behandla mappningar mellan ramverk som rättslig likvärdighet.

Räkneexempel: en brist i ett beroende i en enhet med support

Tänk dig en illustrativ tillverkare som tillhandahåller en nätverksansluten enhet i EU. Anta att dess tillämpningsområde och klassificering har granskats, att två releasegrenar fortfarande har support och att ett medföljande bibliotek rapporteras som aktivt utnyttjat på annat håll.

Den första uppgiften är inte att stänga uppströmsmeddelandet. Teknikteamet identifierar vilka byggen av enheten som innehåller det sårbara biblioteket och om den berörda funktionen är nåbar. SBOM:en tyder på att båda grenarna innehåller det, men konfigurationsanalysen visar olika exponering. Den skillnaden registreras med stödjande underlag.

Den produktsäkerhetsansvariga bedömer därefter om de tillgängliga fakta uppfyller den tillämpliga utlösande händelsen för rapportering enligt CRA. Osäkerhet kring en driftkonfiguration registreras; den motiverar inte att beslutsfattaren lämnas onamngiven. Rapporteringshandboken anger de aktuella anmälningsstegen och förfarandet.

Teknikteamet tar fram en tillfällig åtgärd och ett patchat bygge för varje berörd gren. Testerna omfattar den sårbara vägen, normal drift och installation av autentiserade uppdateringar. Om en gren inte kan använda uppströmspatchen registrerar teamet sin alternativa behandling och den kvarstående risken i stället för att markera hela produkten som åtgärdad.

Kundkommunikationen identifierar berörda versioner, omedelbara skyddsåtgärder och hur uppdateringen erhålls. Tidpunkten för offentliggörande samordnas med de tillämpliga kraven på sårbarhetshantering och eventuella motiverade säkerhetsöverväganden.

Den färdiga posten kopplar samman säkerhetsmeddelandet, analysen av berörda byggen, rapporteringsbeslutet, inlämningar där sådana krävs, patchcommits, testresultat, releaseartefakter och kommunikation. En granskare kan nu rekonstruera både den tekniska hanteringen och compliancebeslutet.

Börja med en produkt och en komplett underlagskedja

Välj en representativ produkt med support och spåra en nylig release och en sårbarhet genom livscykeln. Saknade versionskopplingar, oklara supportåtaganden och otillgängliga rapporteringsrutiner blir snabbt synliga. Omvandla varje lucka till en uppgift med en ägare och utvidga sedan modellen till hela portföljen.

Secani kan stödja det här arbetsflödet för underlag genom att koppla samman krav, underlag, ägare, uppgifter och granskningsbeslut. Utvecklingsverktygen förblir de operativa källorna för byggen, releaser och sårbarheter; compliancearbetsytan relaterar dessa poster till den tillämpliga skyldigheten. Håll mänskligt godkännande uttryckligt för mappningar och slutsatser, och bevara spårbarheten till källorna när AI-stödda utkast används.

Det omedelbara nästa steget är att testa rapporteringshandboken. Kräv parallellt att nästa produktrelease har ett kopplat beslut om tillämpningsområde, en aktuell riskbedömning, en komponentförteckning och ett säkerhetsgodkännande. Det skapar en repeterbar teknisk praxis medan förberedelserna för överensstämmelse fortskrider.