Sikkerhedsmeddelelse til kunderne om en sårbarhed i produktet

En sikkerhedsmeddelelse skal give kunderne det, de har brug for til at vurdere deres egen risiko, uden at blive en vejledning til at udnytte svagheden. Om den lykkes, afhænger af tre ting: at indholdet er præcist om, hvem der er berørt, at tonen hverken skræmmer eller bagatelliserer, og at formatet er fast, så meddelelsen kan skrives hurtigt, når det haster. Beslutningen om, hvorvidt kunderne skal have besked, træffes før meddelelsen skrives. → Skal kunderne have besked?

Hvem meddelelsen er til

Meddelelsen kan have to læsere hos hver kunde. Den ene er den, der ejer aftalen og skal vide, om forretningen er påvirket. Den anden er kundens IT- eller sikkerhedsansvarlige, der skal vurdere, om der skal gøres noget, og som måske skal dokumentere det over for sin egen ledelse eller revisor.

Skriv derfor i to lag. Øverst et kort resumé i almindeligt sprog. Derunder de oplysninger, en fagperson skal bruge. Begge lag skal kunne læses uden kendskab til jeres interne betegnelser for moduler og versioner.

Tænk også over kredsen af modtagere. Er kun kunder med et bestemt modul berørt, kan meddelelsen gå til dem alene, mens de øvrige ikke skal bruge tid på den. Er alle kunder berørt, eller kan I ikke afgrænse kredsen sikkert, sendes den bredt. Hold en opdateret liste over sikkerhedskontakter hos hver kunde, så meddelelsen ikke ender hos en medarbejder, der har forladt virksomheden, eller i en fælles indbakke, ingen læser.

Det, der skal stå i den

Et fast sæt felter gør meddelelsen lettere at skrive og at læse:

Overskrift og dato · en kort beskrivelse og den dato, meddelelsen er udsendt.
Berørte versioner og moduler · hvad der er ramt, og hvad der ikke er.
Alvorlighed · jeres vurdering og eventuelt en score efter et kendt system, fx CVSS fra FIRST.
Konsekvens · hvad en angriber kunne opnå, beskrevet i forretningssprog.
Status · rettet, under rettelse eller afbødet midlertidigt.
Kundens handling · hvad kunden selv skal gøre, eller at der ikke kræves noget.
Spor af brug · hvad I ved om, hvorvidt svagheden er blevet brugt.
Kontakt · hvor kunden kan stille spørgsmål.

Har sårbarheden fået et CVE-nummer, så nævn det. CVE-programmet giver offentligt kendte sårbarheder en fælles identifikation, og nummeret gør det lettere for kunden at koble meddelelsen til sine egne systemer. → Kunden spørger efter en kendt sårbarhed

Det, der ikke skal stå i den

Fremgangsmåden for at finde eller udnytte svagheden hører ikke hjemme i en meddelelse, der sendes bredt. Det samme gælder navne på andre kunder, interne systemnavne og detaljer fra pentestrapporten, som kun er udleveret under fortrolighed.

Undgå også at gætte. Ved I endnu ikke, om svagheden er brugt, så skriv det, og sig hvornår I forventer at vide mere. En meddelelse, der senere skal trækkes tilbage, skader mere end en, der var forsigtig. → Svar, I ikke kan dokumentere

Tone: sagligt og uden at bagatellisere

Skriv i et roligt og konkret sprog. Ord som kritisk og akut skal svare til jeres egen vurdering og ikke bruges for at virke handlekraftige. Omvendt bør I ikke skrive, at der ingen risiko har været, hvis I ikke kan dokumentere det.

Et tænkt eksempel: Et softwarehus med et system til lønindberetning har rettet en fejl, hvor eksportfiler kunne hentes uden login, hvis man kendte adressen. Meddelelsen siger, at fejlen er rettet i den aktuelle version, at logningen ikke viser hentninger ud over testerens, at kunderne ikke skal gøre noget, og at spørgsmål kan sendes til den faste sikkerhedsadresse. Den siger ikke, hvordan adresserne var opbygget.

Tak gerne testeren eller den, der meldte fejlen, hvis det er aftalt. Det viser, at I tager imod fund, uden at det bliver et salgsbudskab. → Ansvarlig offentliggørelse

Fast format og maskinlæsbar form

En skabelon, der er godkendt på forhånd, sparer tid den dag, meddelelsen skal ud. Læg den samme sted som jeres proces for sårbarheder, og aftal, hvem der må godkende og sende. Skabelonen bør have faste overskrifter for hvert felt ovenfor og en kort standardtekst til de felter, der sjældent ændrer sig, fx kontaktvejen. Prøv den af på et gammelt, allerede rettet fund, så I ved, at den fungerer, og hvor lang tid det tager at udfylde den. → Et fast kontaktpunkt

Nogle kunder vil hellere have oplysningerne i en form, deres egne værktøjer kan læse. OASIS har standardiseret Common Security Advisory Framework (CSAF) 2.0 som et sprog til at udveksle sikkerhedsmeddelelser i JSON. Cyber Resilience Act, forordning (EU) 2024/2847, nævner i artikel 14, stk. 8, at fabrikanter skal underrette berørte brugere om aktivt udnyttede sårbarheder og alvorlige hændelser, hvor det er relevant i et struktureret maskinlæsbart format. Om forordningen gælder jeres produkt, er et spørgsmål for sig. → Cyber Resilience Act

Opfølgning og afslutning

En meddelelse om en sårbarhed, der endnu ikke er rettet, er kun første del. Aftal, hvornår kunderne får den næste, og hold det. Når rettelsen er udrullet, sendes en afsluttende meddelelse til den samme kreds, så ingen står tilbage med den foreløbige.

Giv meddelelserne et løbenummer og versioner, så en opdatering kan kendes fra den første. Gem dem samlet, så de kan bruges, når en ny kunde spørger til historikken. → Åbenhed om tidligere fund

Overvej også, om retesten skal nævnes. Har testeren efterprøvet rettelsen, er det en oplysning, kundens sikkerhedsfolk kan bruge. → Retestbevis til kunden

Det skal I lade være med

Skrive fremgangsmåden · beskriv konsekvens og handling.
Sende fra en sælgers postkasse · brug en fast afsender, kunderne kender.
Love, at ingen data er berørt, uden grundlag · skriv, hvad I ved.
Bruge interne modulnavne · kunden skal kunne genkende sit eget produkt.
Glemme den afsluttende meddelelse · den foreløbige må ikke blive stående.
Sende forskellige versioner til forskellige kunder uden registrering · så kan ingen følge med i, hvad der er sagt.

Hvad kan og ikke kan konkluderes

En god meddelelse viser, at I har styr på, hvad der er sket, og hvad kunden skal gøre. Den giver kundens sikkerhedsfolk et dateret grundlag, de kan henvise til i deres egen dokumentation. Den siger ikke, at produktet ikke har andre svagheder, og den erstatter ikke de underretninger, en kontrakt eller en lov eventuelt kræver over for andre end kunderne.

Tjekliste før meddelelsen sendes

☐ Er berørte versioner og moduler angivet præcist?
☐ Er alvorlighed og konsekvens beskrevet i forretningssprog?
☐ Står det klart, hvad kunden skal gøre?
☐ Er fremgangsmåden holdt ude af teksten?
☐ Er status for spor af brug beskrevet ærligt?
☐ Er næste meddelelse aftalt, hvis rettelsen ikke er klar?
☐ Er meddelelsen nummereret og gemt?

Kilder

OASIS: Common Security Advisory Framework Version 2.0: OASIS-standard fra 18. november 2022 for udveksling af sikkerhedsmeddelelser i JSON.
Cyber Resilience Act, forordning (EU) 2024/2847: artikel 14, stk. 8, om underretning af brugere, hvor det er relevant i et struktureret maskinlæsbart format.
FIRST: CVSS v4.0: system til at angive en sårbarheds alvorlighed.
CVE: fælles identifikation af offentligt kendte sårbarheder.

Senest gennemgået: oktober 2026.