Kundens tester finder et fund: sådan modtager I det

En mail fra kundens sikkerhedsansvarlige med et vedhæftet fund fra kundens egen test er en af de situationer, hvor et softwarehus hurtigt kan komme til at svare forkert. Svaret hviler på tre ting: en fast vej ind for fundet, jeres egen vurdering af det, og en skriftlig tilbagemelding, som kunden kan bruge i sin leverandørvurdering. Tag imod fundet som en oplysning om produktet, ikke som en klage, og giv kunden besked om, hvad der sker, før I har alle svar.

Kundens fund er ikke det samme som et fund i jeres egen rapport. Testeren arbejder for kunden, I har ikke valgt omfanget, og I kender ikke nødvendigvis forudsætningerne. Det ændrer ikke på, at svagheden kan være reel og gælde alle kunder.

Hvor fundet kommer ind

Fundet bør lande ét kendt sted hos jer, uanset om det kommer via supporten, den kundeansvarlige eller direkte til en udvikler. Hvis I har en kontaktvej for sårbarheder, er det den, kunden skal henvises til. NCSC (UK) anbefaler i sin vejledning om håndtering af indrapporterede sårbarheder en enkel kontaktvej, der er let at finde, og en politik, der fortæller, hvad den, der indrapporterer, kan forvente. → Ansvarlig offentliggørelse: en kontaktvej for sårbarheder

En kunde har dog kontakt med andre personer i softwarehuset, end en forsker udefra har. Sørg derfor for, at supporten og de kundeansvarlige ved, at et sikkerhedsfund skal sendes videre med det samme og ikke behandles som en almindelig sag i køen.

Den første kvittering

Svar hurtigt og kort. Bekræft, at fundet er modtaget, hvem der har det, og hvornår kunden kan forvente næste besked. NCSC’s vejledning lægger vægt på at svare hurtigt og takke den, der har indrapporteret, og den siger også, at man ikke behøver at love en tidsplan eller dele tekniske detaljer i første omgang.

Kvitteringen er ikke stedet for en vurdering. En hurtig bemærkning om, at fundet nok ikke er alvorligt, kan blive citeret senere, hvis det viser sig at være det.

Det, I skal have fra kunden

Et fund fra en anden tester kan være beskrevet kortere eller anderledes, end I er vant til. Bed om de oplysninger, der skal til for at vurdere det, og bed kunden sende dem ad en sikker vej.

Tidspunkt og miljø · hvornår testen fandt sted, og om det var produktionen, et testmiljø eller kundens egen installation.
Version · hvilken version eller release af produktet, kunden brugte.
Rolle · med hvilken brugerrolle og hvilke rettigheder fundet blev gjort.
Testerens vurdering · alvorlighed og begrundelse, gerne med den skala, testeren har brugt.
Berørte data · om testeren har set oplysninger, der tilhører andre end kunden selv.

Det sidste punkt er det vigtigste. Hvis kundens tester har kunnet se en anden kundes data, er det ikke længere kun et spørgsmål mellem jer og den ene kunde. → Kundens test i et delt miljø: hensynet til de andre kunder

Jeres egen vurdering

Lad den sikkerhedsansvarlige eller produktejeren eje vurderingen, ikke sælgeren og ikke den udvikler, der skrev koden. Gentag fundet i jeres eget testmiljø, hvis det kan lade sig gøre, og vurder det med samme målestok som fund fra jeres egne test. Spørg også, om fundet gælder alle kunder, kun kunder med en bestemt opsætning eller kun den ene kunde.

Kan I ikke genskabe fundet, er det ikke det samme som, at det ikke findes. Skriv til kunden, hvad I har forsøgt, og hvilke oplysninger der mangler. Forskellen kan skyldes en rolle, en indstilling eller en version, som kun kundens tester kender, og et kort møde med testeren kan afklare mere end flere runder mails.

Kundens tester kan have ret i fundet og tage fejl af alvorligheden, eller omvendt. Hold de to ting adskilt. Hvis I er uenige i alvorligheden, så skriv hvorfor, med de konkrete forhold i produktet, og lad kundens vurdering stå som kundens. → Kunden læser et fund anderledes end jer

Når fundet er bekræftet, skal det ind i samme forløb som alle andre sikkerhedsfund, med ejer, prioritet og en planlagt release. → Fund i backloggen: sådan prioriterer udviklingsteamet

Svaret til kunden

Kunden har brug for et svar, der kan lægges i sagen. Det bør sige, om I har bekræftet fundet, hvordan I vurderer det, hvad I gør, og hvornår kunden hører fra jer igen. NCSC anbefaler også at give besked løbende, hvis rettelsen tager tid, og at fortælle den, der indrapporterede, når fundet er rettet.

Tilbyd kunden at få rettelsen efterprøvet, enten af kundens egen tester eller i jeres næste test. Hvis fundet er bekræftet og gælder alle kunder, er spørgsmålet bagefter, om de andre kunder skal have besked. Det er en beslutning, der træffes for sig. → Testen finder noget alvorligt: skal kunderne have besked?

Et tænkt eksempel

Et softwarehus leverer lagerstyring til grossister. En kunde har bestilt en test af sin egen brug af systemet, og testeren finder, at en bruger med læseadgang kan ændre en ordrestatus. Kunden sender fundet til sin kundeansvarlige, som videresender det til den sikkerhedsansvarlige samme dag.

Softwarehuset kvitterer, beder om version og brugerrolle og gentager fundet i testmiljøet. Det gælder alle kunder. Rettelsen planlægges til næste release, kunden får en skriftlig status, og fundet føjes til listen over det, den næste eksterne test skal efterprøve.

Det skal I lade være med

Afvise fundet, fordi I ikke bestilte testen · svagheden er i jeres produkt, uanset hvem der fandt den.
Lade fundet ligge i supportkøen · sikkerhedsfund skal videre med det samme.
Vurdere fundet i kvitteringen · første svar bekræfter modtagelsen, intet andet.
Bede om tekniske detaljer over almindelig mail · aftal en sikker vej.
Glemme spørgsmålet om andre kunders data · det kan ændre hele sagen.
Love en dato for rettelsen, før fundet er vurderet · løftet skal kunne holdes.

Hvad kan og ikke kan konkluderes

Et fund fra kundens tester viser, at der var en svaghed i den version og det miljø, testeren så på. Det siger ikke noget om resten af produktet, og det gør ikke kundens test til en test af hele løsningen. En god modtagelse viser kunden, at I har en proces, der virker, også når fundet kommer udefra.

Tjekliste, når kunden sender et fund

☐ Er fundet sendt til den, der ejer sikkerhedsfund?
☐ Har kunden fået en kvittering med navn og næste skridt?
☐ Kender I version, miljø og brugerrolle?
☐ Er det afklaret, om andre kunders data var berørt?
☐ Er fundet gentaget og vurderet hos jer?
☐ Er fundet lagt i backloggen med ejer og release?
☐ Har kunden fået en skriftlig status og et tilbud om efterprøvning?

Kilder

NCSC (UK): Vulnerability Disclosure Toolkit: en kontaktvej, der er let at finde, en politik om forventninger, hurtigt svar og tak, ingen krav om tidsplan i første svar, løbende status og besked, når fundet er rettet.

Senest gennemgået: oktober 2026.