Pentest af et SaaS‑produkt: fra bestilling til kundeudlevering

Et softwarehus, der får et krav om penetrationstest fra en kunde, skal igennem en kæde af beslutninger, før kunden står med et dokument, den kan bruge. Kæden hviler på én tanke: hvert trin skal tilrettelægges med kundens brug for øje, fordi det er den læser, der til sidst vurderer, om testen var pengene og tiden værd.

Forløbet kan deles i otte trin. Kravet afklares, testeren vælges, omfanget fastlægges, testen gennemføres, fundene vurderes og rettes, rettelserne efterprøves, kunden får sin version af resultatet, og næste test planlægges. Nedenfor står hvert trin kort med det vigtigste spørgsmål, I skal kunne svare på, og et link til den artikel, der går i dybden.

Før bestillingen: hvad har kunden egentlig bedt om?

Trin et er at læse kravet nøjagtigt. Står der penetrationstest af produktet, af jeres virksomhed eller blot “uafhængig sikkerhedstest”? Skal kunden se en hel rapport, et resumé eller en testerklæring? Og hvornår skal dokumentet ligge hos kunden? Svarene bestemmer resten af kæden, så få dem skriftligt fra den person hos kunden, der skal godkende jer.

Kommer kravet midt i et salg, er der også en dato at forholde sig til. Giv kun kunden en dato, der ligger efter det sidste led, I selv har hånd om. → Aftalen venter på en pentestrapport

Tester og omfang: to beslutninger, der hænger sammen

Trin to er valget af tester. Kunden kan have krav til uafhængighed, kvalifikationer eller sprog i rapporten, og dem skal I kende, før I skriver kontrakt med nogen. Fortæl testeren fra første samtale, at resultatet skal deles med kunder. → Vælg en tester, kunderne vil acceptere

Trin tre er omfanget. For et SaaS-produkt handler det om webapplikationen, API’et, rollerne, adskillelsen mellem kunder og jeres egne administrations- og supportadgange. Det britiske NCSC beskriver, at en velafgrænset test kan give tillid til de komponenter, der blev testet, på testtidspunktet. Komponenter uden for omfanget siger testen intet om. Hvad der påvirker omfanget og dermed opgavens størrelse, kan I læse om under pris og tilbud. → Omfanget af testen

Bestillingen samler de tre første trin: kunden, testeren og omfanget skrevet ned i ét dokument, sammen med version, miljø og ønsket leverance. → Bestil testen til kundebrug

Mens testen kører

Trin fire er selve testen, og her er jeres opgave mest praktisk. Testeren skal have et miljø, der ligner produktionen, testkonti i de aftalte roller og en kontaktperson, der kan svare hurtigt. Udviklerne skal vide, at testen foregår, og hvem der må tale med testeren. Bliver der fundet noget kritisk undervejs, skal det på forhånd være aftalt, hvordan testeren melder det, og hvem hos jer der tager imod.

Undgå at ændre i den version, der testes, uden at sige det til testeren. Ellers kan rapporten komme til at beskrive en blanding af to versioner, og det bliver svært at forklare over for en kunde. → Testmiljøet: staging eller produktion?

Rapporten, rettelserne og efterprøvningen

Trin fem begynder, når rapporten lander. Læs den først internt, vurder hvert fund i forhold til jeres produkt og jeres kunder, og giv det en ejer og en plan. NCSC peger på, at beslutningen om, hvilke risici der accepteres, ligger hos den, der ejer risikoen, og ikke hos testteamet.

Trin seks er efterprøvningen. Et fund, I selv har meldt rettet, er noget andet end et fund, testeren har kontrolleret igen. Kunden vil spørge til netop den forskel, og et dokument fra testeren om efterprøvningen er stærkere end jeres egen forsikring. → Retestbevis til kunden

Til kunden: rapport, resumé eller testerklæring

Trin syv er udleveringen, og her skal I vælge form. Den fulde rapport giver kundens sikkerhedsfolk mest, men beskriver også jeres svagheder i detaljer. Et resumé eller en testerklæring kan sendes bredere. Erklæringsbrevet er testerens eget udsagn om testen, så formuleringerne i det er testerens, ikke jeres. → Hel rapport, resumé eller erklæring?

Uanset form skal I vide, hvem der har fået hvad, og på hvilke vilkår. En fortrolighedsaftale før udlevering og en simpel log over modtagere gør det muligt at svare, hvis kunden eller en revisor spørger senere. Mellem bestilling og færdig rapport kan kunden få en bekræftelse på, at testen er bestilt, men den er ikke en testerklæring.

Efter udleveringen: produktet bliver ved med at ændre sig

Trin otte bliver let glemt. Rapporten beskriver produktet på testtidspunktet, og hver release flytter produktet lidt væk fra det, der blev testet. Læg derfor en rytme for næste test, og beslut på forhånd, hvilke ændringer der udløser en ekstra test, fx en ny integration, et nyt login eller en ombygning af adskillelsen mellem kunder. → Testrytmen og jeres releases

Opdater samtidig de svar, kunderne allerede har fået, i skemaer, på en eventuel tillidsside og i jeres svarbibliotek. Gør det med det samme, når en ny rapport eller en ny efterprøvning foreligger, og ikke først når en kunde spørger. Et skemasvar, der henviser til en test fra for to versioner siden, uden at sige det, er et svar, der ikke længere passer.

Det skal I lade være med

At bestille, før kravet er forstået · så kan testen ende med at dække noget andet end det, kunden spurgte om.
At lade omfanget følge budgettet alene · kunden læser omfanget og ser, hvad der mangler.
At love kunden en dato, testeren ikke har bekræftet · datoen skal hvile på aftaler.
At kalde et fund rettet uden efterprøvning · skeln tydeligt mellem de to.
At skrive testerklæringen selv · den er testerens dokument.
At betragte rapporten som slutpunktet · produktet ændrer sig, og kravet kommer igen.

Hvad kan og ikke kan konkluderes

Et forløb, der følger de otte trin, giver kunden et dokument, der passer til kravet, og jer et grundlag, der kan genbruges over for næste kunde. Det siger intet om, hvor mange fund testen giver, og det gør ikke produktet sikkert. Kundens egne krav kan også kræve trin, der ikke står her, fx et særligt skema eller et møde med kundens sikkerhedsfolk.

Tjekliste for hele forløbet

☐ Kravet er afklaret skriftligt: dokumenttype, læser og dato. Se Hvad skal kunden bruge rapporten til?
☐ Testeren ved, at resultatet skal deles med kunder.
☐ Omfanget dækker det, kunderne køber, herunder API og adskillelse. Se Multi-tenant-test
☐ Miljø, testkonti og kontaktperson er klar før testens start.
☐ Hvert fund har en ejer og en plan.
☐ Rettede fund er efterprøvet af testeren.
☐ Formen til kunden er valgt, og udleveringen logges. Se Erklæringsbrevet fra testeren og Udlevering af rapporten
☐ Næste test og de ændringer, der udløser en ekstra, er planlagt. Se Ændringer, der kræver ny test

Kilder

NCSC: Penetration testing: en velafgrænset test giver tillid til de testede komponenter på testtidspunktet; beslutningen om risiko ligger hos risikoejeren.

Senest gennemgået: oktober 2026.