Automatiske sikkerhedstest i pipelinen og den manuelle pentest

Mange softwarehuse har sikkerhedskontroller bygget ind i den automatiske kæde, der bygger, tester og udruller koden, og det får nogle til at spørge, om pentesten så stadig er nødvendig. Svaret hviler på, hvad hver af dem kan dokumentere over for kunderne: de automatiske test viser, at bestemte kendte fejltyper kontrolleres ved hver ændring, mens pentesten viser, hvad en person med indsigt fandt, da produktet blev undersøgt som helhed.

De to dele supplerer hinanden. Den ene erstatter ikke den anden, og kunderne skal kunne se forskellen i jeres svar.

To slags sikkerhedsarbejde med hver sit formål

De automatiske test lever i udviklingen. De kører, hver gang koden ændres, og de stopper eller markerer ændringer, der falder igennem bestemte kontroller. Det kan være kontrol af kode, af komponenter fra tredjepart, af opsætning eller af den kørende applikation. Deres styrke er, at de er gentagelige og følger med hver release.

Den britiske NCSC skriver i sin vejledning om sikker udvikling, at automatiseret sikkerhedstest giver gentagelige og skalerbare foranstaltninger, og at specialisterne så kan koncentrere sig om de subtile og usædvanlige svagheder. Det er en præcis beskrivelse af arbejdsdelingen.

Pentesten er en manuel undersøgelse af produktet på et bestemt tidspunkt. Testeren bruger viden om produktets formål, roller og forretningslogik til at finde svagheder, som en kontrol uden den viden ikke kan se: at en bruger kan godkende sin egen anmodning, at en invitation kan bruges til at komme ind hos en anden kunde, eller at en arbejdsgang kan springes over. → Test af adskillelsen mellem kunderne

Hvad kunden kan få dokumenteret af de automatiske test

De automatiske test giver ikke nødvendigvis en rapport, kunden kan læse. Til gengæld kan de give en beskrivelse af en proces, der kører hele tiden:

Hvad der kontrolleres · på et overordnet niveau, fx kode, komponenter og opsætning.
Hvornår · ved hver ændring, hver release eller efter en fast plan.
Hvad der sker ved et fund · om ændringen stoppes, eller om fundet registreres og prioriteres.
Hvem der følger op · den rolle, der har ansvaret for at håndtere fundene.

En kunde i en leverandørvurdering kan spørge til sikker udvikling som et emne for sig, og her hører de automatiske test hjemme. → Sikker udvikling i skemaet

Hvad kunden kan få dokumenteret af pentesten

Pentesten giver et dokument med en dato, et omfang, en metode og fund. Det er det, kunderne beder om, når de skriver, at de vil se jeres pentestrapport. Rapporten viser, at en uafhængig person har undersøgt produktet, og hvad der blev fundet, og en retest viser, hvad der er rettet.

NCSC beskriver pentesten som en måde at få sikkerhed for, at jeres løbende arbejde med sårbarheder virker. Det passer godt til et softwarehus med en moden pipeline: pentesten kontrollerer, om de automatiske kontroller og den øvrige udvikling har fanget det, de skulle. Finder testeren mange fund af en type, de automatiske test burde have fanget, er det i sig selv en oplysning, I kan bruge. → Fundene som læring for udviklerne

Når kunden blander de to sammen

Nogle kunder spørger, om I laver penetrationstest, og får et svar om automatisk scanning ved hver release. Andre spørger til sikker udvikling og får pentestrapporten. Begge dele giver forvirring, og forvirringen kan blive opdaget af kundens rådgiver, som så stiller opfølgende spørgsmål.

Hold dem adskilt i svaret. Pentesten beskrives med dato, omfang og testerens uafhængighed. De automatiske test beskrives som en del af udviklingsprocessen. Kalder I de automatiske test for løbende pentest, risikerer I at love noget, kunden opfatter som en manuel test, og det kan være svært at forsvare, hvis kunden senere beder om at se resultatet. → Scanning og pentest i samme spørgsmål

