Finder et softwarehus en sårbarhed i en komponent, det har integreret, skal det fra 11. december 2027 indberette den til den, der fremstiller eller vedligeholder komponenten. Har softwarehuset selv lavet en rettelse, skal den deles med vedligeholderen, hvor det er relevant. Pligten står i artikel 13, stk. 6, og gælder også open source.
Kommissionens vejledning sætter en række grænser for pligten. Artiklen følger en tænkt sag fra opdagelse til deling af rettelsen og viser, hvor grænserne går.
Pligten
Artikel 13, stk. 6, siger, at fabrikanten, når den identificerer en sårbarhed i en komponent, der er integreret i produktet, herunder i en open source-komponent, giver besked om sårbarheden til den, der laver eller passer komponenten. Fabrikanten håndterer og afhjælper sårbarheden efter kravene i bilag I, del II. Har fabrikanten udviklet en software- eller hardwareændring for at afhjælpe sårbarheden, deler den den relevante kode eller dokumentation med den, der fremstiller eller vedligeholder komponenten, hvor det er relevant i et maskinlæsbart format.
Bilag I, del II, nr. 6, peger samme vej. Her skal fabrikanten gøre det let at udveksle viden om mulige sårbarheder, både i eget produkt og i de komponenter fra andre, der indgår i det.
En tænkt sag, trin for trin
Et softwarehus bruger et open source-bibliotek til at læse et filformat. Under en intern test finder en udvikler, at en bestemt fil får biblioteket til at skrive uden for sin hukommelse. Sagen er tænkt.
Trin 1: Er det komponentens sårbarhed? Vejledningen siger, at pligten kun gælder sårbarheder i selve komponenten. Opstår fejlen, fordi softwarehuset bruger biblioteket forkert, er det en sårbarhed i integrationen, og pligten til at indberette opstrøms gælder ikke. Kommissionen opfordrer dog til at fortælle vedligeholderen om adfærd, integrationen afslører.
Trin 2: Kender vedligeholderen den allerede? Ved I med sikkerhed, at projektet allerede har fået sårbarheden at vide, falder pligten bort. Vejledningen opfordrer til at undgå dobbeltmeldinger ved at se i offentlige databaser, projektets meddelelser og fejlsporingssystemer.
Trin 3: Hvilken version? Pligten gælder den version af komponenten, fabrikanten har integreret.
Trin 4: Hvordan meldes den? Vejledningen siger, at fabrikanten bruger vedligeholderens politik, koordinerede proces eller kanal. Har projektet en beskrevet måde at modtage sårbarheder på, er det den, der bruges.
Trin 5: Egen håndtering. Uanset meldingen opstrøms skal softwarehuset håndtere og afhjælpe sårbarheden i sit eget produkt efter del II. Det kan ikke vente på, at vedligeholderen retter.
Trin 6: Deling af rettelsen. Har softwarehuset selv lavet en rettelse, deles koden eller dokumentationen, hvor det er passende, i et maskinlæsbart og let efterprøveligt format. For open source skal det ske på en måde, der er forenelig med komponentens licens.
Grænserne
Vejledningen trækker flere grænser, som er værd at kende, fordi de ofte overses.
- Der er ingen pligt til at sikre, at rettelsen bliver accepteret eller indarbejdet hos vedligeholderen.
- Fabrikanten er ikke forpligtet til at acceptere vedligeholderens egen rettelse, hvis den foretrækker en anden løsning.
- Der er ingen pligt til at dele en anden afbødning, for eksempel en konfigurationsændring, men Kommissionen opfordrer til det.
- Har komponenten ingen vedligeholder, eller bruger fabrikanten ikke længere den oprindelige vedligeholder, gælder pligten ikke. Kommissionen opfordrer da til at informere brugere af komponenten på anden måde.
Når vedligeholderen ikke reagerer
FAQ’en beskriver situationen, hvor udvikleren af en komponent, der ikke er omfattet af forordningen, ikke støtter fabrikanten. Så må fabrikanten finde andre veje, for eksempel ved at slå funktioner fra, skifte komponenten eller selv udvikle en rettelse. Er komponenten derimod CE-mærket, kan fabrikanten støtte sig til komponentproducentens egne pligter, men skal stadig selv informere brugerne, afbøde og opdatere sin dokumentation.
Forholdet til indberetning efter artikel 14
Beskeden til vedligeholderen er en anden pligt end indberetningen til myndighederne efter artikel 14, der har været gældende siden 11. september 2026 og handler om sårbarheder, der aktivt bliver udnyttet. Er sårbarheden i komponenten aktivt udnyttet, kan begge pligter være i spil. Det behandles i artiklerne om indberetning.
Hvad en gennemgang ser efter
En almindelig fremgangsmåde er at finde de sager i sårbarhedsregistreringen, hvor årsagen lå i en tredjepartskomponent, og følge sporet. Blev det afklaret, om sårbarheden lå i komponenten eller i integrationen? Blev det undersøgt, om vedligeholderen kendte den? Hvornår og hvordan blev den meldt? Blev en egen rettelse delt? Hvor der ikke blev meldt, er der så en begrundelse, for eksempel at vedligeholderen allerede kendte den?
Hvad det kræver, og hvad det koster at lade være
Det kræver en procedure for fund i tredjepartskomponenter, der skelner mellem komponent og integration, kontrollerer, om sårbarheden er kendt, og registrerer meldingen og eventuel deling af rettelser.
Uden den bliver meldingen opstrøms afhængig af den enkelte udviklers vane. Og sårbarheden kan blive siddende i komponenten og ramme andre, mens jeres egen rettelse kun beskytter jeres produkt.
Det skal I lade være med
- At vente på vedligeholderen med jeres egen afhjælpning · del II gælder jeres produkt uanset.
- At melde uden at se, om sårbarheden er kendt · vejledningen opfordrer til at undgå dobbeltmeldinger.
- At dele en rettelse på en måde, der strider mod licensen · delingen skal være forenelig med den.
Det skal auditten kunne vise
- ☐ En procedure for sårbarheder i tredjepartskomponenter.
- ☐ For udvalgte sager: afklaring af komponent eller integration.
- ☐ Kontrol af, om vedligeholderen kendte sårbarheden.
- ☐ Dato og kanal for meldingen opstrøms.
- ☐ Deling af egen rettelse, hvor den findes, eller begrundelse for at lade være.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 6, og bilag I, del II, nr. 6, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 222-229, læst 13. november 2026.
- Kommissionens tjenestegrene, FAQs on the Cyber Resilience Act, version 1.4, afsnit 4.3.6, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste sårbarhed, der lå i en tredjepartskomponent, og se, om den blev meldt til vedligeholderen.
- Softwarekomponentliste, afhængigheder og tredjepartskomponenter
- Politik for koordineret offentliggørelse og det centrale kontaktpunkt
Læs også: Komponentens support slutter · En udnyttet sårbarhed i et bibliotek, mange bruger
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
