Penetrationstest af en ny funktion før lancering

Når et softwarehus lancerer en ny funktion, står den seneste pentestrapport pludselig og beskriver et produkt, der ikke længere findes i præcis den form. Om funktionen skal testes for sig, afhænger af, hvad den rører ved: håndterer den nye slags data, giver den nye rettigheder eller åbner den en ny vej ind, er en afgrænset test før lanceringen ofte det, der holder jeres svar til kunderne retvisende.

En afgrænset test er ikke en lille udgave af den årlige test. Den har sit eget formål: at undersøge det nye og det, det nye berører, mens der stadig er tid til at rette, og før kunderne begynder at lægge data ind.

Hvornår en ny funktion fortjener sin egen test

En ny funktion kan være en udvidelse af noget, der allerede er testet. En ny visning, et ekstra felt eller en anden sortering ændrer ikke nødvendigvis noget, kunden har grund til at bekymre sig om. Andre funktioner flytter grænser. Det gælder funktioner, der deler data med personer uden for kundens konto, nye roller med flere rettigheder, betaling, automatiske handlinger på brugerens vegne, eksport af store datamængder og nye koblinger til andre systemer.

NIST’s ramme for sikker softwareudvikling, SSDF, anbefaler mere grundige vurderinger af områder med høj risiko og nævner beskyttelse af følsomme data og kontrol af identitet, login og adgang som eksempler. Det er en brugbar målestok for et softwarehus: jo tættere den nye funktion ligger på de områder, jo stærkere er grunden til at teste den, før den slås til. Kriterierne for, hvilke ændringer der i det hele taget skal vurderes, er beskrevet for sig. → Ændringer, der kræver en ny test

Afgræns testen til det nye og dets kanter

Det svære ved en afgrænset test er at trække grænsen rigtigt. Testes kun den nye funktion isoleret, kan det overses, at den har ændret noget i det eksisterende. Testes for meget, bliver det en ny fuld test med en tidsplan, lanceringen ikke kan bære.

En god afgrænsning har tre dele:

Selve funktionen · skærmbilleder, kald i API’et og de handlinger, funktionen tilbyder.
Kanterne · de steder, hvor funktionen møder resten af produktet, fx rollemodellen, adskillelsen mellem kunderne og de data, funktionen kan læse eller ændre.
Det, der bevidst er udeladt · resten af produktet, som er dækket af den seneste brede test, og som rapporten derfor ikke siger noget nyt om.

Den sidste del er lige så vigtig som de to første. Den gør det tydeligt for kunderne, hvad den nye rapport kan bruges til. → Hvad skal med i en pentest af et SaaS-produkt?

Hvad I aftaler med testeren

Før testen starter, skal der være enighed om nogle få punkter. Flere af dem handler om timing og miljø, fordi en funktion før lancering endnu ikke findes i produktionen.

Miljøet · om testen sker i et testmiljø, i produktionen med funktionen slået til for testkonti, eller begge dele. → Et staging-miljø til testen
Versionen · hvilken udgave af funktionen der testes, og om den må ændres undervejs.
Roller og data · hvilke testkonti og testdata testeren får, så funktionen kan afprøves med de rettigheder, kunderne vil have.
Tid til rettelser · hvor lang tid der er mellem testens afslutning og lanceringen.
Rapportform · om resultatet skal være en selvstændig rapport, et tillæg til den seneste, eller et kortere notat til internt brug.

Det fjerde punkt bestemmer, hvor meget testen kan nå at gøre gavn. Ligger testen dagen før lanceringen, kan fundene kun bruges til at beslutte, om datoen holder. Hvordan testen passes ind i releaseplanen, er en sag for sig. → Lanceringsdato og testvindue

Fund før lancering: hvad de betyder for kunderne

Et fund i en funktion, der endnu ikke er lanceret, har ikke ramt nogen kunde. Det er den store fordel ved at teste før. Fundet kan rettes, og retesten kan ligge, før funktionen slås til, så den rapport, kunderne til sidst ser, beskriver en funktion uden kendte alvorlige fund.

Det kræver dog, at I er ærlige over for jer selv om, hvad der blev fundet. Et alvorligt fund i en ny delingsfunktion kan betyde, at funktionen skal vente. Et mindre fund kan måske lanceres med en plan for rettelsen. Den beslutning skal træffes af dem, der ejer produktet, med fundets betydning for kunderne som udgangspunkt, ikke kun lanceringsdatoen.

Kunder, der har fået lovning på funktionen, vil hellere have den lidt senere end i en udgave, der skal trækkes tilbage. Og en kunde i en leverandørvurdering spørger måske ikke, hvornår en funktion kom, men om den var testet, da den kom.

Rapporten fra en afgrænset test i salget

En rapport om en enkelt funktion er et godt supplement, men den erstatter ikke den brede rapport. Når en kunde beder om jeres seneste pentest, bør I kunne vise begge: den brede test af produktet og den afgrænsede test af det nye, med datoer og versioner, så kunden kan se, hvordan de hænger sammen.

Forestil jer et softwarehus med et system til vagtplanlægning, der lancerer en funktion, hvor medarbejdere kan bytte vagter med kolleger hos samarbejdende virksomheder. Funktionen krydser for første gang grænsen mellem to kunder. Den afgrænsede test omfatter selve byttefunktionen, rollerne for godkendelse og adskillelsen mellem de to kunders data. Rapporten nævner, at resten af produktet blev testet i den brede test tidligere på året, og hvilken version det var.

Spørger kunden, om hele produktet er testet efter lanceringen, er det ærlige svar: den nye funktion og dens kanter er testet, resten er testet i den brede test, og de ændringer, der er kommet siden, er vurderet. → Meget er udgivet siden testen

Omfanget af en afgrænset test afhænger af funktionens størrelse, hvor mange roller og integrationer den berører, og hvilket miljø der testes i. Det er de forhold, der indgår i → pris og tilbud.

Det skal I lade være med

Teste funktionen uden dens kanter · fejl kan opstå, hvor det nye møder det gamle.
Lægge testen, så der ikke er tid til at rette · så bliver fundene en ubehagelig overraskelse i stedet for en hjælp.
Kalde en afgrænset test for en ny pentest af produktet · kunden vil læse det som en test af det hele.
Ændre funktionen væsentligt efter testen · så beskriver rapporten ikke det, der blev lanceret.
Lancere med alvorlige fund for at holde datoen · uden at ledelsen har taget stilling til det.

Hvad kan og ikke kan konkluderes

En afgrænset test viser, hvad testeren fandt i den nye funktion og dens kanter i den version, der blev testet. Den siger ikke noget nyt om resten af produktet, og den dækker ikke ændringer i funktionen efter testen. Sammen med den brede rapport kan den give kunderne et retvisende billede af produktet ved lanceringen.

Tjekliste før funktionen slås til

☐ Er det vurderet, om funktionen berører data, roller, adskillelse eller nye veje ind?
☐ Er afgrænsningen skrevet ned, inklusive det, der bevidst er udeladt?
☐ Er der aftalt miljø, version, testkonti og rapportform med testeren?
☐ Er der tid til at rette og efterprøve fund før lanceringen?
☐ Har produktejeren taget stilling til eventuelle åbne fund?
☐ Kan I vise kunderne både den brede og den afgrænsede rapport?

Kilder

NIST SP 800-218, Secure Software Development Framework, praksis PW.1.1, eksempel 2: mere grundige vurderinger af områder med høj risiko, fx beskyttelse af følsomme data og kontrol af identitet, login og adgang.

Senest gennemgået: oktober 2026.