Før eller siden skriver en stor kunde, at de vil se en pentest af produktet, ofte tæt på en underskrift. En pentest, eller penetrationstest, er et aftalt forsøg på at bryde ind i produktet, udført af specialister, der bruger samme metoder som en angriber. Resultatet bliver mere værd for jer, hvis forarbejdet er gjort, før testen bestilles. Det handler om at rette det, I allerede kender, gøre klart hvad testen skal dække, stille et egnet miljø til rådighed og have et team, der kan rette fundene. Det meste af det kan gøres uden en ekstern tester.
Afklar, hvad kunden faktisk vil se
Spørg, før I bestiller. Mange kunder vil have noget mere præcist end ordet pentest:
- Skal rapporten dække hele produktet eller en bestemt del?
- Hvor gammel må den være?
- Vil de se hele rapporten eller et sammendrag?
- Skal der være test af det API, de selv skal bruge?
- Har de krav til, hvem der tester?
- Vil de have bevis for, at fundene er rettet?
Svarene styrer omfanget. Oftest hører spørgsmålet til en større sag, nemlig kundens samlede vurdering af jer som leverandør, se kundens spørgeskema om produktet og, set fra ledelsen, sikkerhedsspørgeskemaet fra kunden.
Ret det, I allerede kender
En tester skal ikke bruge tiden på at finde det, I selv kunne have fundet. Gå disse punkter igennem i god tid:
- Afhængigheder. Opdater biblioteker med kendte sårbarheder, og se tredjepartsbiblioteker, SBOM og byggepipeline.
- Nøgler. Fjern hemmeligheder fra koden og frontend, se nøgler og adgangskoder.
- Rettigheder. Tjek, at adgangskontrol sker på serveren. En almindelig bruger må ikke kunne nå en administrators funktioner ved at ændre en adresse eller et id.
- Adskillelse af kunder. Prøv selv, om en bruger hos kunde A kan se data hos kunde B. I en SaaS er det en af de fejl, der skader mest.
- Login. Grænser for forsøg, nulstilling af adgangskode og udløb af sessioner.
- Opsætning. Offentlige lagerområder, administrationsflader, der kan nås fra internettet, og gamle testmiljøer, ingen husker.
- Glemte dele. Gamle API-versioner og funktioner, der ikke bruges længere. Fjern dem, eller tag dem med i testen.
Kravene i OWASP ASVS kan bruges som tjekliste til jeres egen gennemgang, og de er også et fælles sprog med testeren.
Beskriv, hvad der skal testes
Testeren kan kun nå det, I beskriver. Lav en kort oversigt over:
- Adresser, API’er og apps, der er med, og det, der er ude.
- Brugerroller, med en testkonto til hver, gerne to kunder, så adskillelsen kan prøves.
- Den tekniske opbygning. Arkitekturbeskrivelsen på tre sider dækker det meste.
- Kendte begrænsninger, som I allerede har besluttet at leve med.
Vælg miljøet med omtanke
Test sker oftest i et separat miljø, der ligner produktionen. Det skal have samme version og opsætning, ellers siger testen ikke meget om det, kunderne bruger. Brug konstruerede data, og lad være med at kopiere kundernes oplysninger ind. Hvorfor, står i persondata i produktet.
Skal der testes i produktion, skal det aftales nøje, hvad testeren må, og hvornår. Læs også reglerne hos jeres cloududbyder, for nogle tjenester har egne vilkår for sikkerhedstest. Rører testen kunders installationer eller data, skal de eventuelt have besked.
Lad overvågningen være tændt under testen. Så lærer I samtidig, om I selv opdager forsøgene.
Gør teamet klar til fundene
En rapport uden rettelser er næsten værdiløs, og den kan i værste fald gøre sagen sværere over for kunden. Afklar derfor, inden testen starter:
- Hvem læser rapporten først, og hvem vurderer fundene?
- Hvor meget kapacitet er afsat til rettelser de næste uger?
- Hvor hurtigt skal alvorlige fund lukkes?
- Hvem bestiller gentest af de rettede fund?
- Hvad må kunden se, og hvem taler med dem?
Lad ikke testen slutte dagen før et kundemøde. Der skal være tid til at rette og teste igen.
Hold det i gang
En test er et øjebliksbillede. Produktet ændrer sig hver uge, og kunden spørger igen næste år. Læg derfor testen ind i årets plan, og knyt den til de større ændringer. Teamets faste vaner, se sikker softwareudvikling i et lille team, gør hver ny test mere værd, for fundene flytter sig fra det oplagte til det svære.
Det skal I lade være med
- At bestille testen dagen efter kundens krav · uden forarbejde køber I en liste over det, I allerede vidste.
- At bruge rigtige kundedata i testmiljøet · brug konstruerede data.
- At bede testeren holde sig fra det svage · kunden vil spørge til netop det.
- At lade samme firma både bygge produktet og teste det · testen skal stå uafhængigt af dem, der byggede.
Det skal I kræve af den eksterne
- ☐ En afklaring af, hvad kunden præcist vil have.
- ☐ En oversigt over omfang, roller og miljø.
- ☐ En plan for rettelser med afsat kapacitet.
- ☐ Et uafhængigt syn på, hvem der tester.
- ☐ En aftale om, hvad kunden får at se.
Kilder
- OWASP Application Security Verification Standard: testbare krav til webapplikationer.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Kundens IT-arkitekt vil have et møde · Når kunderne stiller krav til produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
