Rettefrister, kunden vil skrive ind i kontrakten

Når en kunde vil have faste frister for rettelse af sårbarheder ind i kontrakten, bliver en intern prioritering til et løfte, som kunden kan måle jer på. I kan forpligte jer til frister, I kan holde for alle kunder på én gang, og som tager udgangspunkt i en risikovurdering, I selv står for. Det kræver, at fristerne er knyttet til en defineret alvorlighed, at det er klart, hvornår uret starter og stopper, og at der er en vej for de fund, der ikke kan rettes til tiden. Teksten er ikke juridisk rådgivning.

Hvordan en virksomhed sætter sine egne frister for rettelser, er beskrevet for køberen på penetrationtest.dk. Her handler det om fristerne som en forpligtelse over for kunden.

Hvorfor faste frister er svære for et softwarehus

En rettelse i et softwareprodukt er ikke en indstilling, der kan ændres samme dag. Den skal udvikles, testes og udrulles, og hvis produktet installeres hos kunderne, skal kunderne selv opdatere. Nogle fund kræver en ændring i arkitekturen, andre ligger i en komponent fra en anden leverandør.

Samtidig gælder en rettelse alle kunder. Hvis én kunde har en kortere frist end de andre, er det i praksis den frist, der styrer hele udviklingsplanen. Ti kunder med ti forskellige frister giver ti forskellige ure for det samme fund. → Fund i backloggen: sådan prioriterer udviklingsteamet

Hvad kilderne siger om fristen

To af de kilder, kunder henviser til, overlader fristen til virksomhedens egen risikovurdering. PCI DSS krav 11.4.4 siger, at udnyttelige sårbarheder fundet ved penetrationstest rettes i overensstemmelse med virksomhedens egen vurdering af risikoen, og at testen gentages for at efterprøve rettelserne. NCSC (UK) skriver i sin vejledning om penetrationstest, at risikovurdering og beslutninger om rettelser er virksomhedens ansvar.

Det er et argument, I kan bruge over for kunden: en fast frist for alle fund uanset alvorlighed går længere, end selv en streng standard som PCI DSS kræver i dette punkt. Det betyder ikke, at kunden ikke må kræve mere. Det betyder, at kravet bør knyttes til en vurdering.

Kunden kan selv være underlagt regler, der stiller krav til leverandørerne, fx som finansiel virksomhed eller som virksomhed omfattet af NIS2. Spørg, om kundens krav om frister kommer fra sådanne regler eller fra en intern politik. Hvis det er en politik, kan der være mere plads til at finde en formulering, der passer til jeres udviklingsrytme.

Det, I kan forpligte jer til

Tilbyd frister, der svarer til den proces, I allerede har, og som kan måles.

Kvittering · at fund, der meldes til jer, bekræftes inden for en aftalt tid.
Vurdering · at hvert fund vurderes og får en alvorlighed inden for en aftalt tid.
Plan · at fund med høj alvorlighed får en plan med ejer og forventet release.
Mål for rettelse · en målsat frist pr. alvorlighed, ikke én frist for alle fund.
Status · at kunden får besked, hvis en frist ikke kan holdes, og hvad der gøres i mellemtiden.

En frist for vurdering og plan er lettere at holde end en frist for den endelige rettelse, og den giver kunden det, kunden har mest brug for: at ingen alvorlige fund bliver liggende uden stillingtagen.

Knyt også efterprøvningen til fristerne. En kunde, der får en frist, vil før eller siden spørge, hvordan I viser, at den er holdt. Planlæg derfor, at rettelser af fund med høj alvorlighed efterprøves, og at resultatet kan vises til kunden. → Retestbevis: vis kunden, at fundene er rettet

Definer, hvad fristen måles på

En frist uden definitioner bliver en kilde til uenighed. Skriv ned, hvilken skala alvorligheden fastsættes efter, fx CVSS, som FIRST står bag, og hvem der fastsætter den: testeren, jer eller begge. Skriv også, hvornår uret starter. Det kan være, når rapporten er modtaget, når fundet er bekræftet, eller når kunden melder det.

Aftal, hvornår fundet tæller som rettet. Er det, når rettelsen er udviklet, når den er udrullet til alle kunder, eller når den er efterprøvet? For installationer hos kunden kan det kun være, når opdateringen er stillet til rådighed. → Sikkerhedsfund i udviklingsprocessen: hvornår er en rettelse færdig?

Når fristen ikke kan holdes

Der vil komme fund, som ikke kan rettes til tiden. Kontrakten bør beskrive, hvad der så sker, i stedet for at lade det blive et spørgsmål om misligholdelse.

En midlertidig foranstaltning, der begrænser risikoen, en ny dato med begrundelse og en status til kunden er en rimelig fremgangsmåde. For fund i komponenter fra andre leverandører kan fristen knyttes til, hvornår en rettelse er tilgængelig. Aftal også, hvem der hos kunden skal have besked, og i hvilken form, så statusmeldingen ikke ender hos en indkøber, der ikke kan bruge den. Jo tydeligere fremgangsmåden er, jo færre uenigheder skal I tage, den dag en rettelse bliver forsinket. → Kompenserende foranstaltninger: når et krav ikke er opfyldt

Et tænkt eksempel

Et softwarehus leverer en kundeportal til forsikringsmæglere. En ny kunde vil have en kontraktbestemmelse om, at alle fund fra penetrationstest rettes inden for en fast, kort frist.

Softwarehuset foreslår i stedet en vurdering af hvert fund inden for en aftalt tid, en plan for fund med høj alvorlighed, målsatte frister pr. alvorlighed efter CVSS og en skriftlig status, hvis en frist skrider. Kunden accepterer på betingelse af, at efterprøvningen af fund med høj alvorlighed fremgår af næste rapport. Softwarehuset lægger samme frister ind i sine standardvilkår, så de gælder alle kunder.

Det skal I lade være med

Acceptere én frist for alle fund · alvorligheden skal styre tempoet.
Love frister, udviklingsplanen ikke kan bære · fristen gælder også i en travl periode.
Give én kunde kortere frister end resten · det bliver den frist, der styrer alle.
Lade uret og ordet rettet være udefineret · så må I diskutere det, hver gang et fund kommer.
Glemme komponenter fra andre · nogle rettelser venter på en anden leverandør.

Hvad kan og ikke kan konkluderes

Frister, I overholder, viser kunden, at sikkerhedsfund bliver behandlet i et forudsigeligt tempo. De siger ikke, at produktet har færre svagheder, og de giver ikke kunden sikkerhed for fund, som ingen har fundet endnu. Hvilke følger det får, hvis en frist overskrides, afhænger af kontraktens øvrige bestemmelser.

Tjekliste til fristerne

☐ Er fristerne knyttet til en defineret skala for alvorlighed?
☐ Er det aftalt, hvem der fastsætter alvorligheden?
☐ Er det klart, hvornår uret starter, og hvornår et fund er rettet?
☐ Kan udviklingsplanen bære fristerne for alle kunder?
☐ Er der en fremgangsmåde for fund, der ikke kan rettes til tiden?
☐ Er fristerne de samme som i jeres standardvilkår?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.4 om rettelse efter virksomhedens egen risikovurdering og gentaget test for at efterprøve rettelserne.
NCSC (UK): Penetration testing: risikovurdering og beslutninger om rettelser er virksomhedens ansvar.
FIRST CVSS v4.0: fælles skala for alvorlighed.

Senest gennemgået: oktober 2026.