Åbenhed om tidligere fund over for nye kunder

En ny kunde kan spørge, om produktet har haft alvorlige sårbarheder, og hvordan de blev håndteret. Spørgsmålet kan føles som en fælde, men historikken er et af de få steder, hvor I kan vise, at jeres proces fungerer i praksis og ikke kun på papir. Svaret hviler på to ting: at I har ført en ordnet oversigt over fund og rettelser, og at I deler den i en form, der viser forløbet uden at udlevere detaljer, der stadig kan skade.

Hvad nye kunder spørger om

Spørgsmålene kommer i et sikkerhedsspørgeskema, på et møde med kundens sikkerhedsfolk eller efter, at kunden har søgt på jeres produkt. De lyder fx sådan:

Tidligere test · hvilke alvorlige fund havde de sidste rapporter, og er de rettet?
Kendte sårbarheder · har produktet fået offentlige sårbarhedsnumre, og hvad skete der?
Hændelser · har en svaghed været brugt mod jer eller jeres kunder?
Tid til rettelse · hvor lang tid gik der fra fund til rettelse?

Det sidste spørgsmål handler om noget andet end de tre første. Kunden prøver at forstå, hvad der vil ske næste gang. Svar derfor med de faktiske forløb og ikke med en gennemsnitlig tid, I ikke har regnet ud. Har I faste frister for rettelser efter alvorlighed, kan I nævne dem og sige, om de er overholdt i de seneste test. Har I ikke, så beskriv, hvordan fundene bliver prioriteret. → Skemaet spørger til åbne fund

Historikken viser processen

En leverandør uden registrerede fund ser ikke nødvendigvis sikrere ud for en erfaren sikkerhedsansvarlig. Det kan lige så vel betyde, at ingen har kigget. En historik med fund, der er fundet, vurderet, rettet og efterprøvet, fortæller derimod, at I tester, og at fundene fører til noget.

CISA, den amerikanske myndighed for cyber- og infrastruktursikkerhed, beder i sit frivillige Secure by Design-tilsagn producenter om at udstede CVE-numre for kritiske sårbarheder og skriver, at antallet kan stige på kort sigt, når producenter bliver mere åbne, uden at det skal ses som et negativt tegn. Tilsagnet er rettet mod producenter af erhvervssoftware med kunder i USA, men tanken kan bruges i jeres dialog med en dansk kunde: åbenhed om fund er et tegn på modenhed.

Hvad der kan deles, og i hvilken form

Del forløbet frem for rapporterne. En oversigt over de seneste test kan rumme dato, omfang, antal fund efter alvorlighed og status for rettelserne. Det giver kunden et billede uden at sende gamle rapporter, som måske beskriver svagheder i dele af produktet, der stadig findes.

Har kunden brug for mere, kan I tilbyde et møde eller en gennemgang under fortrolighed. Gamle rapporter bør kun udleveres efter samme regler som den nyeste. → Kundeversionen af rapporten

Offentligt kendte sårbarheder med et CVE-nummer kan I henvise direkte til, fordi oplysningerne allerede er offentlige. Har I sendt sikkerhedsmeddelelser til kunderne, er de et naturligt grundlag for oversigten. → Sikkerhedsmeddelelse til kunderne

Fund fra tidligere test og fra andre kilder

Historikken består ikke kun af pentest. Fund kan også komme fra jeres automatiske kontroller, fra kunders egne test, fra forskere, der har meldt en fejl, og fra leverandører af komponenter. Hvis kunden spørger bredt til sårbarheder, bør svaret dække de kilder, I faktisk registrerer, og sige hvilke det er.

En fælles registrering gør det muligt. Den behøver ikke være stor, men hvert fund skal have en dato, en kilde, en alvorlighed, en status og en dato for rettelse. Uden den bliver svaret en opgave i at huske, og så bliver det let mere positivt, end det burde. Sørg også for, at registreringen overlever, når medarbejdere skifter. En oversigt, der kun findes i én udviklers noter, er ikke en historik, kunden kan regne med. Den bør ligge sammen med rapporterne og opdateres efter hver test og hver retest, så tallene i næste svar passer til det, der faktisk er sket. → Fund i backloggen

ISO/IEC 29147 beskriver, hvordan leverandører kan modtage meldinger om sårbarheder og offentliggøre oplysninger om dem. En kunde, der kender standarden, kan spørge, om jeres håndtering følger den. Svar præcist på, hvad I gør, og lov ikke overensstemmelse, I ikke har fået vurderet. → Ansvarlig offentliggørelse

Når historikken rummer noget ubehageligt

Har produktet haft en hændelse, eller lå et alvorligt fund åbent længe, så sig det med den forklaring, der hører til: hvad skete der, hvad blev ændret bagefter, og hvordan ville det blive håndteret i dag. Kunden vil i forvejen kunne finde offentlige oplysninger, og det er bedre, at forklaringen kommer fra jer.

Skriv forklaringen én gang, lad den godkendes af ledelsen, og brug den samme formulering hver gang. Forskellige versioner til forskellige kunder kan blive opdaget, når kunderne taler sammen eller deler rådgiver. Det samme gælder salgsmateriale, der omtaler sikkerheden i produktet. → Svarbibliotek · → Testen i salgsmaterialet

Et tænkt eksempel

Et softwarehus med et system til vagtplanlægning bliver spurgt af en ny regional kunde om tidligere sårbarheder. Svaret er en side med de tre seneste test: dato, omfang, antal fund efter alvorlighed og status. Under oversigten står, at et højt fund i en ældre eksportfunktion for to år siden tog længere tid at rette, fordi funktionen blev bygget om, og at softwarehuset siden har indført faste frister for rettelser efter alvorlighed. Kunden får tilbudt et møde med den sikkerhedsansvarlige, hvis der er spørgsmål.

Det skal I lade være med

Svare, at produktet aldrig har haft sårbarheder · det kan sjældent dokumenteres og vækker mistro.
Sende gamle rapporter uden fortrolighed · de kan beskrive svagheder, der stadig findes.
Udelade kilder uden at sige det · skriv, hvilke kilder oversigten dækker.
Give forskellige forklaringer på den samme sag · brug én godkendt tekst.
Gøre historikken til et salgsbudskab · lad tallene og forløbet stå for sig selv.

Hvad kan og ikke kan konkluderes

En ordnet historik viser, at fund bliver registreret, vurderet og rettet. Den siger ikke, at fremtidige fund vil blive håndteret lige så hurtigt, og den kan kun dække de kilder, I faktisk har registreret. Et lavt antal fund kan skyldes et sikkert produkt, men også et smalt omfang i testene. Derfor bør oversigten altid vise omfanget ved siden af tallene, så kunden selv kan vurdere, hvad de dækker.

Tjekliste til historikken

☐ Er fund fra alle kilder registreret ét sted?
☐ Har hvert fund dato, kilde, alvorlighed og status?
☐ Findes der en oversigt, der kan deles uden detaljer?
☐ Er reglerne for udlevering af gamle rapporter de samme som for den nyeste?
☐ Er forklaringen på vanskelige sager godkendt og ens for alle kunder?
☐ Er det klart, hvilke kilder oversigten ikke dækker?

Kilder

CISA: Secure by Design Pledge: frivilligt tilsagn for producenter af erhvervssoftware; mål om CVE-numre for kritiske sårbarheder og bemærkning om, at et stigende antal ikke skal ses som et negativt tegn.
CVE: fælles identifikation af offentligt kendte sårbarheder.
ISO/IEC 29147: leverandørers modtagelse og offentliggørelse af oplysninger om sårbarheder.

Senest gennemgået: oktober 2026.