Når produktet kører på kundens egne servere, er det ikke længere jer, der bestemmer opsætningen, hvem der kan nå systemet, og hvornår det bliver opdateret. Fordelingen af testen hviler derfor på ejerskab: I tester det, alle installationer har til fælles, altså softwaren i den version, I leverer. Kunden tester sin egen installation, sit net og sine egne valg. Jeres pentestrapport kan dokumentere produktet, men aldrig den konkrete installation hos en bestemt kunde.
Det lyder enkelt, men de to ting kan blive blandet sammen. Kunden beder om jeres rapport og forventer, at den siger noget om serveren i deres eget serverrum.
To test af det samme produkt
En test, I selv bestiller, afprøver produktet i et miljø, I har bygget efter jeres egen installationsvejledning. Den svarer på, om softwaren holder, når den er sat op, som I anbefaler.
En test, kunden bestiller, afprøver et kørende system i kundens net. Den svarer på, om netop deres installation er sikker nok med deres netværk, deres konti og deres opdateringsniveau. Den britiske NCSC beskriver penetrationstest som en metode til at undersøge et konkret system i drift, der består af produkter og tjenester fra flere leverandører. Kundens test passer til den beskrivelse. Jeres egen test skal derfor bestilles og beskrives, så den kan bruges som dokumentation for produktet og ikke forveksles med en vurdering af kundens drift. → Omfanget af testen
De to rapporter supplerer hinanden. Ingen af dem kan erstatte den anden.
Et tænkt eksempel
Et softwarehus leverer et planlægningssystem, som logistikvirksomheder installerer på egne servere. En kunde sender et sikkerhedsspørgeskema og beder om den seneste pentestrapport. Softwarehuset sender et resumé af testen af den aktuelle version, afprøvet i et miljø bygget efter installationsvejledningen. Samtidig skriver det i svaret, at kundens netværk, servere og opdateringsniveau ikke er omfattet, og at kunden kan lade sin egen installation teste efter de aftalte regler.
Kunden får dermed to ting: dokumentation for produktet og et klart billede af, hvad der er kundens egen opgave. Spørgsmålet om, hvem der har ansvaret for hvad, bliver afklaret i salget og ikke først efter en hændelse.
Det, jeres test kan dække
Jeres test omfatter alt det, der følger med, når kunden installerer produktet:
- Applikationen · login, roller, rettigheder og de funktioner, alle kunder bruger.
- Standardopsætningen · de indstillinger, produktet leveres med, og de valg, installationsvejledningen anbefaler.
- Forbindelser · de grænseflader, produktet åbner mod brugere, andre systemer og jeres support.
- Opdateringer · måden nye versioner leveres på, og om kunden kan stole på, at de kommer fra jer.
- Supportadgang · den adgang, jeres medarbejdere bruger, når de hjælper en kunde med installationen. → Supportadgang og administrationsmodul
Rapporten skal sige præcist, hvilken version og hvilken opsætning der blev testet. En kunde, der kører en anden version eller har fravalgt en anbefaling, skal kunne se det selv. → Den testede version
Det, kunden selv står for
Alt omkring softwaren er kundens. Det gælder servere og styresystem, netværket og adgangen udefra, kundens egne brugerkonti og den måde, de er koblet til kundens katalog på, samt sikkerhedskopier og overvågning. Kunden bestemmer også, hvor hurtigt nye versioner bliver installeret, og om installationsvejledningen er fulgt.
Integrationer til kundens øvrige systemer ligger et sted imellem. I ejer den del af produktet, der sender og modtager data. Kunden ejer sine egne systemer og den måde, forbindelsen er sat op på. → Kundens eget ansvar
Skriv fordelingen ned i dokumentationen til kunderne. Så kan kundens sikkerhedsansvarlige se, hvad jeres rapport dækker, og hvad de selv skal sørge for at få undersøgt.
Når kunden tester installationen
Kunden må gerne teste sit eget system, også den del, der er jeres software. I har sjældent grund til at sige nej, men der er forhold, I bør aftale:
- Besked på forhånd · så jeres support ikke bruger tid på fejlmeldinger, der skyldes testen.
- Licensvilkårene · om de siger noget om test af softwaren, og om de skal opdateres.
- Fund i produktet · at kunden sender jer de fund, der vedrører selve softwaren, så I kan rette dem for alle.
- Fortrolighed · at kunden ikke deler detaljer om svagheder i produktet med andre, før I har en rettelse klar.
Kundens fund kan være værdifulde. De viser produktet i en virkelig opsætning, som jeres eget testmiljø ikke altid ligner. → Kunden vil selv teste produktet
Et fund i produktet rammer alle installationer
Når en svaghed sidder i softwaren og ikke i kundens opsætning, findes den hos alle, der kører den pågældende version. I et SaaS-produkt retter I fejlen ét sted. Når produktet er installeret hos kunderne, skal hver kunde selv installere rettelsen, og I ved ikke altid, hvem der har gjort det.
Det stiller krav til jeres proces efter testen: en ny version, en meddelelse, der forklarer, hvem der er berørt, og en måde at følge op på. Kunder, der kører en ældre version, skal have et klart svar på, om de er berørt, og hvad de kan gøre. → Underretning om sårbarheder
For produkter, der er omfattet af EU’s Cyber Resilience Act, nævner forordningens bilag I, del II, bl.a. regelmæssig afprøvning af produktets sikkerhed og sikkerhedsopdateringer til at afhjælpe sårbarheder. Om jeres produkt er omfattet, skal vurderes for sig; teksten her er ikke juridisk rådgivning.
Det skal I lade være med
- At lade jeres rapport fremstå som en test af kundens installation · den dækker produktet, ikke kundens server.
- At teste i et miljø, der ikke følger jeres egen vejledning · så dokumenterer rapporten en opsætning, ingen kunde har.
- At afvise kundens egen test · aftal hellere rammen og få fundene i produktet tilbage.
- At glemme supportadgangen · den åbner ind til kundens miljø og hører med i jeres test.
- At sende en rettelse uden forklaring · kunden skal vide, om rettelsen haster for netop deres version.
- At love, at installationen er sikker, når vejledningen er fulgt · testen viser, hvad der blev fundet, ikke hvad der aldrig kan ske.
Hvad kan og ikke kan konkluderes
En test af produktet i jeres eget miljø kan vise, at softwaren i den testede version og opsætning holdt under de forsøg, testeren gjorde. Den siger intet om kundens net, kundens konti eller kundens opdateringsniveau. Kundens egen test kan vise, at installationen var sikker på testdagen, men den kan sjældent sige noget om produktet i andre versioner eller hos andre kunder.
Tjekliste til installationer hos kunder
- ☐ Er testmiljøet bygget efter jeres egen installationsvejledning?
- ☐ Angiver rapporten version og opsætning?
- ☐ Er det beskrevet for kunderne, hvad jeres test dækker, og hvad de selv skal teste?
- ☐ Er supportadgangen med i omfanget?
- ☐ Er der en aftale om, at kunden sender fund i produktet til jer?
- ☐ Har I en plan for at nå alle installationer med en rettelse?
Kilder
- NCSC (UK): Penetration testing: penetrationstest som undersøgelse af et konkret system i drift med produkter og tjenester fra flere leverandører.
- Cyber Resilience Act, forordning (EU) 2024/2847: bilag I, del II, om håndtering af sårbarheder, herunder regelmæssig afprøvning og sikkerhedsopdateringer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: En gammel version, der stadig har kunder · Cyber Resilience Act
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT