Kildekode til testeren: hvornår giver det mening for et softwarehus?

Et softwarehus ejer sin kildekode og passer på den. Alligevel kan det være en fordel at lade pentesteren læse med. Spørgsmålet er, om adgangen giver en bedre test af det, kunderne bekymrer sig om, og om fordelen står mål med hensynet til koden. Svaret hviler på to ting: hvad testen skal dokumentere, og hvor meget tid der er. Når testen skal sige noget om adgangskontrol og adskillelsen mellem kunderne inden for en begrænset tid, kan kildekoden give et mere præcist resultat. Når formålet er at vise, hvad en angriber udefra kan opnå uden forhåndsviden, er den mindre vigtig.

De tre niveauer af viden, black, grey og white box, er forklaret generelt på penetrationtest.dk. Her handler det om softwarehusets eget valg.

Hvad kildekoden giver testen

OWASP’s vejledning til test af webapplikationer beskriver gennemgang af kildekode som en metode, der kan finde alvorlige svagheder, som andre former for test ikke opdager, fx fejl i forretningslogik og adgangskontrol. Vejledningen anbefaler, at kildekoden stilles til rådighed for dem, der tester, fordi den kan afsløre svagheder, som ellers ville blive overset i en test uden forhåndsviden.

For et SaaS-produkt er det særligt relevant ved:

Adskillelse mellem kunder · koden viser, hvor kontrollen af kundegrænsen sidder, og hvor den mangler. → Multi-tenant: test af adskillelsen
Roller og rettigheder · koden viser, om alle funktioner tjekker brugerens rettigheder ens.
Funktioner, der er svære at nå · baggrundsjob, sjældent brugte indstillinger og ældre grænseflader.
Årsager frem for symptomer · når testeren ser koden, kan et fund ofte føres tilbage til en fælles årsag, som udviklerne kan rette ét sted.

Testtiden bliver dermed brugt på at afprøve det, koden viser kan være svagt, i stedet for på at kortlægge det, I allerede ved. For et softwarehus, der får samme spørgsmål om adskillelse og rettigheder fra mange kunder, er det en måde at få et mere solidt svar uden at forlænge testen. Vejledningen nævner også en begrænsning: den kode, der gennemgås, kan afvige fra den, der kører. Sørg derfor for, at testeren ser koden til den version, der testes.

Hvornår det giver mindre mening

Kildekoden er ikke altid den bedste brug af testen. Hvis kunden udtrykkeligt efterspørger en test, der viser, hvad en angriber uden forhåndsviden kan nå, skal testen tilrettelægges sådan. Hvis koden er meget stor, og testtiden kort, kan testeren bruge for meget tid på at læse og for lidt på at afprøve.

En pentest med adgang til kode er heller ikke det samme som en kodegennemgang. Pentesten bruger koden som støtte til at afprøve det kørende produkt. En kodegennemgang gennemgår koden systematisk og giver en anden slags dokumentation. Kunder, der efterspørger det ene, er ikke altid tilfredse med det andet. → Kodegennemgang eller penetrationstest?

Fortrolighed og adgang

Kildekoden kan være softwarehusets vigtigste aktiv. Adgangen skal derfor aftales lige så omhyggeligt som adgangen til produktet:

Fortrolighedsaftale · en skriftlig aftale med testeren, der dækker koden og alt, testeren lærer af den. Nielco IT underskriver fortrolighedsaftale på forespørgsel. → Fortrolighed begge veje
Læseadgang · adgang til at læse de relevante dele, ikke til at ændre noget, og helst uden at koden kopieres ud af jeres miljø.
Afgrænsning · de dele af koden, der hører til produktet i omfanget, ikke hele virksomhedens kodebase.
Tidsrum · adgangen lukkes, når testen og en eventuel retest er afsluttet.
Hemmeligheder · nøgler og adgangskoder, der ved en fejl ligger i koden, skal skiftes, hvis testeren ser dem. Det er i sig selv et fund.

Udviklerne i forløbet

Når testeren har koden, bliver dialogen med udviklerne mere konkret. Testeren kan spørge, hvorfor en kontrol er bygget på en bestemt måde, og udviklerne kan pege på de dele, de selv er usikre på. Det gør testen mere målrettet, men det kræver, at nogen hos jer har tid til at svare. → Udviklerne og testeren

En trusselsmodel fra udviklingen kan være et godt udgangspunkt. Den peger på de steder i koden, hvor testerens tid er bedst givet ud. → Trusselsmodellering før testen

Hvad kunderne skal vide

Rapporten skal sige, at testeren havde adgang til kildekoden, og til hvilke dele. Kunderne bruger den oplysning til at forstå resultatet. En test med kildekode kan finde flere og andre fund end en test uden. Det er ikke et tegn på, at produktet er svagere; det er et tegn på, at testen gik dybere.

Skriv det også i jeres svar til kunderne. Nogle kunder spørger direkte, om testen var black box, grey box eller white box. Et præcist svar viser, at I har tænkt over, hvad testen skulle dokumentere. → Omfangsafsnittet

Sammenligner en kunde to rapporter, en med og en uden adgang til kode, kan antallet af fund give et forkert billede. Forklar forskellen, så kunden ikke læser den dybere test som et tilbageskridt.

Et tænkt eksempel

Et softwarehus med et produkt til kontraktstyring har haft to test uden adgang til kode. Begge gav få fund, men flere store kunder spørger nu specifikt til adskillelsen mellem kunderne og til rettighederne for eksterne brugere, som kunderne inviterer ind. Testtiden er den samme som før.

Softwarehuset beslutter at give testeren læseadgang til de dele af koden, der styrer adgangskontrol og kundegrænse, under en fortrolighedsaftale og i et afgrænset tidsrum. Testen finder flere fund end tidligere, bl.a. en kontrol, der manglede i en sjældent brugt eksportfunktion. Rapporten nævner kodeadgangen, og svaret til kunderne forklarer, hvorfor antallet af fund er steget. Kunderne får et mere brugbart svar på netop de spørgsmål, de stillede.

Det skal I lade være med

At give kodeadgang uden skriftlig fortrolighedsaftale · koden er jeres vigtigste aktiv.
At give adgang til hele kodebasen, når kun produktet er i omfanget · afgræns adgangen.
At lade adgangen stå åben efter testen · luk den, når forløbet er slut.
At skjule, at testen havde kodeadgang · kunderne skal kunne forstå resultatet.
At kalde en pentest med kodeadgang en kodegennemgang · det er to forskellige leverancer.

Hvad kan og ikke kan konkluderes

En pentest med adgang til kildekoden kan give et mere præcist billede af adgangskontrol og adskillelse i den version, der blev testet. Den er ikke en systematisk gennemgang af al koden, og den siger intet om kode, der er ændret efter testen. En test uden kodeadgang kan til gengæld vise, hvad der kan nås uden forhåndsviden, men kan dække mindre i samme tid.

Tjekliste før I udleverer kildekoden

☐ Er det afklaret, hvad testen skal dokumentere over for kunderne?
☐ Er der en skriftlig fortrolighedsaftale med testeren?
☐ Er adgangen afgrænset til produktet i omfanget?
☐ Er adgangen kun til at læse?
☐ Er det aftalt, hvornår adgangen lukkes?
☐ Står det i rapporten, at testeren havde kodeadgang?

Kilder

OWASP Web Security Testing Guide: Introduction: gennemgang af kildekode og penetrationstest som metoder, og anbefalingen om at stille kildekoden til rådighed for dem, der tester.

Senest gennemgået: oktober 2026.