Fund i tredjepartskomponenter i jeres leverance: hvem fortæller kunden hvad?

Testen finder en svaghed, men koden er ikke jeres. Den sidder i et bibliotek, et styresystem, et indbygget modul eller en platform, som jeres leverance hviler på. Over for en NIS2-kunde er svaret alligevel jeres: kunden har en aftale med jer, ikke med producenten, og det er jer, der skal fortælle, hvad fundet betyder for kundens drift, hvad I gør, og hvad producenten har fået besked om.

Det hviler på to ting. Kundens egne regler beder kunden tage hensyn til kvaliteten af leverandørernes produkter, og en aftale med en NIS2-kunde kan indeholde en pligt for jer til at håndtere sårbarheder. Begge dele gør jer til kundens kontaktpunkt, også når I ikke selv kan skrive rettelsen. Teksten er ikke juridisk rådgivning.

Hvorfor kunden ser på jer og ikke på producenten

NIS2-direktivets artikel 21, stk. 3, beder de omfattede enheder tage hensyn til de sårbarheder, der er specifikke for hver direkte leverandør, og til den generelle kvalitet af leverandørernes produkter og cybersikkerhedspraksis. Ordet direkte er vigtigt. Kunden vurderer jer, og I vurderer de komponenter, I bygger ind.

Forordning 2024/2690 retter sig mod en afgrænset kreds af digitale udbydere som cloud, datacentre og administrerede tjenester, og den er bindende for dem. Bilaget, punkt 5.1.4, litra f, nævner en kontraktlig pligt for leverandøren til at håndtere sårbarheder, der udgør en risiko for kundens net- og informationssystemer. SAMSIK’s vejledning om foranstaltninger har et tilsvarende punkt på listen over, hvad aftaler med leverandører kan indeholde. Står pligten i jeres aftale, så læs, om den skelner mellem jeres egen kode og andres; gør den ikke det, omfatter den begge. → Pligt til at håndtere sårbarheder i leverandøraftalen

Tre parter og tre beskeder

Et tredjepartsfund giver tre forskellige beskeder, som ikke må blandes sammen:

Til producenten · en teknisk beskrivelse, der gør det muligt at genskabe og rette fejlen, sendt gennem producentens kanal for sårbarhedsmeldinger.
Til kunden · hvad fundet betyder for kundens brug af leverancen, hvad I gør nu, og hvornår kunden hører fra jer igen.
Internt hos jer · hvem der følger sagen, hvilke andre leverancer der bruger samme komponent, og hvad der står i jeres aftaler.

Kunden har ikke brug for producentens tekniske detaljer for at handle. Kunden har brug for at vide, om egne systemer er udsatte, og om der er noget, kunden selv skal gøre i mellemtiden. Hold derfor de tre beskeder i hver sin tråd, med hver sin modtager og hver sin dato, så det senere kan ses, hvem der vidste hvad og hvornår. Det er også den dokumentation, kunden kan spørge efter ved næste opfølgning.

Kendt fejl eller ny fejl

Det gør en forskel, om svagheden allerede er kendt.

Er der en offentlig sårbarhed og en rettelse fra producenten, handler sagen om, hvorfor rettelsen ikke er installeret, og hvornår den bliver det. Kunden spørger her til jeres opdateringsrutiner mere end til komponenten. → Opdateringer fra jer til kunden

Er svagheden ny, og kender producenten den ikke, er I i en anden rolle. Så skal producenten have besked først eller samtidig med kunden, og oplysningerne til kunden skal holdes på et niveau, der ikke gør det lettere at udnytte fejlen hos andre, før en rettelse findes. Aftal med producenten, hvad der må siges hvornår. → Koordineret offentliggørelse af sårbarheder

Når I selv er producent af et produkt

