Kodegennemgang eller penetrationstest: hvad efterspørger kunderne?

Når en kunde stiller krav om dokumentation for sikkerheden i jeres produkt, står ordet kodegennemgang ikke altid alene i kravet. Svaret på, hvad kunden faktisk efterspørger, hviler på forskellen mellem de to leverancer: en penetrationstest viser, hvad der kunne misbruges i det kørende produkt, mens en kodegennemgang viser, hvordan koden er skrevet, og hvilke svagheder den rummer.

Kort sagt: beder kunden om en rapport, der kan læses af kundens sikkerhedsfolk, er det som regel en penetrationstest, der skal ligge bag. En kodegennemgang styrker jeres svar om udviklingen, men den erstatter ikke nødvendigvis testen i kundens øjne. Hvor kravet er uklart, er det billigste svar et spørgsmål til kunden.

To leverancer, to slags dokumentation

En kodegennemgang ser på kildekoden. Den kan udføres af jeres egne udviklere som en del af det daglige arbejde, eller af en ekstern part, der læser udvalgte dele af koden med sikkerheden for øje. Resultatet beskriver svagheder i koden, uanset om de kan nås udefra eller ej.

En penetrationstest ser på produktet, som det kører. Testeren bruger produktet som kunder, brugere og udefrakommende og prøver at nå det, rollerne ikke tillader. Resultatet beskriver, hvad der faktisk lod sig gøre i den version og det miljø, der var med.

NIST’s ramme for sikker softwareudvikling, SSDF, holder de to adskilt: én praksis handler om at gennemgå eller analysere koden, en anden om at teste den kørende software. Penetrationstest nævnes dér som et eksempel på test i scenarier med høj risiko. Rammen bruges også af købere, når de taler med leverandører om udvikling. → Spørgsmål om sikker udvikling og kodegennemgang

Hvor kunderne stiller spørgsmålene

Kravet kan komme tre steder fra, og hvert sted har sin egen forventning:

Sikkerhedsspørgeskemaet · her står spørgsmål om kodegennemgang og om penetrationstest måske som to separate linjer, og hver linje skal have sit eget svar.
Kontrakten eller sikkerhedsbilaget · her kan der stå, at løsningen skal testes regelmæssigt af en uafhængig part, og det læses som en pentest.
Kundens sikkerhedsmøde · her bliver I spurgt, hvordan I sikrer koden mellem to test, og her hører kodegennemgangen hjemme.

Hvis et krav kun siger sikkerhedstest, så spørg, hvad kunden skal bruge resultatet til. En kunde, der skal dokumentere sin leverandørvurdering, har brug for et dokument fra en tredjepart. En kunde, der vil forstå jeres udviklingspraksis, har brug for en beskrivelse af processen. → Hvad skal kunden bruge rapporten til?

Det, en kodegennemgang kan vise kunden

En kodegennemgang kan finde svagheder, som en test af det kørende produkt ikke når frem til i den aftalte tid: logik, der kun aktiveres i sjældne situationer, kode, der ikke længere bruges, men stadig ligger der, og kontrol af adgang, der er bygget forskelligt fra modul til modul.

Over for kunderne er det ikke nødvendigvis selve gennemgangens fund, der bliver udleveret. Det er det faktum, at gennemgangen sker, hvem der udfører den, og hvordan fund bliver fulgt op. En intern gennemgang, der er en fast del af jeres udviklingsproces, er et godt svar på spørgsmålet om sikker udvikling. Den bliver ikke nødvendigvis accepteret som den uafhængige test, kunden har bedt om. → Kunden accepterer ikke jeres egen interne test

En ekstern kodegennemgang af et afgrænset område, fx betalingsmodulet eller den del, der adskiller kunderne, kan give kunden noget ekstra. Men den skal beskrives præcist, så kunden ikke læser den som en gennemgang af hele produktet.

Det, pentesten viser, som koden ikke afslører

