Pentestrapport

Funktioner, der kun er slået til for nogle kunder

Funktioner, der kun er slået til for nogle kunder

Når en funktion kun er slået til for udvalgte kunder, står I med et spørgsmål, som pentestrapporten ikke selv svarer på: var den med i testen eller ej? Svaret hviler på en enkel regel. En funktion er kun testet, hvis den var slået til der, hvor testeren arbejdede, og hvis den stod i omfanget. At koden ligger i produktet hos alle, er ikke nok.

Det lyder banalt, men netop her glider sælgerens svar og rapportens indhold lettest fra hinanden. Funktionen er i drift hos en håndfuld kunder, sælgeren omtaler produktet som testet, og rapporten nævner den ikke med et ord.

Hvorfor skjulte funktioner er et særligt problem

Funktionsflag (feature flags) bruges til at rulle nyt ud gradvist, til at give enkelte kunder adgang til et modul, de har betalt for, eller til at holde noget halvfærdigt skjult, indtil det er klar. For driften er det praktisk. For testen betyder det, at produktet ikke er ét produkt, men mange kombinationer af til og fra.

En tester ser kun det, testlejerne kan se. Er et flag slået fra i testmiljøet, er funktionen bag det i praksis usynlig, selv om koden er der. Rapporten kan derfor med rette sige, at produktet er testet, og samtidig tie om en funktion, som nogle af jeres kunder bruger hver dag. → Testlejere

Tre slags flag, tre forskellige svar

Det hjælper at sortere flagene efter, hvad de bruges til:

  • Gradvis udrulning · funktionen skal ud til alle, men starter hos få. Den hører med i næste test og helst før den bliver bred.
  • Betalte moduler og tilvalg · funktionen er varigt forbeholdt nogle kunder. Den skal med i omfanget, hvis de kunder får rapporten som dokumentation.
  • Midlertidige og interne flag · eksperimenter, nødafbrydere og noget, kunderne aldrig skulle se. De skal ryddes op, eller det skal være sikkert, at kun I kan slå dem til.

Den sidste gruppe kan blive overset. Gamle flag, som ingen længere husker, kan holde en halvfærdig funktion i live i produktionen. Så er spørgsmålet ikke kun, om den blev testet, men om den overhovedet burde findes.

Flagene og testens omfang

Når testen planlægges, bør nogen i teamet kunne sige, hvilke flag der findes, og hvilke der er slået til hos kunder. Den oversigt er grundlaget for at beslutte, hvad testlejerne skal have slået til. Et rimeligt udgangspunkt er, at alt, der er slået til for mindst én betalende kunde, også er slået til hos mindst én testlejer.

Holder I bevidst et flag ude af testen, så skriv det i omfanget. Så kan en kunde, der bruger netop den funktion, se det selv, og I slipper for at rette indtrykket bagefter. → Omfangsafsnittet

Flagene ændrer også, hvad rollerne kan. En funktion, der er slået til, kan give nye rettigheder, nye skærmbilleder og nye kald til produktets API. Testeren skal derfor have adgang med de roller, der faktisk bruger funktionen, og ikke kun som administrator.

Endelig hører flagene med i beslutningen om, hvilken version der testes. Et build kan være det rigtige, men med andre flag end produktionen, og så passer rapporten ikke til det, kunderne kører. → Hyppige udrulninger: hvilken version skal testes?

Når kunden spørger, om deres modul er testet

Spørgsmålet kan komme fra den kunde, der har købt et tilvalg, eller fra en kunde i en pilotgruppe. Svar præcist: var funktionen slået til i testen, i hvilken version, og står den i omfanget? Er svaret nej, så sig det, og forklar, hvornår den kommer med. → Rapporten dækker ikke det modul, kunden køber

Det er fristende at svare, at koden er den samme for alle. Det er sandt, men det er ikke det, kunden spørger om. Kunden vil vide, om nogen har set på funktionen med en angribers øjne, og kun rapporten kan svare på det.

Før flaget slås til for alle

Det bedste tidspunkt at teste en funktion, der rulles gradvist ud, er mens den kun er slået til for få. En fejl rammer færre kunder, og rettelsen kan nå ud, før funktionen bliver standard. Har jeres rytme kun én større test om året, kan det være anledningen til en mindre, afgrænset test af netop den funktion. → Penetrationstest af en ny funktion før lancering

Udrulning til en lille gruppe kan ligne en pilot med rigtige kunder. Så gælder de samme overvejelser om kundernes data og om, hvad de har fået at vide om testen. → Beta eller pilot med rigtige kunder

Et tænkt eksempel

Et softwarehus har et økonomimodul, som tre kunder har købt som tilvalg. Modulet ligger bag et flag. Ved den årlige test var flaget slået fra hos testlejerne, fordi ingen tænkte på det. Rapporten nævner ikke modulet, og omfangsafsnittet siger blot, at produktet i den aktuelle version er testet.

En ny kunde vil købe modulet og beder om dokumentation for test. Sælgeren sender rapporten. Kundens sikkerhedsansvarlige finder ikke modulet i omfanget og spørger ind. Nu skal softwarehuset forklare hullet og love en test, der kunne have været med fra starten.

Havde flagoversigten været en del af planlægningen, ville modulet have været slået til hos en testlejer, og rapporten kunne have svaret for sig selv. Sælgeren ville samtidig have vidst, at modulet var med, og kunne have sagt det i første svar i stedet for at vente på kundens spørgsmål.

Det skal I lade være med

  • Sætte lighedstegn mellem kode i produktet og testet kode · kun det, der var slået til, er afprøvet.
  • Teste med flagene, som de tilfældigvis står i staging · de afspejler ikke nødvendigvis kunderne.
  • Lade glemte flag leve · gamle funktioner er svære at forklare og måske ikke testet.
  • Give testeren kun én rolle · funktioner bag flag kan ændre, hvad rollerne kan.
  • Sige til kunden, at tilvalget er dækket, uden at tjekke · kunden kan selv læse omfanget.
  • Vente med testen, til funktionen er ude hos alle · så rammer en fejl også alle.

Hvad kan og ikke kan konkluderes

En test kan sige noget om de funktioner, der var slået til hos testlejerne, i den version, der blev testet. Den siger intet om funktioner bag et slukket flag, selv om koden var den samme, og intet om flag, der er kommet til siden.

Tjekliste til funktioner bag flag

  • ☐ Findes der en oversigt over flag, og over hvem de er slået til for?
  • ☐ Er alt, der er slået til for betalende kunder, også slået til hos en testlejer?
  • ☐ Står bevidst udeladte funktioner i omfanget?
  • ☐ Har testeren de roller, der bruger funktionerne?
  • ☐ Er gamle og interne flag ryddet op?
  • ☐ Kan sælgeren svare på, om en kundes tilvalg var med?

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Hvilke ændringer i produktet kræver en ny test? · Testlejere

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS 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

Kræver kunden en pentestrapport?

Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.