Spørgsmål om sikker udvikling og kodegennemgang

Ud over spørgsmålet om pentest kan et sikkerhedsspørgeskema indeholde en række spørgsmål om, hvordan produktet bliver udviklet. Kunden vil vide, om sikkerhed er en del af arbejdet hele vejen, ikke kun ved den årlige test. Et godt svar hviler på en beskrivelse af jeres faktiske proces, med de trin I rent faktisk følger, og de spor, der viser, at I følger dem.

Svaret er derfor en beskrivelse af processen på begrebsniveau: hvordan krav stilles, hvordan kode gennemgås, hvilke automatiske kontroller der kører, og hvordan fund håndteres. Pentesten er en del af billedet, men den svarer ikke alene på spørgsmål om udviklingen.

Hvad kunden kan spørge om

Spørgsmålene varierer, men de kan samles i nogle få grupper:

Proces · har I en beskrevet proces for sikker udvikling, og følger I en kendt ramme?
Kodegennemgang · bliver ændringer gennemgået af en anden udvikler, før de udrulles?
Automatiske kontroller · scanner I kode og afhængigheder?
Adskillelse af miljøer · er udvikling, test og produktion adskilt?
Uddannelse · får udviklerne viden om sikker udvikling?
Håndtering af fund · hvordan bliver svagheder fra test og scanning prioriteret og rettet?

Det er en god idé at have et svar klar til hver gruppe, så I ikke skal skrive det forfra til hver kunde. Spørgsmålene om uddannelse og adskillelse af miljøer kan blive besvaret for hurtigt, fordi de lyder enkle. Kunden vil dog gerne vide, hvad uddannelsen består i, og hvor ofte den gentages, og hvem der kan flytte kode og data mellem miljøerne. Svar konkret på begge dele. → Et svarbibliotek

Rammer, kunden kan kende

Nogle kunder spørger, om jeres proces følger en anerkendt ramme. En af dem er NIST’s Secure Software Development Framework, SP 800-218. Udgiveren beskriver den som et sæt overordnede praksisser for sikker softwareudvikling, der kan indarbejdes i den udviklingsmodel, en organisation allerede bruger. Den er også tænkt som et fælles sprog mellem dem, der køber software, og dem, der leverer det.

I behøver ikke følge en bestemt ramme for at svare godt. Men hvis I har valgt at bruge en, så sig hvilken, og hvor langt I er. Påstå ikke, at I følger en ramme fuldt ud, hvis I kun har brugt den som inspiration. Kundens sikkerhedsfolk kan spørge ind til konkrete dele af den. → OWASP ASVS

Beskriv det, I faktisk gør

Det mest almindelige problem i svar om udvikling er, at de beskriver en ideel proces frem for den, teamet følger. Et svar som “alle ændringer gennemgås af en sikkerhedsekspert” holder sjældent i et lille team. Et svar som “alle ændringer gennemgås af en anden udvikler, før de flettes ind, og gennemgangen registreres i versionsstyringen” er både mere præcist og lettere at dokumentere.

Vær også præcis om, hvornår processen blev indført. Hvis kodegennemgang først er blevet fast praksis for nylig, er der dele af produktet, som aldrig er gennemgået på den måde. Det er ikke nødvendigvis et problem, men det er en oplysning, kunden kan have brug for, hvis spørgsmålet gælder hele kodebasen. Et svar som “fast praksis siden foråret, ældre kode gennemgås, når den ændres” er ærligt og let at forstå.

Spørg udviklingsteamet, hvordan arbejdet faktisk foregår, før I svarer. Det gælder især for de dele, der lyder selvfølgelige, som adskillelse af miljøer og adgang til produktion. Hvis der er undtagelser, fx at en enkelt udvikler har adgang til produktion i nødsituationer, så skriv det, og forklar, hvordan adgangen er styret.

Kodegennemgang og pentest i samme svar

Nogle skemaer spørger, om der laves sikkerhedsgennemgang af koden. Her er det vigtigt at skelne mellem tre ting, der let blandes sammen:

Den daglige gennemgang · udviklernes gennemgang af hinandens ændringer.
Automatisk analyse af kode · værktøjer i pipelinen, der leder efter kendte mønstre.
En særskilt sikkerhedsgennemgang af koden · udført af en specialist, internt eller eksternt.

Den daglige gennemgang er værdifuld, men den er ikke det samme som en sikkerhedsgennemgang. Hvis kunden spørger til den tredje, og I kun har de to første, så sig det. Pentesten er en fjerde ting: en afprøvning af det kørende produkt udefra eller med login. Den kan ske med adgang til koden, men det er ikke en kodegennemgang. → Kodegennemgang eller penetrationstest · → Automatiske sikkerhedstest i pipelinen

Spor, der viser processen

Kunden kan bede om dokumentation. Det behøver ikke være et stort dokument. Mange af de spor, der viser en proces, findes allerede i jeres værktøjer:

En kort procesbeskrivelse · en side om, hvordan sikkerhed indgår i udviklingen.
Registrerede gennemgange · versionsstyringens historik viser, hvem der godkendte hvad.
Resultater fra automatiske kontroller · oversigter over fund og deres status.
Sager i backloggen · sikkerhedsfund med prioritet og ejer.
Seneste pentest · erklæring eller resumé, der viser, at processen er efterprøvet udefra.

Del ikke skærmbilleder af kode eller interne sager i skemaet. Henvis til, at sporene kan vises på et møde. → Fund i backloggen

Et tænkt eksempel

En leverandør af et system til lagerstyring får fire spørgsmål om udvikling. Svarene bliver korte og konkrete: der findes en beskrevet proces, der er inspireret af SSDF, men ikke fuldt implementeret; alle ændringer gennemgås af en anden udvikler, og det registreres; afhængigheder scannes automatisk ved hver udrulning; der er ingen særskilt sikkerhedsgennemgang af koden, men produktet testes årligt af en ekstern tester med adgang til dokumentation. Kunden kan se, hvad der er på plads, og hvad der ikke er.

Det skal I lade være med

Beskrive en ideel proces · Kunden spørger, hvad I gør, ikke hvad I gerne vil.
Kalde den daglige gennemgang for en sikkerhedsgennemgang · De er ikke det samme.
Påstå at følge en ramme fuldt ud · Sig, hvor langt I er.
Lade sælgeren skrive svarene alene · Udviklerne skal godkende dem.
Dele kode eller interne sager i skemaet · Vis dem på et møde, hvis det er nødvendigt.

Hvad kan og ikke kan konkluderes

Et præcist svar om udvikling viser kunden, hvordan sikkerhed indgår i det daglige arbejde, og hvilke kontroller der fanger fejl, før de når produktionen. Det siger ikke, at produktet er uden svagheder. En pentest kan efterprøve, om processen har virket for den version, der blev testet, men den kan ikke dokumentere processen i sig selv.

Tjekliste til spørgsmål om udvikling

☐ Er svarene skrevet eller godkendt af udviklingsteamet?
☐ Beskriver svarene den proces, I faktisk følger?
☐ Er det klart, om I bruger en ramme, og hvor langt I er?
☐ Er den daglige gennemgang adskilt fra en særskilt sikkerhedsgennemgang?
☐ Ved I, hvilke spor I kan vise, hvis kunden beder om dokumentation?
☐ Er undtagelser, fx adgang til produktion, beskrevet åbent?

Kilder

NIST SP 800-218: Secure Software Development Framework (SSDF) version 1.1: overordnede praksisser for sikker udvikling, som kan indarbejdes i den eksisterende udviklingsmodel, og et fælles sprog for købere og leverandører.

Senest gennemgået: oktober 2026.