Fundene som læring for udviklerne

Et fund i pentestrapporten kan lukkes med én rettelse, men den samme slags fejl kan dukke op igen et andet sted i koden ved næste test. Om det sker, afhænger af, om udviklingsteamet kun retter det konkrete fund, eller også spørger, hvorfor fejlen opstod. Den anden vej kræver lidt mere arbejde, men den giver færre gengangere og bedre svar til kunderne.

For et softwarehus er det ikke kun et internt kvalitetsspørgsmål. Kunderne læser rapporterne år for år, og de stiller spørgsmål om sikker udvikling i deres skemaer. En rapport, hvor de samme fejltyper går igen, siger noget om processen bag produktet.

Det konkrete fund og fejltypen

Hvert fund i en rapport har to lag. Det ene er den konkrete svaghed: et bestemt sted i produktet, hvor noget kan misbruges. Det andet er fejltypen: den slags fejl, som førte til svagheden, og som kan findes andre steder.

Rettes kun det konkrete sted, er fundet lukket, og retesten kan bekræfte det. Men fejltypen kan stadig findes i kode, testeren aldrig nåede, eller i kode, der bliver skrevet næste måned. NCSC skriver i sin vejledning om penetrationstest, at testen skal give udviklerne tilbagemelding om deres kodepraksis. Det er den del, der går tabt, hvis fundene kun behandles som opgaver i backloggen. → Fund i backloggen

Fra rettelse til grundårsag

NIST beskriver i sit rammeværk for sikker softwareudvikling (SSDF) en række trin, der passer godt til et softwarehus: analysér sårbarheder for at finde grundårsagen, se efter mønstre over tid, gennemgå softwaren for lignende sårbarheder, og ret udviklingsprocessen, så årsagen ikke gentager sig.

Omsat til hverdagen kan det være spørgsmål som:

Hvorfor opstod fejlen? · manglende viden, et uklart krav, en genvej under tidspres eller en fælles komponent, der bruges forkert.
Hvor kan den samme fejl ellers findes? · andre moduler, der er bygget på samme måde eller af samme team.
Hvad ville have fanget den tidligere? · et krav i specifikationen, et punkt i kodegennemgangen eller en automatisk kontrol.
Hvad ændrer vi? · en fælles løsning, et nyt krav eller et kort oplæg for teamet.

Spørgsmålene kan tages på et kort møde, når rapporten er gennemgået, og svarene kan skrives et sted, hvor udviklerne kan finde dem igen.

Mønstre over flere rapporter

En enkelt rapport siger ikke meget om mønstre. To eller tre rapporter efter hinanden gør. Læs dem side om side og se efter fejltyper, der går igen: adgangskontrol, der ikke tjekkes ens alle steder, data fra brugeren, der behandles forskelligt, eller indstillinger, der er forskellige mellem miljøerne.

Når et mønster er fundet, kan det være et tegn på, at kravene eller de fælles løsninger mangler noget, og ikke på, at en enkelt udvikler har sjusket. → Sikkerhedskrav i kravspecifikationen

Mønstrene er også nyttige før næste test. Fortæl testeren, hvilke fejltyper I har arbejdet med, og spørg, om de er værd at se ekstra efter. Det gør det lettere at vise kunderne, at en tidligere svaghed ikke bare er flyttet. → Udviklerne og testeren

Hvem ejer læringen

Læring af fund falder let mellem to stole. Udviklerne retter, den sikkerhedsansvarlige følger op på fristerne, og produktejeren prioriterer. Ingen af dem har nødvendigvis fået til opgave at se på årsagerne.

Gør det til en del af en rolle. I et lille softwarehus kan det være den ledende udvikler, der efter hver rapport samler teamet en time og skriver konklusionerne ned. I et større kan det være en sikkerhedsansvarlig i hvert team. Det vigtige er, at nogen har ansvaret, og at produktejeren giver plads til de ændringer, møderne fører til, også når de ikke er et fund i sig selv. → Produktejerens rolle

Tidsrummet er også værd at aftale. Læringen er lettest at tage, mens fundene er friske, og før teamet er videre i næste release.

Hvad kunderne ser

Kunder, der får rapporter fra flere år, kan selv se, om de samme fejltyper går igen. Det kan føre til spørgsmål, der er sværere at svare på end et enkelt fund: hvad har I gjort for at undgå det her fremover?

Her er et godt svar konkret. Nævn fejltypen, hvad I fandt som årsag, og hvad I har ændret i processen. Det kan også bruges i svaret på spørgsmål om sikker udvikling i et sikkerhedsspørgeskema, så længe det, I skriver, faktisk sker. → Spørgsmål om sikker udvikling

At være åben om tidligere fund er et valg, I træffer ud fra, hvem kunden er, og hvad der er aftalt om fortrolighed. → Åbenhed om tidligere fund

Den generelle side af gentagne fund, set fra en virksomhed, der køber test af egne systemer, er beskrevet på penetrationtest.dk.

Et tænkt eksempel

Et softwarehus har fået to rapporter med et års mellemrum. Begge har et fund om, at en bruger kan se oplysninger fra en anden afdeling i samme kunde. Første gang blev det rettet i ét skærmbillede. Anden gang er det et andet skærmbillede.

På mødet efter rapporten finder teamet årsagen: hver ny skærm tjekker selv brugerens rettigheder, og der er ingen fælles løsning. De beslutter at samle kontrollen ét sted, tilføjer et krav i specifikationen og gennemgår de øvrige skærme. Gennemgangen finder to skærme mere med samme svaghed, som ingen tester havde nået at se, og de bliver rettet i samme release. Næste gang en kunde spørger til fundet, kan sælgeren forklare både rettelsen og ændringen i måden, der udvikles på.

Det skal I lade være med

Lukke fundet uden at spørge hvorfor · fejltypen lever videre andre steder.
Gøre grundårsagen til et spørgsmål om skyld · så stopper ærligheden på mødet.
Læse hver rapport for sig · mønstrene viser sig først over flere test.
Skrive i skemaet, at I lærer af fundene, uden at kunne vise det · kunden kan spørge til et eksempel.
Holde læringen i ét hoved · skriv den ned, så nye udviklere også får den.
Springe mødet over, når rapporten er pæn · også små fund kan pege på en fejltype.

Hvad kan og ikke kan konkluderes

Arbejdet med grundårsager kan mindske risikoen for, at samme fejltype går igen, og det giver jer et konkret svar til kunder, der spørger til sikker udvikling. Det kan ikke garantere, at næste rapport bliver uden fund, og det erstatter ikke retesten af de konkrete rettelser.

Tjekliste til læring af fundene

☐ Er der et fast møde om årsager, når rapporten er gennemgået?
☐ Bliver fejltyperne skrevet ned et sted, udviklerne bruger?
☐ Er rapporterne fra tidligere år læst side om side?
☐ Fører mønstre til nye krav eller fælles løsninger?
☐ Ved testeren, hvilke fejltyper I har arbejdet med?
☐ Kan sælgeren give et konkret eksempel, hvis kunden spørger?

Kilder

NCSC (UK): Penetration testing: testen skal give udviklerne tilbagemelding om kodepraksis, og fundene bør bruges til at forbedre.
NIST SP 800-218, Secure Software Development Framework: praksis RV.3 om at analysere sårbarheder for grundårsager, finde mønstre, gennemgå softwaren for lignende sårbarheder og opdatere udviklingsprocessen.

Senest gennemgået: oktober 2026.