Sikkerhedsfund i udviklingsprocessen: hvornår er en rettelse færdig?

Et udviklingsteam kan have en klar fælles forståelse af, hvornår en opgave er færdig: koden er gennemgået, testene er grønne, og ændringen er ude. For et sikkerhedsfund fra en pentest rækker det ikke. Rettelsen er først færdig, når den fjerner selve svagheden i alle de steder, den findes, når den er beskyttet mod at komme tilbage, og når den er dokumenteret, så testeren og kunderne kan se, hvad der er gjort.

Forskellen betyder noget i praksis. Et fund, der sendes til retest for tidligt, kommer tilbage som delvist rettet, og så skal kunden have endnu en status og endnu en dato.

Hvorfor den almindelige definition ikke slår til

Den almindelige definition af færdig er skrevet til funktioner. Den spørger, om det nye virker, som det skal. Et sikkerhedsfund handler om det modsatte: at noget, der ikke burde kunne lade sig gøre, ikke længere kan. Det er sværere at vise, og det er let at stoppe ved det eksempel, rapporten nævner.

Rapporten kan beskrive ét sted, hvor svagheden blev fundet, og måske et par lignende. Testeren har ikke nødvendigvis set hele produktet med samme øjne. Retter udviklerne kun det konkrete eksempel, kan den samme fejl sidde i ti andre skærmbilleder eller kald, og så er fundet ikke lukket, selvom opgaven er det. → Fund i backloggen

Kriterier for en færdig rettelse

En rettelse af et sikkerhedsfund kan have sin egen definition af færdig. Den kan bestå af fem kriterier:

Årsagen er fundet · udviklerne har forstået, hvorfor svagheden opstod, ikke kun hvor den viste sig.
Lignende steder er gennemgået · andre dele af produktet med samme mønster er undersøgt og rettet, hvis det var nødvendigt.
Rettelsen er sikret mod tilbagefald · der er tilføjet en test eller en kontrol, der fanger fejlen, hvis den kommer igen.
Rettelsen er ude · den er udrullet til de miljøer, kunderne bruger, eller til det miljø, retesten skal ske i.
Rettelsen er beskrevet · det er skrevet ned, hvad der er ændret, i hvilken version, og hvordan det kan efterprøves.

NIST’s ramme for sikker softwareudvikling, SSDF, peger i samme retning. Den anbefaler at gennemgå produktet for lignende svagheder i stedet for at vente på nye rapporter, og at lægge test for tidligere fundne svagheder ind i projektets testsamling, så fejlene ikke genopstår.

Kriterierne skal ikke gøre hver rettelse til et projekt. For et lille fund med en tydelig årsag kan de fem punkter klares på kort tid. Pointen er, at de bliver stillet hver gang, og at svaret står i opgaven. Et team, der aftaler kriterierne én gang og skriver dem ind i sin proces, slipper for at diskutere dem ved hvert fund, og kriterierne bliver noget, alle kender, og ikke noget, den sikkerhedsansvarlige skal huske at minde om.

Det tredje kriterium er det, der kan mangle

Det er fristende at stoppe, når fundet ikke længere kan genskabes. Men et produkt i løbende udvikling ændrer sig, og en senere ændring kan genåbne præcis den samme svaghed. En automatisk test, der kontrollerer, at rettelsen stadig virker, gør, at fejlen bliver opdaget i udviklingen og ikke i næste pentest.

Testen skal ikke være en kopi af testerens fremgangsmåde. Den skal kontrollere den egenskab, rettelsen indførte, fx at en bruger i én rolle ikke kan hente data fra en anden rolle. Hvordan de automatiske test spiller sammen med pentesten, er beskrevet for sig. → Pipelinen og pentesten

Hvem siger, at rettelsen er færdig?

Udvikleren, der har lavet rettelsen, er den, der bedst kan beskrive den, men ikke den, der bedst kan bedømme den. En kollega bør gennemgå rettelsen med kriterierne i hånden, og den sikkerhedsansvarlige eller produktejeren bør godkende, at fundet er klar til retest. Det giver to sæt øjne, før testeren bruger tid på det. Hvis en rettelse ikke kan opfylde alle kriterier, fx fordi den endelige løsning kræver en større ombygning, skal det fremgå af opgaven, så ingen tror, at fundet er klar til retest. → Produktejerens rolle i penetrationstesten

Færdig i udviklingen er ikke det samme som lukket over for kunden. Først når retesten har bekræftet rettelsen, kan I skrive i spørgeskemaerne, at fundet er lukket. Indtil da er det rettet og afventer efterprøvning, og det er et fuldt ud ærligt svar. → Retest efter rettelser i en ny release

Et tænkt eksempel

Et softwarehus med et system til håndtering af kontrakter får et fund om, at brugere kan se titlen på dokumenter i mapper, de ikke har adgang til, gennem søgefunktionen. Udvikleren retter søgningen. Før opgaven lukkes, gennemgår teamet de andre steder, hvor dokumenttitler vises: listen over seneste dokumenter, notifikationer og eksporten. To af dem har samme svaghed og rettes i samme omgang. Der tilføjes en automatisk test, som kontrollerer adgangen på tværs af alle fire steder.

Beskrivelsen til testeren nævner alle fire steder og den version, rettelserne er med i. Retesten bekræfter rettelsen, og kunden får et retestbevis, der dækker mere end det oprindelige eksempel. → Retestbevis til kunden

Det, kunderne får ud af det

Kunderne ser ikke jeres definition af færdig, men de ser resultatet. Færre fund, der kommer tilbage som delvist rettet, betyder kortere tid fra rapport til retestbevis. Færre fund, der genopstår, betyder færre ubehagelige gengangere i næste års rapport. Og når kunden i et spørgeskema spørger, hvordan I sikrer, at fund ikke kommer igen, har I et konkret svar. → Sikker udvikling i skemaet

Det skal I lade være med

Lukke fundet, når koden er flettet ind · fundet er først lukket efter retesten.
Rette kun rapportens eksempel · gennemgå de steder, hvor samme mønster går igen.
Springe testen mod tilbagefald over · det er den, der beskytter rettelsen i næste release.
Sende fund til retest uden beskrivelse · testeren skal vide, hvad der er ændret og hvor.
Kalde et rettet fund for lukket over for kunden · før det er efterprøvet.

Hvad kan og ikke kan konkluderes

En rettelse, der opfylder kriterierne, er klar til retest og har en bedre chance for at holde. Det er ikke et bevis for, at svagheden er væk. Det kan kun retesten give, og kun for de steder og den version, testeren efterprøvede.

Tjekliste før retest

☐ Er årsagen til fundet beskrevet?
☐ Er lignende steder i produktet gennemgået?
☐ Findes der en test, der fanger fejlen, hvis den kommer igen?
☐ Er rettelsen udrullet til det miljø, retesten sker i?
☐ Er det skrevet ned, hvad der er ændret, og i hvilken version?
☐ Har en anden end udvikleren godkendt, at fundet er klar?

Kilder

NIST SP 800-218, Secure Software Development Framework, PW.8.2, eksempel 3, og RV.3.3: test for tidligere fundne svagheder lægges ind i testsamlingen, og produktet gennemgås for lignende svagheder.

Senest gennemgået: oktober 2026.