Fund i backloggen: sådan prioriterer udviklingsteamet

Når pentestrapporten er gennemgået, skal fundene ind i det samme arbejdsflow som alt andet, udviklingsteamet laver, og der konkurrerer de med nye funktioner, kundeønsker og fejlrettelser. En prioritering, der holder, bygger på tre ting: fundets alvor i jeres produkt, hvad kunderne er blevet lovet, og en fast regel for, hvornår sikkerhedsfund går foran.

Kommer fundene ind uden en sådan regel, kan de ende nederst, fordi de ikke har en kunde, der rykker for dem. Det mærker I først, når en kunde spørger, hvad der er sket med de åbne fund fra rapporten.

Hvorfor sikkerhedsfund taber i en almindelig backlog

En backlog kan være prioriteret efter værdi for brugerne og forretningen. Nye funktioner har en tydelig værdi og en, der efterspørger dem. Et sikkerhedsfund har en værdi, der er svær at se: det forhindrer noget, der måske aldrig sker. Hvis fundene vurderes med samme målestok som funktioner, glider de ned.

Samtidig er rapportens alvorlighedsgrad ikke skrevet til en backlog. Den beskriver svagheden, ikke hvor meget arbejde rettelsen kræver, eller hvordan den passer ind i jeres releaseplan. Udviklingsteamet skal derfor oversætte rapporten til opgaver, som kan planlægges. → Sikkerhedsfund i udviklingsprocessen

Den britiske NCSC skriver, at vurderingen af risikoen og beslutningen om rettelser er jeres ansvar og ikke kan overlades helt til testeren. For et softwarehus betyder det, at prioriteringen er en produktbeslutning med kunderne i tankerne.

Fra rapport til opgaver

Det første skridt er at få hvert fund ind som en opgave, der kan genfindes. NIST’s ramme for sikker softwareudvikling, SSDF, anbefaler, at fund fra test registreres og vurderes i udviklingsteamets eget arbejdsflow eller sagssystem. Det gør fundene synlige på lige fod med anden udvikling.

Hver opgave bør have:

Henvisning til rapporten · fundets nummer og rapportens dato, så sammenhængen kan dokumenteres over for kunden.
Alvor i jeres produkt · rapportens vurdering, justeret efter hvilke kunder og data der er berørt.
En ejer · den udvikler eller det team, der skal stå for rettelsen.
En kategori · sikkerhedsfund, så de kan trækkes ud for sig og rapporteres samlet.
En forventet release · hvornår rettelsen planlægges til at være ude hos kunderne.

Kategorien er vigtig. Den gør det muligt at svare hurtigt, når en kunde spørger, hvor mange fund der stadig er åbne. → Åbne fund i spørgeskemaet

En regel, der går forud for den løbende prioritering

Den mest effektive måde at beskytte sikkerhedsfund i backloggen er at lægge en regel ud over den løbende prioritering. Reglen kan fx sige, at alvorlige fund planlægges i den næste release, at fund af middel alvor planlægges inden for en bestemt periode, og at de øvrige vurderes ved næste planlægning. Perioderne er jeres egne, og de bør passe til det, I har lovet kunderne i kontrakter og spørgeskemaer.

Reglen flytter diskussionen. I stedet for at forhandle om hvert fund med produktansvarlige skal der kun tages stilling, når et fund skal fraviges. Det kræver en begrundelse, og begrundelsen kan dokumenteres. → Rettefrister i kontrakten

Rapportens alvorlighedsgrad kan bygge på CVSS, som FIRST står bag. Grundscoren beskriver svagheden uden hensyn til jeres produkt. Brug den som startpunkt, men lad den, der kender produktet og kunderne, justere, hvor det giver mening.

Fund, der kræver mere end en rettelse

Nogle fund kan ikke lukkes med én opgave. Et svagt punkt i rollemodellen kan kræve en ændring, der berører mange dele af produktet. Så er det fristende at udskyde det hele. Bedre er det at dele fundet op: en midlertidig foranstaltning, der kan komme ud hurtigt, og en egentlig løsning, der planlægges som et projekt. Begge dele registreres, og begge kan forklares over for kunderne. → Kompenserende foranstaltninger

