Kunden får en advarsel om jeres produkt fra en anden kilde

En mandag morgen skriver kundens sikkerhedsansvarlige: “Vi har set en advarsel om en sårbarhed i en komponent, som jeres løsning bygger på. Er vi berørt?” I har ikke selv meldt noget, og jeres seneste penetrationstest nævnte ikke fejlen. Situationen er ikke tilfældig. NIS2-kunder er bedt om at følge med i oplysninger om sårbarheder fra flere kilder, også fra myndigheder og leverandører, og de spørger derfor ind, når en kilde nævner noget, I leverer.

Svaret hviler på bilaget til gennemførelsesforordning (EU) 2024/2690, punkt 6.10.2, litra a, og på SAMSIK’s vejledning om foranstaltninger, som siger det samme for andre kunder. Teksten er ikke juridisk rådgivning.

Hvorfor kunden ser advarslen før jer

Forordningens punkt 6.10.2, litra a, siger, at de relevante enheder skal overvåge oplysninger om sårbarheder gennem passende kanaler, såsom meddelelser fra CSIRT’er, kompetente myndigheder eller oplysninger fra leverandører eller tjenesteudbydere. Punkt 6.10.4 tilføjer, at kanalerne gennemgås med planlagte mellemrum. Forordningen gælder bestemte digitale udbydere, blandt andre cloud, datacentre og administrerede tjenester.

SAMSIK’s vejledning om foranstaltninger, afsnit 5.b, siger tilsvarende, at enheden bør følge med i informationer om sårbarheder fra forskellige kilder, fx meddelelser fra CSIRT, den sektoransvarlige myndighed eller leverandører. Kunden har altså en grund til at holde øje, og en kunde med en god overvågning kan finde en relevant oplysning, før I har nået at vurdere den. → SAMSIK’s vejledning om tekniske test

Hvad kunden vil vide

Kundens spørgsmål kan deles op i fire:

Er I berørt? · bruger jeres leverance den komponent eller den udgave, advarslen nævner?
Er kunden berørt? · er den sårbare del i brug i netop kundens opsætning?
Hvad gør kunden imens? · er der noget, kunden selv bør gøre, før I har en rettelse?
Hvornår hører kunden fra jer igen? · en tid for næste besked, også selv om svaret endnu er uklart.

Et ærligt foreløbigt svar er bedre end tavshed. “Vi undersøger det og vender tilbage inden i morgen middag” giver kunden noget at handle på. → Kritisk fund, der berører kunden

At kunne svare hurtigt

Hastigheden afhænger af ét forhold: om I ved, hvilke komponenter og udgaver jeres leverance består af. Uden en ajourført oversigt bliver hvert spørgsmål til en undersøgelse fra bunden. Med den kan I hurtigt svare på det første spørgsmål og bruge tiden på det næste.

ENISA’s tekniske vejledning til forordningen, som ikke er bindende, nævner som eksempel på dokumentation en liste over kanaler til overvågning af sårbarheder, herunder leverandørers og tjenesteudbyderes faste kontaktpunkter. Hvis kunden har jer på sådan en liste, forventer kunden også, at I har et kontaktpunkt, der kan svare. Aftal, hvem det er, og giv kunden navnet på funktionen, ikke kun en generel postkasse.

Advarsler om komponenter kan henvise til et CVE-nummer, som er en fælles identifikation af en offentligt kendt sårbarhed. Når kunden henviser til et nummer, kan I slå det op og sammenholde det med jeres oversigt. → Fund i tredjepartskomponenter i jeres leverance

Hvorfor testen ikke fandt det

Kunden kan spørge, hvorfor den seneste test ikke nævnte sårbarheden. Der kan være flere forklaringer. Sårbarheden kan være blevet kendt efter testen. Den kan sidde i en del af leverancen, som ikke var med i omfanget. Eller den kan være af en type, som testen ikke var tilrettelagt til at finde.

Svar konkret ud fra testens dato og omfang. Det er ikke en fejl ved testen, at den ikke kendte en sårbarhed, der først blev offentlig bagefter. En penetrationstest er et øjebliksbillede, og det er netop derfor, forordningen ved siden af test kræver løbende overvågning og sårbarhedsscanninger med planlagte mellemrum, hvor det er relevant. → Hvad testdokumentationen ikke kan bevise

Hvad testen kan bruges til bagefter

Når I har vurderet advarslen, kan en test få to roller. Den ene er at efterprøve, om rettelsen eller et midlertidigt tiltag virker i jeres leverance. Den anden er at undersøge, om den samme slags svaghed findes andre steder, fx i andre dele, der bygger på samme komponent.

Aftal med kunden, om en sådan efterprøvning er nødvendig, eller om en dokumenteret opdatering er nok. Det afhænger af sårbarhedens alvor og af, hvor tæt den ligger på det, kunden er afhængig af. Rammer advarslen flere kunder, gælder de samme hensyn til fortrolighed og rækkefølge som ved et testfund. → Fund, der også rammer andre kunder

Et tænkt eksempel

En leverandør af et system til styring af adgangskort hos en fødevareproducent får en mail fra producentens IT-chef. Den nationale CSIRT har omtalt en sårbarhed i et bibliotek til håndtering af login, og IT-chefen vil vide, om adgangssystemet er berørt. Leverandøren slår bibliotekets udgave op i sin komponentoversigt og ser, at den sårbare udgave indgår i administrationsmodulet, men ikke i den del, kortlæserne bruger. Inden for få timer får producenten et foreløbigt svar: hvilken del er berørt, at modulet midlertidigt kun kan nås fra producentens eget net, og hvornår næste besked kommer. En uge senere installeres en opdateret udgave, og en kort efterprøvning bekræfter, at svagheden ikke længere kan nås ad den beskrevne vej.

Det skal I lade være med

At vente med at svare, til I har det fulde billede · kunden har brug for et foreløbigt svar.
At afvise spørgsmålet med henvisning til den seneste test · testen dækker ikke senere kendte sårbarheder.
At svare “ikke berørt” uden at have tjekket udgaven · kunden kan handle på jeres svar.
At lade kunden finde kontaktpunktet selv · aftal det, før advarslen kommer.
At lade sagen gå i stå efter første svar · kunden skal have besked, når status ændres.

Hvad kan og ikke kan konkluderes

At kunden får en advarsel om jeres produkt fra en anden kilde, siger ikke, at I har gjort noget forkert. Det viser, at kunden følger med, som reglerne beskriver. Et hurtigt og præcist svar viser, at I kender jeres leverance og har en fast vej for den slags spørgsmål. En tidligere test siger noget om sårbarheder, der var kendte og inden for omfanget på testtidspunktet, ikke om dem, der er kommet til siden. → Sårbarheder, som andre melder til jer

Tjekliste, når advarslen kommer

☐ Har I en ajourført oversigt over komponenter og udgaver i leverancen?
☐ Er der et kendt kontaktpunkt, som kunden kan skrive til?
☐ Har kunden fået et foreløbigt svar med tid for næste besked?
☐ Er det afklaret, om I og kunden er berørt?
☐ Ved kunden, om der er noget, kunden selv skal gøre?
☐ Er det aftalt, om rettelsen skal efterprøves?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 6.10.2, litra a og b, og 6.10.4.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 5.b om håndtering af sårbarheder.
ENISA, NIS2 Technical Implementation Guidance (juni 2025): vejledning til punkt 6.10.4 om kanaler og kontaktpunkter, ikke bindende.
CVE: fælles identifikation af offentligt kendte sårbarheder.

Senest gennemgået: oktober 2026.