Når en sårbarhed i et udbredt bibliotek bliver udnyttet, skal hver fabrikant indberette, hvis sårbarheden er aktivt udnyttet i netop dens produkt. Kommissionen forklarer, at en sårbarhed, der ikke kan udnyttes eller ikke er udnyttet i produktet, ikke er omfattet af pligten for den fabrikant.
Den bedste måde at forstå forskellen på er at følge en tænkt sag. De tre softwarehuse nedenfor findes ikke. De er konstrueret for at vise tre udfald.
Udgangspunktet
Et open source-bibliotek til behandling af billedfiler bruges af mange. En onsdag offentliggør en forsker, at en fejl i biblioteket giver mulighed for at køre kode ved behandling af en særlig fil. Dagen efter melder en sikkerhedsmyndighed, at fejlen udnyttes mod virksomheder.
Tre danske softwarehuse har biblioteket i deres produkter:
- Hus A laver et dokumenthåndteringssystem, hvor brugerne uploader billeder, som behandles med den sårbare funktion.
- Hus B har biblioteket med i sin app, men bruger kun en funktion til at læse metadata. Den sårbare kode bliver aldrig kaldt.
- Hus C bruger den sårbare funktion, men har ingen tegn på, at nogen har udnyttet den i deres produkt.
Hvad Kommissionen siger
Kommissionens FAQ (punkt 5.4) og vejledningen (punkt 218) forklarer, at fabrikanten skal indberette en aktivt udnyttet sårbarhed i sit produkt, også når den stammer fra en integreret komponent. Komponentens egen fabrikant skal også indberette, hvis komponenten er bragt i omsætning.
Vejledningen tilføjer, at en kendt sårbarhed i en tredjepartskomponent ikke er en aktivt udnyttet sårbarhed i fabrikantens produkt, hvis den ikke kan udnyttes i produktet, eller hvis den ikke er udnyttet i produktet. Kommissionens eksempel på det første er sårbar kode, der ikke kan nås. I begge tilfælde er den ikke omfattet af pligten for den fabrikant. Kommissionen peger i stedet på frivillig indberetning efter artikel 15, som efter artikel 71, stk. 2, gælder fra 11. december 2027.
Hus A: indberetning
Hus A får henvendelser fra to kunder, der har set mistænkelige filer i systemet, og en logfil viser, at en fremmed har kørt kommandoer på serveren. Efter en første vurdering har huset en rimelig grad af sikkerhed for, at sårbarheden er udnyttet i produktet. Pligten efter artikel 14 er udløst, og den tidlige varsling skal ud inden for 24 timer.
At fejlen sidder i en andens kode, ændrer ikke på det. Det er Hus A’s produkt, der er udnyttet.
Hus B: ikke omfattet, men dokumentér hvorfor
Hus B kan vise, at den sårbare funktion ikke bliver kaldt fra appen. Efter Kommissionens forklaring er sårbarheden da ikke en aktivt udnyttet sårbarhed i Hus B’s produkt. Der er ingen indberetningspligt for Hus B.
Konklusionen er kun lige så stærk som beviset. Hus B bør kunne vise den analyse, der viste, at koden ikke kan nås, hvem der lavede den, og hvornår. Det er praksis og ikke et krav, men uden dokumentationen er det svært at forklare en myndighed, hvorfor der ikke blev varslet. Hvordan sådan en vurdering skrives, står i “Ikke berørt”: den dokumenterede vurdering.
Hus C: ikke omfattet nu, men hold øje
Hus C har sårbar kode, der kan nås, men ingen tegn på udnyttelse i eget produkt. Efter vejledningen er sårbarheden ikke aktivt udnyttet i Hus C’s produkt, og pligten er ikke udløst. Hus C kan overveje den frivillige vej, som Kommissionen nævner.
Situationen kan ændre sig fra time til time. Kommer der en henvendelse fra en kunde om usædvanlig aktivitet, skal Hus C vurdere den straks. Kendskabet kan opstå senere end hos de andre, og så starter fristen der. Hus C bør desuden rette eller afbøde hurtigt, fordi koden er udsat.
Hvem melder opstrøms?
Kommissionen forklarer også, hvornår en fabrikant skal melde til den, der vedligeholder komponenten (vejledningen punkt 222 til 225 om artikel 13, stk. 6). Pligten gælder den version, fabrikanten integrerer. Den gælder ikke, når fabrikanten kan bekræfte, at vedligeholderen allerede kender sårbarheden, når sårbarheden først opstår ved integrationen, eller når komponenten ikke længere har en vedligeholder. Vedligeholderens egne kanaler og politik følges.
Artikel 13 gælder først fra 11. december 2027. I dag er opstrømsmeldingen altså god praksis. I den tænkte sag er sårbarheden allerede offentlig, og vedligeholderen kender den. Hvordan opstrømsmeldingen bliver en pligt fra december 2027, står i sårbarhed i en andens komponent.
Det, sagen viser om forberedelsen
Alle tre huse skal kunne svare på samme spørgsmål hurtigt: hvilke produkter og versioner indeholder biblioteket, og hvilke dele af det bliver brugt? Uden en komponentliste pr. version kan ingen af dem afgøre, om de er Hus A, B eller C. Komponentlisten gælder som krav fra december 2027, men indberetningspligten gælder allerede.
Hvad det kræver, og hvad det koster at lade være
Det kræver en komponentliste pr. version, en metode til at afgøre, om sårbar kode kan nås, og en skabelon til at dokumentere vurderingen pr. sårbarhed.
Uden dem kan et softwarehus ikke vide, om det skal varsle. Vælger det at lade være uden en begrundelse, står det svagt, hvis det senere viser sig, at produktet var udnyttet.
Det skal I lade være med
- At gå ud fra, at det er bibliotekets udvikler, der indberetter · pligten følger det udnyttede produkt.
- At konkludere “ikke berørt” uden en analyse · beviset er det, der bærer konklusionen.
- At kalde opstrømsmelding en lovpligt i dag · artikel 13 gælder fra 11. december 2027.
Det skal auditten kunne vise
- ☐ En komponentliste pr. udgivet version.
- ☐ En dokumenteret vurdering pr. sårbarhed i en komponent med dato og ansvarlig.
- ☐ Begrundelsen, når en sårbarhed vurderes som ikke udnyttet eller ikke udnyttelig i produktet.
- ☐ Et spor af frivillige eller opstrøms meldinger, hvor de er sendt.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 6, artikel 14 og artikel 15, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 218 og 222-225, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 5.4, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg et udbredt bibliotek i jeres produkter og afgør, om I ville være Hus A, B eller C.
Læs også: Overvågning af komponenter for hver understøttet version · Aktivt udnyttet sårbarhed
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
