Kodefrys under testen: er det nødvendigt?

Et fuldt kodefrys, hvor intet må udrulles, mens pentesten står på, er sjældent nødvendigt for et softwarehus, og for et produkt med daglige udrulninger kan det være dyrt. Det, der er nødvendigt, er, at testeren arbejder på en version, der er kendt, og at rapporten kan sige præcist, hvad der blev testet. Det kan opnås på flere måder, og valget afhænger af, hvordan I udruller, og hvad kunderne skal bruge rapporten til.

Kodefryset er altså et middel, ikke et mål. Målet er en rapport, der kan kobles til en bestemt udgave af produktet.

Hvorfor spørgsmålet opstår

En pentest strækker sig over dage eller uger. I den periode kan et produkt i løbende udvikling ændre sig mange gange. Hvis testeren finder en svaghed mandag, og den er væk onsdag, fordi en udrulning har ændret funktionen, er det uklart, om fundet stadig gælder. Omvendt kan en ny funktion dukke op midt i testen og se ud, som om den var med, selvom testeren aldrig nåede at se på den.

Ifølge den britiske NCSC kan en pentest kun validere forholdene på selve testdagen. Hvis produktet ændrer sig hver dag i testperioden, bliver det svært at sige, hvilken dag rapporten egentlig beskriver. Det er grunden til, at mange testere spørger efter et kodefrys. → Version og testdatoer

Fire måder at give testeren en stabil version

Der er flere måder at løse det på end et fuldt kodefrys:

Fuldt kodefrys · intet udrulles i testperioden. Enkelt og entydigt, men det stopper også fejlrettelser og funktioner, kunderne venter på.
Delvist kodefrys · de dele af produktet, der er med i testen, fryses, mens andre dele kan udrulles. Det kræver, at I kan skelne mellem delene i jeres udrulning.
Et separat testmiljø med en fast version · testeren arbejder i et miljø, der ligner produktionen, mens produktionen udvikler sig videre. Rapporten beskriver testmiljøets version. → Et staging-miljø til testen
Fri udrulning med logbog · der udrulles som normalt, men hver udrulning i testperioden noteres og meddeles testeren, så rapporten kan sige, hvad der ændrede sig undervejs.

Valget kan også kombineres. Et separat testmiljø kan suppleres med et kort, delvist frys i produktionen de dage, hvor testeren kigger på adskillelsen mellem kunderne i den rigtige drift, eller et fuldt frys kan begrænses til de første dage, hvor testeren kortlægger produktet, mens resten af testen kører med logbog. Det vigtige er, at kombinationen er aftalt og beskrevet, ikke at den er enkel.

Den tredje mulighed er ofte den mest praktiske for et produkt med hyppige udrulninger, så længe miljøet ligner produktionen i det, der betyder noget for testen. Den fjerde kan fungere for små ændringer, men bliver uoverskuelig, hvis der udrulles meget i de dele, der testes.

Hvad hvert valg betyder for rapporten

Kunderne læser rapporten som en beskrivelse af produktet. Hvert valg giver rapporten en lidt forskellig betydning:

Fuldt kodefrys · rapporten beskriver én version i produktionen.
Delvist kodefrys · rapporten beskriver de frosne dele i én version, og resten som det så ud på testdagene.
Separat testmiljø · rapporten beskriver en version i et miljø, der skal ligne produktionen. Kunden kan spørge, hvor godt det ligner.
Fri udrulning · rapporten beskriver et produkt i bevægelse og bør sige, hvilke ændringer der kom undervejs.

Ingen af dem er forkerte, men de skal stå i rapporten, så kunden ikke skal gætte. → Hyppige udrulninger: hvilken version?

Sikkerhedsrettelser under et kodefrys

Et fuldt kodefrys skal have en undtagelse. Finder testeren et alvorligt fund, der kan ramme kunderne i produktionen, skal I kunne rette det med det samme. Ellers bliver testen en grund til at lade kunderne være udsat længere, end nødvendigt. Aftal på forhånd, at sådanne rettelser må udrulles, og at rapporten beskriver både fundet og rettelsen. → Udviklerne og testeren

Det samme gælder rettelser af svagheder, som I selv eller andre opdager i testperioden. Et kodefrys til gavn for rapporten må ikke stå i vejen for en kritisk opdatering. Den britiske NCSC skriver i sin vejledning om sikker udvikling, at sikkerhedstest ikke bør stå i vejen for løbende levering, og det gælder også omvendt for akutte rettelser.

Hvem bestemmer?

Valget er en afvejning mellem releaseplanen og ønsket om en entydig rapport. Det er typisk produktejeren, der træffer det, efter at have hørt testeren og udviklerne. Testeren kan sige, hvor meget ændringer undervejs vil påvirke testen. Udviklerne kan sige, hvad et frys vil koste i forsinkede rettelser og funktioner. → Produktejerens rolle i penetrationstesten

Beslutningen bør skrives ind i aftalen med testeren, før testen begynder. Det gør det tydeligt for begge parter, hvad der må ske i testperioden, og det giver rapporten et fast grundlag. Fortæl også kundeansvarlige og support om valget. Hvis der er et frys, kan kunder, der venter på en rettelse eller en ny funktion, opleve en forsinkelse, og så er det bedre, at de kundeansvarlige kan forklare hvorfor, end at kunden selv undrer sig over, at der pludselig ikke kommer noget nyt.

Et tænkt eksempel

Et softwarehus med et system til styring af træningshold udruller flere gange om dagen. Et fuldt kodefrys i hele testperioden ville stoppe arbejdet for hele udviklingsteamet. I stedet sættes et testmiljø op med en fast version, der svarer til produktionen den dag, testen begynder. Produktionen udvikler sig videre. Der aftales en undtagelse: finder testeren et alvorligt fund, rettes det både i testmiljøet og i produktionen, og rapporten beskriver begge dele. Rapportens forside angiver versionen i testmiljøet og datoen, den svarede til produktionen. Kunderne kan dermed se, hvilken udgave rapporten handler om, og hvor langt produktionen er nået siden.

Det skal I lade være med

Fryse alt uden at overveje alternativerne · det kan koste mere end nødvendigt.
Udrulle frit uden at fortælle testeren det · så bliver fundene uklare.
Stoppe kritiske rettelser for at holde frysen · kundernes sikkerhed går forud.
Teste i et miljø, der ikke ligner produktionen · så beskriver rapporten noget andet.
Lade valget stå uskrevet · rapporten skal kunne forklare, hvad der skete i testperioden.

Hvad kan og ikke kan konkluderes

Et kodefrys eller en fast testversion gør rapporten entydig om, hvad der blev testet. Det siger ikke noget om de ændringer, der kom efter testen. Med fri udrulning kan rapporten stadig være brugbar, men den beskriver et produkt i bevægelse, og det skal fremgå.

Tjekliste før testen

☐ Er det besluttet, om der fryses helt, delvist, eller testes i et separat miljø?
☐ Er der aftalt en undtagelse for alvorlige fund og kritiske rettelser?
☐ Ved testeren, hvad der må udrulles i testperioden?
☐ Bliver udrulninger i testperioden noteret?
☐ Står valget i aftalen med testeren?

Kilder

NCSC (UK): Penetration testing: en test kan kun vise, at systemerne ikke var sårbare over for kendte problemer på dagen for testen.
NCSC (UK): Secure development and deployment guidance, princip 7: sikkerhedstest bør ikke stå i vejen for løbende levering.

Senest gennemgået: oktober 2026.