Sårbarheder i afhængigheder mellem to test

Pentestrapporten beskriver produktet, som det så ud på testdagen, men bibliotekerne i produktet bliver ved med at få nye kendte sårbarheder bagefter. Svaret på, hvad I gør i mellemtiden, hviler på jeres egen proces og ikke på rapporten: I skal opdage den nye sårbarhed, vurdere, om den rammer jer, rette den, og kunne forklare kunderne, hvad I har gjort.

Rapporten mister ikke sin værdi, fordi et bibliotek får en ny sårbarhed. Men den kan ikke stå alene som svar, når kunden spørger, om produktet stadig er i orden.

Det, der ændrer sig efter testdagen

Et SaaS-produkt består af jeres egen kode og en lang række komponenter, som andre har skrevet: rammeværk, biblioteker, og de biblioteker, som bibliotekerne selv trækker med ind. Mange af dem bliver opdateret hyppigt, og nye sårbarheder bliver offentliggjort løbende med et nummer i CVE-systemet.

OWASP har i sin Top 10 en kategori for fejl i softwareforsyningskæden. Her nævnes det som en risiko, hvis man ikke holder styr på versionerne af alle komponenter, herunder de indirekte, og hvis man ikke jævnligt holder øje med nye sårbarheder i dem. Det er netop den del, der foregår mellem to test. → Open source og tredjepartskomponenter

Rapporten og den nye sårbarhed

Når en sårbarhed bliver kendt i et bibliotek, I bruger, opstår der to spørgsmål, som skal holdes adskilt:

Er I berørt? · bruger produktet den sårbare version, og bruges den del af biblioteket, som sårbarheden sidder i?
Holder rapporten stadig? · fundene i rapporten er ikke blevet forkerte, men rapporten kunne ikke kende til sårbarheden.

Det første spørgsmål besvarer I selv. Det andet er et spørgsmål om, hvad kunden må læse ud af rapporten. Rapportens dato er her jeres ven: den viser, at testen er et billede af et bestemt tidspunkt. Ændringer siden da skal dokumenteres på anden vis. → Ændringer siden testen

NIST anbefaler i sit rammeværk for sikker softwareudvikling (SSDF), at producenter løbende indsamler oplysninger om mulige sårbarheder i egen software og i de tredjepartskomponenter, den bruger, og undersøger alle troværdige rapporter. Det er en praksis, ikke en enkeltstående test.

Hvad kunderne forventer at høre

Når en sårbarhed i en udbredt komponent kommer i nyhederne, vil nogle kunder spørge samme dag. De forventer ikke en ny pentest. De forventer et kort, præcist svar: om I er ramt, hvad I har gjort, og hvornår det er rettet. → Kunden spørger efter en kendt sårbarhed

Det svar bliver bedre af at være forberedt. Aftal, hvem der vurderer nye sårbarheder, hvem der godkender teksten til kunderne, og hvor den bliver lagt, så alle kunder får det samme at vide. For alvorlige tilfælde kan en kort meddelelse til alle kunder være bedre end at besvare spørgsmål ét ad gangen. → Sikkerhedsmeddelelse til kunderne

Har I lovet i en kontrakt at underrette kunder om sårbarheder, styrer den aftale, hvad og hvornår I skal fortælle. → Underretning om sårbarheder

Hvornår en ny sårbarhed kræver mere end en opdatering

En ny sårbarhed i en afhængighed kan løses ved at opdatere komponenten, teste, at produktet stadig virker, og rulle ud. Nogle gange er det ikke nok. Det kan være, hvis komponenten ikke længere vedligeholdes, hvis opdateringen ændrer noget grundlæggende, eller hvis sårbarheden sad et sted, hvor der kan have været adgang til kundedata.

I de tilfælde kan det være rimeligt at få ændringen afprøvet af en tester, før den næste planlagte test. Det er en vurdering, I træffer ud fra, hvor stor ændringen er, og hvad den berører. → Ændringer, der kræver en ny test

