Et fund ligger ikke altid i noget, virksomheden selv har bygget. Det kan lige så vel sidde i et standardsystem, en platform eller en udvidelse fra en leverandør. I kan ikke selv rette koden, og alligevel er det jeres systemer, der er udsatte. Håndteringen hviler på to spørgsmål: er svagheden allerede kendt og rettet af producenten, og hvad kan I gøre, indtil en rettelse er på plads.
Svaret er derfor en kombination af tre spor: opdatering, når producenten har en rettelse, dialog med leverandøren, når der ikke er en, og midlertidige tiltag, der mindsker risikoen i mellemtiden.
Hvor svagheden sidder
Begynd med at afklare, om fundet skyldes selve produktet eller den måde, det er sat op og brugt på hos jer. Et fund i webshoppen kan ligge i platformens kode, i en udvidelse, I har installeret, eller i en indstilling, der er valgt ved opsætningen. Kun det første og andet er egentlige fejl i tredjepartssoftware.
Hvis fundet skyldes opsætningen, er det jer eller jeres driftsleverandør, der kan rette det. Hvis det skyldes produktet, skal producenten ind i billedet. Rapporten og testeren kan ofte hjælpe med at skelne. Spørg, hvis rapporten ikke gør det tydeligt. → Hvem retter fundene?
Kendt svaghed med en rettelse
Et fund i standardsoftware kan handle om en kendt sårbarhed, som producenten allerede har rettet i en nyere version. Den har i så fald ofte et CVE-nummer, som gør det muligt at finde producentens egen beskrivelse og vejledning. → CVE forklaret
Her er opgaven i princippet enkel: opdater. I praksis kan det kræve test af opdateringen, koordinering med driftsleverandøren og et vindue, hvor systemet kan tages ned. Placer opgaven i handlingsplanen med en ejer og en frist, som alle andre fund. Kontrollér bagefter, at den nye version faktisk er i drift på de systemer, testen omfattede. En opdatering, der kun er installeret i testmiljøet, retter ikke fundet i webshoppen.
Hvis fundet viser, at opdateringer generelt ikke bliver installeret, er der et større spørgsmål end det enkelte fund. Det handler om jeres proces for opdateringer, og den bør have sin egen opgave. → Opdateringer og penetrationstest
Når opdateringen ikke kan installeres
Nogle gange kan rettelsen ikke installeres med det samme. Den nye version kan kræve en ny licens, være uforenelig med en integration til ERP-systemet eller ændre funktioner, som forretningen er afhængig af. Det er en reel begrænsning, men den bør behandles som en beslutning og ikke som en grund til at lade fundet ligge.
Skriv i handlingsplanen, hvorfor opdateringen ikke kan installeres, hvad der skal til for at gøre det, og hvornår sagen tages op igen. Imens bør I overveje midlertidige tiltag. Hvis systemet ikke længere får rettelser fra producenten, er det et tegn på, at udskiftning bør vurderes. Den vurdering hører hos ledelsen, fordi den ofte handler om tid og økonomi mere end om teknik.
Ukendt svaghed i produktet
Testeren kan også finde en svaghed i produktet, som producenten ikke kender. Så findes der ingen rettelse, og I er i en anden situation. Svagheden skal meddeles producenten, så den kan blive rettet, og det skal ske på en måde, der ikke spreder viden om den, før en rettelse er klar. → Zero-day: hvad en ukendt sårbarhed betyder for jeres test
Aftal, hvem der kontakter producenten. Det kan være jer, jeres leverandør eller testeren. Det vigtige er, at det sker sagligt og fortroligt, og at I ved, hvad der er sendt, og hvornår. Producenten bør få de oplysninger, der skal til for at genskabe og rette fejlen, men rapporten med jeres øvrige fund hører ikke med. → Deling af pentestrapporten
Bed producenten om en forventet tidsplan for en rettelse. Svaret afgør, hvor længe I skal leve med midlertidige tiltag. Hvis svagheden senere får et CVE-nummer, kan det bruges til at følge sagen. Notér datoen for henvendelsen og producentens svar, så I kan dokumentere forløbet, hvis en kunde eller revisor senere spørger, hvorfor fundet stod åbent.
Midlertidige tiltag
Indtil en rettelse er installeret, kan risikoen ofte mindskes ved at begrænse, hvem og hvad der kan nå den sårbare del. Hvilke tiltag der passer, afhænger af systemet og af fundet, og testeren eller leverandøren bør rådgive om det konkrete valg.
- Begræns adgangen · gør funktionen tilgængelig for færre brugere eller kun fra bestemte net.
- Slå funktionen fra · hvis den ikke er nødvendig, kan den måske deaktiveres, til en rettelse findes.
- Øg opmærksomheden · bed driftsleverandøren eller jeres overvågning holde øje med det berørte system.
- Fjern udvidelsen · en udvidelse til webshoppen, som ikke bruges, kan fjernes helt.
Et midlertidigt tiltag skal have en frist og en ejer, og det skal stå i handlingsplanen ved siden af den varige løsning. Ellers bliver det midlertidige let permanent. → Plugins og tredjepartskode
Leverandørens og producentens rolle
Leverandøren, der har solgt eller driver systemet, er ikke altid den samme som producenten. En driftsleverandør kan installere opdateringer, men kan ikke rette en fejl i produktets kode. Afklar, hvem der gør hvad, og hvad aftalen siger om opdateringer og sikkerhedsrettelser.
Hvis leverandøren afviser, at fundet er en fejl, eller ikke vil påtage sig opgaven, må sagen afklares særskilt. → Når leverandøren afviser et fund
Det skal I lade være med
- At antage, at producenten allerede ved det · Tjek, om svagheden er kendt, og meld den, hvis den ikke er.
- At udskyde opdateringen uden begrundelse · En udskydelse er en beslutning, der skal stå i planen.
- At sende hele rapporten til producenten · Producenten skal kun have det, der vedrører produktet.
- At glemme de midlertidige tiltag · De skal have frist og ejer.
- At offentliggøre en ukendt svaghed · Viden om den bør holdes fortrolig, til en rettelse findes.
- At overse udvidelser, der ikke bruges · De kan fjernes i stedet for at blive rettet.
Hvad kan og ikke kan konkluderes
En test kan vise, at en svaghed i tredjepartssoftware findes i jeres installation, og hvad den kan betyde for jer. Sammen med producentens oplysninger kan det give et grundlag for at vælge mellem opdatering, midlertidige tiltag og udskiftning.
Testen kan ikke sige, hvornår producenten retter en ukendt svaghed, eller om andre svagheder findes i produktet. Den kan heller ikke garantere, at et midlertidigt tiltag dækker alle måder, svagheden kan udnyttes på.
Tjekliste ved fund i tredjepartssoftware
- ☐ Er det afklaret, om fundet skyldes produktet eller opsætningen?
- ☐ Er det undersøgt, om svagheden er kendt og rettet?
- ☐ Er opdateringen placeret i handlingsplanen med ejer og frist?
- ☐ Er en ukendt svaghed meldt fortroligt til producenten?
- ☐ Er midlertidige tiltag valgt og givet en frist?
- ☐ Er rollerne mellem leverandør og producent afklaret?
Kilder
- CVE: programmet, der giver offentligt kendte sårbarheder et fælles nummer, så producentens beskrivelse kan findes.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Frister for rettelser · Fra rapport til handlingsplan
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