Leverer I et produkt med digitale elementer, kan forordning (EU) 2024/2847 om cyberrobusthed få betydning. Dens artikel 13, stk. 6, beskriver, at fabrikanten, når den finder en sårbarhed i en integreret komponent, indberetter den til den, der fremstiller eller vedligeholder komponenten, og selv håndterer sårbarheden. Ifølge artikel 71 gælder forordningen fra 11. december 2027, mens artikel 14 om fabrikantens indberetning af aktivt udnyttede sårbarheder gælder fra 11. september 2026. Om jeres leverance er omfattet, er en selvstændig vurdering. → Udstyr og software, I leverer ind i kundens net

Hvad kunden selv kan bruge beskeden til

Forordningens bilag, punkt 6.10.2, litra a, beder de enheder, den gælder for, overvåge oplysninger om sårbarheder gennem kanaler som meddelelser fra CSIRT’er, myndigheder og leverandører. Jeres besked er en af de kanaler. Den bliver brugbar for kunden, når den svarer på det, kundens egen vurdering kræver:

Berørt del af leverancen · hvilken funktion eller installation komponenten indgår i.
Eksponering · om svagheden kan nås udefra, kun af brugere med login eller kun lokalt.
Status hos producenten · kendt, meldt, rettelse findes eller ingen rettelse endnu.
Jeres plan · opdatering, midlertidigt tiltag eller udskiftning af komponenten.
Kundens del · om kunden selv skal gøre noget, fx installere en opdatering.

Et tænkt eksempel

En leverandør af et vagtplansystem til en kommune får testet systemet. Testen finder en svaghed i en komponent til dokumentvisning, som indgår i systemet. Producenten har ingen rettelse.

Leverandøren melder fejlen til producenten gennem dennes kontaktadresse og slår samtidig funktionen fra for kommunens brugere. Kommunen får en kort besked: hvilken funktion er påvirket, at den er slået fra, at producenten er orienteret, og hvornår næste status kommer. Da producenten udsender en rettelse, installeres den, funktionen slås til igen, og leverandøren beder testeren efterprøve den. Kommunen får en afsluttende status med dato for efterprøvningen. → Kritisk fund, der berører kunden

Det skal I lade være med

At henvise kunden til producenten · kunden har en aftale med jer og kan ikke bruge et svar om, at fejlen er en andens.
At sende producentens tekniske detaljer videre · en udførlig beskrivelse af en ny fejl hører hos producenten.
At vente med kunden, til producenten svarer · kunden kan have brug for at vurdere egen risiko nu.
At glemme jeres andre leverancer · samme komponent kan sidde andre steder.
At love en dato, producenten bestemmer · skriv, hvad I selv kan gøre, og hvad I afventer.

Hvad kan og ikke kan konkluderes

En test kan vise, at en komponent i leverancen har en svaghed, som den bruges på testdagen. Den kan ikke vise, om komponenten har andre svagheder, eller hvornår producenten retter fejlen. En velgennemført håndtering viser kunden, at I har overblik over komponenterne og tager ansvar for dem over for kunden. Den siger intet om producentens arbejde. Hvordan et softwarehus generelt besvarer kundens spørgsmål om komponenter, er en sag for sig, se fx pentestrapport.dk.

Tjekliste ved et tredjepartsfund

☐ Er komponenten og den berørte del af leverancen præcist beskrevet?
☐ Er producenten orienteret gennem sin egen kanal?
☐ Har kunden fået en besked om eksponering, plan og kundens egen del?
☐ Er det aftalt med producenten, hvad der må siges hvornår?
☐ Er andre leverancer med samme komponent undersøgt?
☐ Er der aftalt en dato for næste status til kunden?

Kilder

NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 3, om leverandørers sårbarheder og produktkvalitet.
Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4, litra f, og 6.10.2, litra a. Gælder for de digitale udbydere, der er nævnt i artikel 1.
Forordning (EU) 2024/2847 om cyberrobusthed: artikel 13, stk. 6, og artikel 71 om anvendelsesdatoer.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om aftaler med leverandører og afsnit 5.b om håndtering af sårbarheder.

Senest gennemgået: oktober 2026.