Er produktet omfattet af Cyber Resilience Act, stiller forordningen krav til fabrikanter om at håndtere og afhjælpe sårbarheder, herunder i komponenter, og om regelmæssig afprøvning af sikkerheden. Om og hvordan forordningen gælder for jeres produkt, skal vurderes for sig. → Cyber Resilience Act

Pipelinen og pentesten fordeler arbejdet

Automatiske kontroller i udviklingen kan holde øje med kendte sårbarheder i komponenterne hver gang, der bygges. Pentesten ser på, om svagheder kan udnyttes i den sammenhæng, produktet faktisk kører i. De to supplerer hinanden, og kunderne spørger efter begge dele i deres skemaer. → Pipelinen og pentesten

Hvordan en virksomhed, der bruger standardsystemer, håndterer fund i andres software, er beskrevet fra køberens side på penetrationtest.dk.

Et tænkt eksempel

Et softwarehus fik sin årlige pentest i foråret, og rapporten havde ingen alvorlige fund. Om efteråret bliver der offentliggjort en alvorlig sårbarhed i et udbredt bibliotek til behandling af dokumenter. Produktet bruger ikke biblioteket direkte, men en af de komponenter, produktet bygger på, trækker det med ind.

To kunder skriver samme formiddag og spørger, om de er ramt. Den ene har læst om sagen i fagpressen, den anden har fået spørgsmålet fra sin egen ledelse. Fordi softwarehuset har en opdateret oversigt over komponenter, kan udviklerne hurtigt se, at den sårbare version er med. De vurderer, at den del af biblioteket ikke bruges af produktet, men opdaterer alligevel.

Kunderne får samme korte svar: hvad der blev undersøgt, hvad konklusionen var, og hvornår opdateringen var rullet ud. Ingen af dem beder om en ny rapport, men begge noterer, at svaret kom samme dag og var konkret. Forårets rapport bliver ikke brugt som argument, for den kunne ikke vide noget om sagen.

Det skal I lade være med

Bruge rapporten som bevis for, at en ny sårbarhed ikke rammer jer · rapporten kunne ikke kende til den.
Vente med at svare, til næste test · kunden forventer et svar om den konkrete sårbarhed nu.
Svare hver kunde forskelligt · én tekst, godkendt én gang, er lettere at stå på mål for.
Overse de indirekte afhængigheder · det kan være dér, sårbarheden sidder.
Opdatere uden at tjekke resten af produktet · en hastig opdatering kan selv give fejl.
Love, at produktet aldrig har sårbare komponenter · det kan ingen leverandør love.

Hvad kan og ikke kan konkluderes

Den seneste pentest kan vise, hvordan produktet stod på testdagen, herunder om kendte svagheder i komponenterne dengang kunne udnyttes. Den kan ikke sige noget om sårbarheder, der er blevet kendt siden, og den erstatter ikke jeres egen overvågning af komponenterne.

Tjekliste til tiden mellem to test

☐ Ved I, hvilke komponenter og versioner produktet bruger, også de indirekte?
☐ Er der en fast måde at opdage nye sårbarheder i dem på?
☐ Er det aftalt, hvem der vurderer, om I er berørt?
☐ Har I en godkendt tekst klar til kunder, der spørger?
☐ Kender I jeres kontraktlige pligter til at underrette?
☐ Er der en regel for, hvornår en ændring skal testes før næste planlagte test?

Kilder

OWASP Top 10:2025, A03 Software Supply Chain Failures: risiko ved manglende overblik over komponenters versioner, også indirekte afhængigheder, og ved manglende løbende overvågning af nye sårbarheder.
NIST SP 800-218, Secure Software Development Framework: praksis RV.1.1 om løbende at indsamle oplysninger om sårbarheder i softwaren og i tredjepartskomponenter.
CVE: offentlige numre for kendte sårbarheder.
Cyber Resilience Act, forordning (EU) 2024/2847: bilag I, del II, punkt 1 til 3, om softwarekomponentliste, håndtering og afhjælpning af sårbarheder og regelmæssig afprøvning af sikkerheden.

Senest gennemgået: oktober 2026.