Test ved hver release eller én gang om året?

Et SaaS-produkt, der udgives hver uge, er et andet produkt efter et år, mens kundens krav kan lyde på én pentest om året. Valget mellem de to yderpunkter hviler på, hvad testen skal dokumentere: en årlig test giver kunderne et samlet billede på et tidspunkt, mens test i takt med releases giver jer sikkerhed for, at det nye ikke har åbnet noget.

For et produkt i løbende udvikling er svaret ofte hverken det ene eller det andet. En fast, bred test med et fast interval kombineret med afgrænsede test, når der sker noget væsentligt, giver både kunderne en rapport, de kan bruge, og jer en rytme, udviklingen kan leve med.

Hvorfor én test om året ikke slår til alene

En penetrationstest beskriver produktet, som det så ud i testperioden. Den britiske NCSC understreger, at en test kun kan sige noget om forholdene på testtidspunktet, og at der ofte går et år eller mere mellem to test. For et produkt, der ændrer sig hver uge, er det lang tid.

Kunderne ved det godt. Jo ældre rapporten bliver, jo flere spørger til, hvad der er kommet til siden. En årlig test uden noget imellem efterlader jer med et svar, der bliver svagere for hver release. → Meget er udgivet siden testen

Hvorfor en pentest ved hver release sjældent giver mening

En fuld penetrationstest kræver tid, forberedelse og en version, der står stille længe nok til at blive undersøgt. Lægges den ved hver release, bliver den enten så kort, at den ikke når i dybden, eller så tung, at den bremser udgivelserne.

Det er heller ikke, hvad pentesten er bedst til. NCSC beskriver pentesten som en kontrol af, at jeres løbende arbejde med sårbarheder virker, ikke som den primære måde at finde dem på. Det løbende arbejde hører hjemme i udviklingen: gennemgang af koden, automatiske test og kontrol af komponenter. Det er de aktiviteter, der kan følge med hver release. → Automatiske sikkerhedstest i pipelinen og den manuelle pentest

En rytme med to lag

En model, der passer til mange produkter i løbende udvikling, har to lag:

Den faste test · en bred penetrationstest med et fast interval, som dækker produktets kerne og de vigtigste funktioner. Det er den rapport, kunderne får.
De afgrænsede test · kortere test af det, der er nyt eller ændret, når ændringen er væsentlig nok til at påvirke det, den faste test byggede på.

Under begge lag ligger det løbende arbejde i udviklingen, som ikke er pentest, men som gør det muligt at holde intervallet mellem de faste test.

Et tænkt eksempel: et softwarehus udgiver et system til fakturering hver anden uge. Den faste test ligger hvert forår og dækker login, roller, adskillelsen mellem kunderne og API’et. I efteråret får produktet et nyt modul til automatisk betaling af fakturaer med kobling til kundernes bank. Modulet håndterer penge og har nye roller til godkendelse, så det får en afgrænset test, før det slås til for alle. De andre releases i løbet af året ændrer brugerfladen og rapporterne og bliver vurderet, men ikke testet særskilt.

Tankegangen findes også i standarder. I PCI DSS, der gælder, hvor betalingskortdata håndteres, er kravet om penetrationstest knyttet både til et interval på højst tolv måneder og til væsentlige ændringer. Standarden gælder ikke for alle produkter, men den viser, hvordan kalender og ændringer kan bruges sammen. Hvad der tæller som en væsentlig ændring i jeres produkt, er en vurdering for sig. → Ændringer, der kræver en ny test

Hvordan kunderne ser på rytmen

Kunden kan spørge, hvor ofte I tester, og hvornår seneste rapport er fra. En rytme med to lag giver et præcist svar: den faste test lå på en bestemt dato, og siden er bestemte større ændringer testet afgrænset. Det er stærkere end blot at sige årligt, fordi kunden kan se, at I også reagerer på det, der sker i produktet mellem to faste test.

Pas på med at kalde de afgrænsede test for en samlet test. Rapporten fra en test af en ny betalingsfunktion siger noget om betalingsfunktionen, ikke om resten af produktet. Når kunden beder om den nyeste rapport, skal I kunne vise både den seneste faste rapport og de afgrænsede, og forklare, hvordan de hænger sammen. → Hvor ofte tester I?

Releases og testens version

Med hyppige udrulninger er det også et spørgsmål, hvilken version der skal testes. Den faste test kan med fordel lægges på en version, der er stabil i testperioden, eller i et miljø, der ligner produktionen, så rapporten kan knyttes til en bestemt udgave. → Hyppige udrulninger: hvilken version skal testes?

De afgrænsede test passer bedst før en ændring når ud til alle kunder. En ny funktion kan testes, mens den kun er slået til for få, så fund kan rettes før den brede udrulning. → Penetrationstest af en ny funktion før lancering

Retest af rettelser kan ofte gå med i den næste release, men husk at dokumentere, hvilken version rettelsen kom med i, så kunden kan se det. → Retest efter rettelser i en ny release

Hvor stor den faste test skal være, og hvor mange afgrænsede test der er brug for, afhænger af produktets størrelse og af, hvor meget og hvor ofte det ændrer sig. Det er de forhold, der styrer → pris og tilbud.

Det skal I lade være med

Love kunderne en pentest ved hver release · det kan sjældent holdes, og det er ikke det, testen er bedst til.
Lade den årlige test stå alene · væsentlige ændringer i løbet af året kan kræve en afgrænset test.
Kalde automatiske test i pipelinen for pentest · kunden forventer en manuel test, når ordet bruges.
Fremstille en afgrænset test som en samlet test · den dækker det, der var med.
Lade releaseplanen bestemme testen uden en vurdering · det er indholdet af ændringen, der afgør det.

Hvad kan og ikke kan konkluderes

En fast, bred test viser, hvad der blev fundet i produktet på testtidspunktet. Afgrænsede test viser, hvad der blev fundet i det nye. Sammen kan de give et rimeligt billede af produktet, så længe resten faktisk er uændret og det løbende arbejde i udviklingen fungerer. Ingen af dem dækker de releases, der ikke er vurderet.

Tjekliste til rytmen

☐ Har produktet en fast, bred test med et kendt interval?
☐ Er det beskrevet, hvilke ændringer der udløser en afgrænset test?
☐ Er det løbende sikkerhedsarbejde i udviklingen beskrevet for sig?
☐ Kan I vise kunden både den seneste faste rapport og de afgrænsede?
☐ Er det tydeligt, hvilken version hver test dækker?

Kilder

NCSC (UK): Penetration testing: en test siger noget om forholdene på testtidspunktet, der går ofte et år eller mere mellem to test, og pentest bør bruges som kontrol af det løbende arbejde med sårbarheder.
PCI DSS krav 11, krav 11.4: penetrationstest mindst hver tolvte måned og efter væsentlige ændringer i miljøer med betalingskortdata.

Senest gennemgået: oktober 2026.