Et tænkt eksempel: et softwarehus med et system til kvalitetsstyring får en rapport med et alvorligt fund i eksporten, hvor brugere i én rolle kan hente mere end deres rolle tillader. Rettelsen kræver en ny model for rettigheder i eksporten. Udviklingsteamet lægger en midlertidig begrænsning i næste release og planlægger den nye model over to releases. Begge opgaver står i backloggen med henvisning til fundet, og kunderne med krav om underretning får en kort status.

Hvem der sidder med ved bordet

Prioriteringen bliver bedst, når tre perspektiver mødes kort efter, at rapporten er gennemgået. Udviklerne kender indsatsen og de tekniske sammenhænge. Produktejeren kender releaseplanen og kundernes ønsker. Den, der svarer på spørgeskemaer og taler med kunderne om sikkerhed, ved, hvad der er lovet, og hvilke kunder der venter på et svar. Mangler et af perspektiverne, bliver prioriteringen enten urealistisk, eller den rammer ved siden af det, kunderne spørger om.

Mødet behøver ikke være langt. Det skal ende med en rækkefølge, en ejer for hvert fund og en beslutning om, hvad der skal fortælles til kunderne. Gentag det, når nye fund kommer til, fx efter en afgrænset test af en ny funktion, så backloggen hele tiden afspejler den samlede status og ikke kun den seneste rapport. → Produktejerens rolle i penetrationstesten

Kundernes blik på backloggen

Kunderne ser aldrig jeres backlog, men de mærker den. De spørger, om fundene er rettet, hvornår det sker, og om der er en retest. Når fundene er registreret med ejer, kategori og forventet release, kan I svare præcist i stedet for at love noget, I ikke har planlagt. → Retestbevis til kunden

Den britiske NCSC anbefaler i sin vejledning om sikker udvikling at føre et register over sikkerhedsgæld fra opdagelse til afhjælpning. Backloggen med en fast kategori for sikkerhedsfund er netop sådan et register.

Det skal I lade være med

Prioritere fund med samme målestok som funktioner · så kan de tabe.
Lægge fundene i et dokument ved siden af backloggen · så bliver de glemt.
Love kunderne rettelser uden en plan · løftet skal kunne holdes.
Lade et fund ligge, fordi det er stort · del det op i en midlertidig og en endelig løsning.
Fjerne et fund fra backloggen uden en begrundelse · det skal kunne forklares senere.

Hvad kan og ikke kan konkluderes

En backlog med sikkerhedsfund, ejere og planlagte releases viser, at fundene er taget alvorligt og planlagt. Den viser ikke, at rettelserne virker. Det kræver en efterprøvning, og først når den er sket, kan I over for kunderne sige, at et fund er lukket.

Tjekliste til backloggen

☐ Er alle fund fra rapporten registreret som opgaver med henvisning til rapporten?
☐ Har hvert fund en ejer og en forventet release?
☐ Findes der en regel for, hvornår sikkerhedsfund går foran?
☐ Kan I trække alle åbne sikkerhedsfund ud på få minutter?
☐ Er fravigelser fra reglen begrundet og skrevet ned?

Kilder

NCSC (UK): Penetration testing: vurdering af risiko og beslutning om rettelser er virksomhedens ansvar og bør ikke overlades helt til testeren.
NCSC (UK): Secure development and deployment guidance, princip 8: hold styr på sikkerhedsgæld med et register fra opdagelse til afhjælpning.
NIST SP 800-218, Secure Software Development Framework, PW.8.2 og RV.2: fund registreres og vurderes i udviklingsteamets arbejdsflow, og der træffes en risikobaseret beslutning om hvert fund.
FIRST CVSS v4.0: grundscoren beskriver svagheden uafhængigt af det konkrete miljø.

Senest gennemgået: oktober 2026.