Koden er kun en del af produktet. Det, kunden møder, er også opsætningen af miljøet, de roller, der er oprettet, integrationerne til andre systemer og den måde, produktet er udrullet på. En svaghed kan opstå i samspillet mellem dele, der hver for sig ser fornuftige ud.

Pentesten afprøver netop samspillet. Den kan vise, at en kunde kan nå en anden kundes data, at en rolle kan mere end tilsigtet, eller at en indstilling i produktionen er anderledes end i udviklingen. Det er de spørgsmål, kundernes sikkerhedsfolk leder efter svar på i rapporten.

Den britiske NCSC peger på, at test af specialudviklet software bør give udviklerne tilbagemelding på deres kodepraksis. Pentesten er altså ikke kun et dokument til kunden; fundene kan også fortælle jer, hvor kodegennemgangen bør skærpes.

Når kunden vil have begge dele

Nogle kunder, fx i regulerede sektorer, beder om både en penetrationstest og en beskrivelse af jeres kodegennemgang. Det er to forskellige svar, og de skal holdes adskilt i dokumentationen. Kunden vil måske se en rapport fra testen og en kort beskrivelse af, hvornår koden gennemgås, hvem der gør det, og hvad der sker med fundene bagefter.

Testen kan også bestilles med adgang til koden, så testeren kan bruge den til at forstå produktet og målrette arbejdet. Det er stadig en penetrationstest, og rapporten skal sige, hvad koden blev brugt til, og hvad der ikke blev gennemgået. Om det er en god idé for jer, afhænger af produktet og af, hvad kunden skal kunne læse. → Kildekode til testeren

Uanset kombinationen gælder det samme: omfangsafsnittet skal kunne læses af en kunde, der ikke kender produktet. Står der kodegennemgang og test i samme sætning, skal det fremgå, hvad der hører til hvad. → Omfangsafsnittet

Hvor meget en ekstra gennemgang eller en test med kodeadgang fylder i opgaven, afhænger af produktets størrelse og af, hvor mange områder der skal dækkes. Det er en del af → pris og tilbud.

Det skal I lade være med

Kalde en kodegennemgang for en pentest · kunden opdager forskellen, når rapporten mangler afprøvning af det kørende produkt.
Svare ja til begge spørgsmål med én aktivitet · to linjer i skemaet kræver to svar, der hver kan dokumenteres.
Udlevere gennemgangens fund uden at tænke over det · detaljer om koden siger meget om, hvor produktet er svagt.
Lade et automatisk kodetjek stå som en gennemgang · kunden kan spørge til en menneskelig vurdering.
Gætte på kundens krav · spørg, hvad kunden skal bruge dokumentationen til.

Hvad kan og ikke kan konkluderes

En penetrationstest viser, hvad der kunne udnyttes i den testede version og det testede miljø. En kodegennemgang viser svagheder i den kode, der blev læst. Ingen af dem viser, at produktet er uden fejl, og ingen af dem dækker mere, end omfanget siger.

Tjekliste før I svarer kunden

☐ Ved I, om kunden beder om en test, en beskrivelse af udviklingen eller begge dele?
☐ Er kodegennemgang og penetrationstest beskrevet hver for sig i jeres svar?
☐ Kan I dokumentere, hvem der udfører gennemgangen, og hvordan fund følges op?
☐ Står det i rapporten, om testeren havde adgang til koden?
☐ Er det besluttet, hvad af gennemgangens resultater der må udleveres?

Kilder

NIST SP 800-218, Secure Software Development Framework: praksis PW.7 (gennemgang og analyse af kode) og PW.8 (test af kørende kode, med penetrationstest som eksempel ved høj risiko); rammen kan bruges i dialogen mellem købere og leverandører.
NCSC (UK): Penetration testing: test af specialudviklet software bør give udviklerne tilbagemelding på kodepraksis.

Senest gennemgået: oktober 2026.