Artikel 14, stk. 5, gør en hændelse alvorlig, når den rammer produktets evne til at beskytte data og funktioner, eller når den kan føre ondsindet kode ud til brugerne. Et kompromitteret kodelager, byggemiljø eller opdateringsserver kan derfor udløse en indberetning inden for 24 timer.
De tre steder nævnes ikke i forordningen. At de kan være omfattet, er vores tolkning af bestemmelsen, og den uddybes nedenfor. Spørgsmålet, en gennemgang stiller, er, om softwarehuset kan skelne en sådan hændelse fra en almindelig driftshændelse.
De to kriterier i artikel 14, stk. 5
En hændelse med indvirkning på produktets sikkerhed er alvorlig, hvis mindst ét af to forhold gælder:
- Litra a: Den påvirker eller kan påvirke evnen til at beskytte tilgængelighed, autenticitet, integritet eller fortrolighed af følsomme eller vigtige data eller funktioner negativt.
- Litra b: Den har ført til eller kan føre til, at ondsindet kode indføres eller udføres i produktet eller i brugerens net- og informationssystemer.
Definitionen af en hændelse med indvirkning på produktets sikkerhed i artikel 3, nr. 44, handler om produktets evne til at beskytte data eller funktioner. Udgangspunktet er altså produktet hos brugeren. Jeres egen drift kommer først ind i billedet, når den rører ved det.
Hvorfor kodelager og byggekæde kan være omfattet
Litra b taler om ondsindet kode i produktet. Software når brugerne gennem en kæde: kildekoden ligger i et lager, bygges i et miljø, signeres og lægges på en server, som klienten henter fra. Får en uvedkommende fodfæste et af de steder, kan resultatet være en opdatering med indhold, I ikke selv har skrevet.
Derfor læser vi en kompromittering af kodelager, byggemiljø eller opdateringsserver som en hændelse, der kan falde under litra b. Ordet “kan” er vigtigt. Det afhænger af, om der er en realistisk vej fra kompromitteringen til produktet hos brugeren. Er angriberen nået ind på en testserver uden forbindelse til byggekæden, ser billedet anderledes ud end ved adgang til signeringsnøglerne.
ENISA’s glossar til indberetningsplatformen bruger selv lignende eksempler. Som trusselstype nævnes en kompromittering af forsyningskæden via en uautoriseret ændring af opdateringspakken, og som hændelsens art ondsindet kode leveret via opdateringstjenesten. Det er eksempler i et udfyldningsglossar og ikke en regel, men de viser, at ENISA forventer den slags sager på platformen.
Driftshændelse eller produkthændelse?
Mange hændelser i et softwarehus rammer kun virksomhedens egne systemer: en phishingmail, der giver adgang til en mailkonto, en nedlagt hjemmeside eller en krypteret filserver. Om de har indvirkning på produktets sikkerhed, afhænger af, hvad den angrebne del kunne nå.
En gennemgang kan bede om at se, hvordan huset træffer den vurdering. Spørgsmål, der ofte afslører hullerne:
- Ved I, hvilke systemer der kan ændre det, brugerne modtager? Kodelager, byggeservere, pakkeregistre, signeringsnøgler, opdateringsserver og distributionskanaler.
- Er adgangen til de systemer logget, så I kan se, hvad en angriber har kunnet gøre?
- Hvem afgør, om en hændelse når produktet, og står kriterierne skrevet?
- Kan I afgøre, hvilke udgivne versioner der er bygget eller distribueret i perioden med kompromittering?
Er svaret på det fjerde spørgsmål nej, er det svært at sige, hvem der er berørt, og hvilke medlemsstater der skal stå i varslingen.
Det, varslingen skal sige
For en alvorlig hændelse skal varslingen inden for 24 timer som minimum oplyse, om der er mistanke om ulovlige eller ondsindede handlinger, og hvor det er relevant hvilke medlemsstater der er berørt (artikel 14, stk. 4, litra a). Efter 72 timer kommer en underretning med arten af hændelsen og en indledende vurdering. Den afsluttende rapport skal være inde senest en måned derefter og skal beskrive trusselstype eller grundlæggende årsag.
Grundlæggende årsag er netop det, en kompromitteret byggekæde gør svært at finde. Derfor betaler det sig at kende kæden, før noget sker.
Hvad gennemgangen holder op mod
Bilag I, del I, nr. 2, litra f, kræver beskyttelse af integriteten af data, programmer og konfiguration. Kravene i bilaget gælder fra 11. december 2027. Indberetningspligten for alvorlige hændelser gælder allerede. Det giver en særlig situation: I kan i dag have en hændelse, der skal indberettes, i en byggekæde, som forordningens produktkrav først stiller krav til om et år.
En gennemgang ser derfor på begge dele: om kæden kan forsvares, og om en kompromittering vil blive opdaget og vurderet i tide. Sikker distribution af opdateringer er beskrevet i signering, kanal og kontrol i klienten.
Hvad det kræver, og hvad det koster at lade være
Det kræver en oversigt over de systemer, der kan ændre det udgivne produkt, logning af adgangen til dem og skrevne kriterier for, hvornår en hændelse vurderes efter artikel 14, stk. 5.
Uden oversigten bliver hver hændelse vurderet på fornemmelse. Opdages en kompromitteret opdateringsserver først, når kunderne melder sig, er fristen måske allerede løbet, og det bliver svært at sige, hvilke versioner der skal trækkes tilbage.
Det skal I lade være med
- At behandle et indbrud i byggekæden som en ren IT-sag · det kan være en hændelse i produktet.
- At slette logfiler under oprydningen · de skal bruges til at finde berørte versioner.
- At vente på den grundlæggende årsag, før I varsler · den hører til den endelige rapport.
Det skal auditten kunne vise
- ☐ En oversigt over systemer, der kan ændre det, brugerne modtager.
- ☐ Logning af adgang til kodelager, byggemiljø, signeringsnøgler og opdateringsserver.
- ☐ Skrevne kriterier for vurderingen efter artikel 14, stk. 5.
- ☐ Evnen til at koble en periode med kompromittering til bestemte versioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 3, nr. 44, artikel 14, stk. 3-5, og bilag I, del I, læst 13. november 2026.
- ENISA, CRA SRP Glossary, version 1.6, felt i32 og i36, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv de systemer op, der kan ændre en opdatering, før den når kunden, og find ud af, hvem der har adgang til dem.
Læs også: Indberetningspligten gælder nu · Efter indberetningen
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