Penetrationtest.dk beskriver forskellen mellem automatisk og manuel test fra køberens side, når et tilbud skal vurderes: penetrationtest.dk.

Pipelinen kan gøre pentesten bedre

En moden pipeline ændrer, hvad pentesten skal bruge tiden på. Når de enkle, kendte fejltyper fanges i udviklingen, kan testeren bruge mere af tiden på det, der kræver forståelse af produktet: roller, adskillelsen mellem kunderne og forretningslogik. Fortæl testeren, hvilke kontroller I har i pipelinen, så testen kan tilrettelægges derefter. → Hvad skal med i testen af et SaaS-produkt

Pipelinen kan også bære rettelserne videre. Når et fund fra pentesten er rettet, kan en automatisk test, der kontrollerer rettelsen, lægges ind i pipelinen, så fejlen ikke kommer tilbage i en senere release. NIST’s ramme for sikker softwareudvikling, SSDF, nævner både automatisk sårbarhedstest i projektets testsamling og pentest i scenarier med høj risiko som eksempler på test af den kørende kode.

Et tænkt eksempel

Et softwarehus med et system til tidsregistrering har automatiske kontroller af kode og komponenter ved hver ændring og en årlig pentest. I kundens spørgeskema er der et spørgsmål om penetrationstest og et om sikker udvikling. Svaret på det første nævner den seneste pentest, dens dato, omfang og retest. Svaret på det andet beskriver de automatiske kontroller, hvornår de kører, og hvad der sker med fund. Kunden kan se, at der er to lag, og at de ikke er det samme. Da kundens rådgiver bagefter spørger, om de automatiske kontroller fandt de fund, pentesten rapporterede, kan softwarehuset svare ærligt: to af fundene burde have været fanget og er nu lagt ind som kontroller, mens resten handlede om rettigheder i en godkendelsesgang, som ingen automatisk kontrol kendte til.

Det skal I lade være med

Kalde de automatiske test for pentest · kunden forventer en manuel undersøgelse.
Droppe pentesten, fordi pipelinen er moden · den finder ikke fejl i forretningslogikken.
Give kunden rå resultater fra de automatiske test · de er skrevet til udviklerne, ikke til kunden.
Skjule pipelinen for testeren · testen bliver bedre, når testeren ved, hvad der allerede kontrolleres.
Lade fund fra pentesten blive ved rettelsen · læg en kontrol ind, der fanger fejlen næste gang.

Hvad kan og ikke kan konkluderes

De automatiske test viser, at bestemte kontroller kører ved hver ændring. De viser ikke, at produktet er uden svagheder i logik og adgang. Pentesten viser, hvad testeren fandt i produktet i testperioden. Den siger ikke noget om de ændringer, der kom bagefter, men den kan sige noget om, hvor godt det løbende arbejde virkede op til testen.

Tjekliste til svaret

☐ Er pentesten og de automatiske test beskrevet hver for sig?
☐ Kan I forklare, hvornår de automatiske test kører, og hvad der sker med fund?
☐ Har testeren fået en oversigt over kontrollerne i pipelinen?
☐ Lægges der en automatisk kontrol ind efter rettede pentestfund?
☐ Bruges ordet pentest kun om den manuelle test?

Kilder

NCSC (UK): Secure development and deployment guidance, princip 7: automatiseret sikkerhedstest giver gentagelige og skalerbare foranstaltninger, og specialisterne kan koncentrere sig om subtile og usædvanlige svagheder.
NCSC (UK): Penetration testing: pentest som en måde at få sikkerhed for, at arbejdet med sårbarheder virker.
NIST SP 800-218, Secure Software Development Framework, PW.8.2, eksempel 2 og 6: automatisk sårbarhedstest i testsamlingen og pentest i scenarier med høj risiko.

Senest gennemgået: oktober 2026.