Kunden spørger efter en kendt sårbarhed: er jeres produkt ramt?

En sårbarhed får omtale, og samme dag skriver en kunde og spørger, om jeres produkt er berørt. Svaret hviler på jeres overblik over de komponenter og versioner, produktet består af, og ikke på den seneste pentestrapport.

Til kunden er der i praksis tre mulige svar: ikke berørt, berørt og under håndtering, eller endnu ikke afklaret med et tidspunkt for næste besked. Pentesten kan indgå som baggrund, men den kan sjældent afgøre spørgsmålet alene, fordi den beskriver produktet, som det så ud på et tidligere tidspunkt.

Spørgsmålet kommer, før svaret er klar

Kundens henvendelse kan være udløst af en nyhed, en advarsel fra en myndighed eller en intern liste i kundens egen sikkerhedsfunktion. Kunden skal kunne markere jer som afklaret, og for dem haster det. For jer handler opgaven om at svare hurtigt uden at sige mere, end I ved.

Har sårbarheden et CVE-nummer, findes der et fælles navn at tale ud fra. CVE-programmet giver offentligt kendte sårbarheder en fælles identifikator, så kunden og softwarehuset taler om det samme. Bed om nummeret, hvis henvendelsen kun nævner et produktnavn eller en overskrift fra pressen. Flere sårbarheder kan have næsten enslydende navne, og et svar på den forkerte er værre end at bede om et døgns afklaring.

Sårbarheder, der vides at blive udnyttet, får ekstra opmærksomhed. Den amerikanske myndighed CISA fører et katalog over kendt udnyttede sårbarheder, og kunder bruger den slags lister som afsæt for deres spørgsmål. At en sårbarhed står på listen, siger noget om udnyttelse i almindelighed. Om netop jeres produkt er udsat, siger det intet.

Det kan pentestrapporten bidrage med

Rapporten fra seneste test viser, at bestemte dele af produktet blev afprøvet i en bestemt periode. Den kan også nævne komponenter eller versioner, testeren lagde mærke til undervejs. En sårbarhed, der blev offentliggjort efter testen, kan derimod ikke være vurderet i rapporten. Og en pentest gennemgår ikke systematisk hver eneste afhængighed i koden.

Brug derfor ikke rapporten som svaret. En sætning om, at seneste test var uden alvorlige fund, kan let blive læst som et nej til kundens spørgsmål, selv om den handler om noget andet. Hold de to ting adskilt i svaret, og nævn kun testen, hvis kunden spørger til den. → Hyppige udrulninger: hvilken version skal testes?

Overblikket, der giver svaret

Svaret kommer fra jeres egen viden om produktet: hvilke tredjepartskomponenter og biblioteker der indgår, i hvilke versioner, og hvor i løsningen de bruges. Dertil kommer hostingplatformen og de tjenester, I køber hos andre. Overblikket er udviklingens og driftens ansvar, og det skal kunne slås op uden at samle tre personer til et møde.

Indgår komponenten, skal I også tage stilling til, om den sårbare del faktisk er i brug, og om den kan nås af kunder eller udefra. Det er en faglig vurdering, som udviklerne laver. Skriv den ned med dato og navn på den, der vurderede. Når kunden eller en anden kunde spørger igen en uge senere, er det notat grundlaget for svaret. → Sårbarheder i afhængigheder mellem to test · → Open source og tredjepartskomponenter

Svaret til kunden

Et brugbart svar er kort og dateret. Det siger, hvilken sårbarhed svaret gælder, hvilket produkt og hvilke versioner, og hvad status er lige nu. Tag et tænkt eksempel: Et softwarehus med et bookingsystem får spørgsmålet fra tre kunder samme formiddag. Udviklerne konstaterer, at komponenten indgår, men at den berørte funktion ikke er slået til. Svaret til kunderne siger netop det og oplyser, at komponenten opdateres i den kommende release med en angivet uge.

Ved I det ikke endnu, så sig det. Et svar om, at sagen er under afklaring, og at kunden hører fra jer på et bestemt tidspunkt, holder bedre end et hurtigt nej, der senere skal trækkes tilbage. Overhold så tidspunktet, også hvis beskeden blot er, at afklaringen tager længere tid.

Er produktet berørt, handler opgaven ikke længere kun om den kunde, der spurgte. Alle kunder på de berørte versioner har krav på samme oplysning, og formen bør være aftalt på forhånd. → Sikkerhedsmeddelelse til kunderne

Alvorlighed og prioritet i svaret

Nogle kunder spørger efter en score. CVSS er det fælles format, og specifikationen fra FIRST beskriver scoren som et udtryk for en sårbarheds alvorlighed i forhold til andre sårbarheder. Scoren i den offentlige post handler om komponenten generelt. Den siger ikke, hvordan sårbarheden påvirker jeres produkt med jeres opsætning. Vurderer I betydningen lavere, så begrund det med opsætningen og brugen, ikke med en talværdi, I selv har regnet frem.

Vær også varsom med at love en dato for opdateringen, før udviklerne har set på ændringen. En dato, der skrider, koster mere tillid end en dato, der ligger lidt senere fra begyndelsen.

Når kunden beder om en ny test

Nogle kunder beder om en test, der skal bekræfte, at sårbarheden ikke findes i produktet. Det kan give mening, hvis rettelsen har ændret noget væsentligt i løsningen. Ofte er det mere præcist at dokumentere opdateringen og en afgrænset kontrol af den berørte del end at bestille en bred test med kort varsel. Tag stilling til, hvad kunden skal bruge dokumentationen til, og hvad den næste planlagte test i forvejen skal dække. → Hvilke ændringer i produktet kræver en ny test?

Det skal I lade være med

Henvise til seneste pentest · Rapporten kan ikke svare på en sårbarhed, der blev kendt efter testen.
Svare nej uden opslag · Et forhastet svar skal måske trækkes tilbage over for flere kunder.
Kun svare den, der spurgte · Er I berørt, gælder det alle kunder på samme version.
Gætte på nummeret · Få CVE-nummeret eller den præcise betegnelse bekræftet, før I svarer.
Lade sælgeren svare alene · Vurderingen hører hjemme hos dem, der kender koden og driften.

Hvad kan og ikke kan konkluderes

Et svar om, at produktet ikke er berørt, gælder den vurderede sårbarhed, de nævnte versioner og tidspunktet for vurderingen. Det siger intet om andre sårbarheder. En tidligere pentest kan underbygge, at produktet er afprøvet, men ikke at det er fri for svagheder, der først blev kendt senere.

Tjekliste, når spørgsmålet lander

☐ Er CVE-nummeret eller den præcise sårbarhed bekræftet?
☐ Ved I, om komponenten indgår, og i hvilke versioner?
☐ Har en udvikler vurderet, om den berørte del er i brug?
☐ Er vurderingen skrevet ned med dato og navn?
☐ Siger svaret, hvilke versioner og hvilket tidspunkt det gælder?
☐ Har kunden fået et tidspunkt for næste besked, hvis sagen er uafklaret?
☐ Har I taget stilling til, om andre kunder skal informeres?

Kilder

CVE: fælles identifikation af offentligt kendte sårbarheder.
CISA Known Exploited Vulnerabilities Catalog: katalog over sårbarheder, der vides at være udnyttet.
FIRST CVSS v4.0: scoren udtrykker alvorlighed i forhold til andre sårbarheder.

Senest gennemgået: oktober 2026.