Penetrationtest

Testen ligger lige før lanceringen uden tid til at rette

Penetrationtest: opslagsværk om penetrationstest på dansk

Når penetrationstesten lægges som sidste punkt før en lancering, kommer rapporten samtidig med, at systemet åbner. Fundene er kendte, men der er ingen tid til at rette dem, og testen ender som dokumentation for de problemer, der går i drift. Løsningen hviler på to ting: at planen regnes baglæns fra lanceringsdatoen, og at der er truffet beslutning om, hvad der sker med fund, der ikke kan nås.

Den tænkte kundeportal skal åbne en mandag. Testen er lagt i ugen før, fordi udviklingen først blev færdig dér. Rapporten kommer fredag med et alvorligt fund i adskillelsen mellem kunder. Nu er der tre muligheder, og ingen af dem er gode: åbne alligevel, udskyde eller lave en hurtig rettelse, som ingen har nået at efterprøve.

Hvorfor testen ender i sidste øjeblik

Det er forståeligt, at testen placeres sent. Testeren skal have et system, der ligner det, der går i drift, og det findes først, når udviklingen er næsten færdig. Samtidig kan lanceringsdatoen være meldt ud til kunder eller samarbejdspartnere og svær at flytte.

Problemet opstår, når forsinkelser i udviklingen spiser af den tid, der var sat af. Testen bliver skubbet, men datoen for lanceringen bliver stående. Til sidst er der kun plads til selve testen og ingen plads til det, der kommer efter. Hvornår testen bør ligge i et projekt med en ny kundeportal, er beskrevet i → Ny kundeportal: hvornår skal testen ligge?. Den tilsvarende vejledning for webshops findes i → Penetrationstest før lancering af en ny webshop.

Regn baglæns fra lanceringen

Start med datoen for åbningen, og placer hvert trin bagud derfra. Rækkefølgen ligger nogenlunde fast, mens længden af hvert trin afhænger af systemet og skal aftales.

  1. Lancering · den dato, der ikke flyttes.
  2. Beslutning om åbning · en ansvarlig tager stilling til de fund, der stadig er åbne.
  3. Efterprøvning · de vigtigste rettelser bliver kontrolleret. → Retest efter penetrationstest
  4. Rettelser · udviklere og leverandører retter fundene i prioriteret rækkefølge.
  5. Rapport og gennemgang · fundene bliver forklaret og fordelt.
  6. Test · den aftalte testperiode.
  7. Forberedelse · testkonti, tilladelser og et miljø, der ligner det endelige.

Hvis trinnene ikke kan nå at ligge før lanceringsdatoen, er det en oplysning, projektet skal have nu og ikke ugen før. Så kan der træffes et valg, mens der stadig er valg at træffe.

Del testen op i stedet for at skubbe den

En stor test i sidste øjeblik kan i nogle projekter erstattes af mindre dele, der ligger tidligere. Det kræver, at projektet ved, hvilke dele af løsningen der bliver færdige først.

Login, roller og adskillelsen mellem kunder kan være på plads, længe før de sidste skærmbilleder er færdige. De dele kan testes i et testmiljø, mens resten bliver udviklet. Fund i dem kan så rettes, mens der stadig er ro i projektet. Tættere på åbningen kan en kortere test se på det, der er kommet til, og på den endelige opsætning i drift.

Opdelingen skal aftales med testeren og beskrives i scope, så hver del har sit eget spørgsmål. Rapporterne skal kunne læses sammen, så det fremgår, hvilken udgave og hvilket miljø hver konklusion gælder for. → Penetrationstest i produktion eller testmiljø

Hvis datoen ligger fast

Nogle gange kan lanceringen ikke flyttes, og testen kan ikke rykkes tidligere. Så er der stadig måder at undgå den værste situation på.

  • Åbn i etaper · lad de dele, der er testet og rettet, gå i drift først, og vent med resten.
  • Hold funktioner tilbage · en funktion med et alvorligt fund kan slås fra ved åbningen og åbnes senere.
  • Begræns brugerne · åbn for en mindre gruppe, mens rettelserne bliver lavet.
  • Test det vigtigste først · aftal med testeren, at de mest kritiske dele undersøges tidligt i perioden.
  • Få besked undervejs · aftal, at alvorlige fund meldes med det samme og ikke først i rapporten.

Den sidste mulighed er særlig nyttig, når tiden er knap. Et alvorligt fund, der bliver meldt om tirsdagen, kan nå at blive rettet. Det samme fund i en rapport om fredagen kan ikke. → Kritisk fund midt i testen

Når åbningen sker med kendte fund

Hvis systemet åbner med fund, der ikke er rettet, skal det være en beslutning og ikke en glidning. En ansvarlig person med mandat skal vide, hvilke fund der er åbne, hvad de kan betyde, og hvornår de skal være rettet. Beslutningen skal skrives ned med dato og begrundelse. → Risikoaccept

Skeln mellem fund, der kan vente, og fund, der ikke kan. Et fund, der giver en kunde adgang til andre kunders oplysninger, er af en anden karakter end en mangel i, hvordan fejlbeskeder vises. Rapportens vurdering af alvorlighed er udgangspunktet, men virksomheden må selv vurdere betydningen for sin forretning. → Prioritering af rettelser

Fortæl også de berørte om beslutningen. Kundeservice skal vide, hvis en funktion er holdt tilbage, og driftsleverandøren skal vide, hvilke fund der er åbne, så overvågningen kan rettes mod dem. En beslutning, som kun projektlederen kender, beskytter ingen.

Sæt en dato for opfølgning allerede ved åbningen. Ellers bliver de åbne fund en del af driften, og ingen husker, at de var midlertidige.

Det skal I lade være med

  • At lægge testen som sidste milepæl · rettelser og efterprøvning skal også have plads før åbningen.
  • At lade forsinkelser spise testtiden · flyt hellere lanceringen eller del åbningen op.
  • At åbne uden en beslutning · kendte fund skal have en ansvarlig, der har sagt ja.
  • At rette i hast uden efterprøvning · en hurtig ændring kan løse problemet halvt eller skabe et nyt.
  • At vente på rapporten med alvorlige fund · aftal, at de meldes, så snart de er bekræftet.
  • At glemme de åbne fund efter lanceringen · de skal have en frist og en ejer.

Hvad kan og ikke kan konkluderes

En test lige før lanceringen kan stadig give værdi. Den dokumenterer, hvilke svagheder systemet havde ved åbningen, og den giver grundlag for en bevidst beslutning om, hvad der skal rettes først.

Den kan ikke vise, at systemet var klar til drift, hvis fundene ikke er rettet. En rettelse, der er lavet i de sidste timer uden efterprøvning, kan heller ikke regnes som dokumenteret. Og en rapport, der kommer efter åbningen, siger intet om, hvad der er sket i systemet siden testperioden.

Tjekliste til projektplanen

  • ☐ Er planen regnet baglæns fra lanceringsdatoen?
  • ☐ Er der tid til rettelser og efterprøvning efter rapporten?
  • ☐ Er det aftalt, at alvorlige fund meldes undervejs?
  • ☐ Er de mest kritiske dele placeret tidligt i testperioden?
  • ☐ Er der en plan for åbning i etaper eller for at holde funktioner tilbage?
  • ☐ Er det klart, hvem der beslutter åbning med kendte fund?
  • ☐ Har åbne fund en frist og en ejer efter lanceringen?

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Hvor lang tid tager en penetrationstest? · Spørgsmål og svar

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.