Ingen webløsning er skrevet fra bunden. Den står på en platform, bruger færdige biblioteker og har måske udvidelser fra andre end den, der leverede løsningen. Når en af de dele har en kendt svaghed og ikke er opdateret, ender den i rapporten. Fundet er let at forstå, men kan være svært at rette, fordi det er uklart, hvem der må opdatere hvad. Svaret hviler på to ting: et overblik over, hvilke komponenter løsningen består af, og en klar fordeling af, hvem der opdaterer hvilket lag. OWASP har samlet risikoen i kategorien for fejl i softwareforsyningskæden i 2025-udgaven af sin Top 10.
Lagene i en webløsning
For at fordele fundene skal IT kunne se løsningen som lag:
- Styresystem og webserver · det, løsningen kører på. Opdateres normalt af IT eller hostingudbyderen.
- Runtime og platform · det miljø, programmet afvikles i, fx en bestemt udgave af en programmeringsplatform eller en database.
- Selve løsningen · programmet, som leverandøren eller jeres egne udviklere står bag.
- Biblioteker i løsningen · færdige dele, som er bygget ind i programmet. De følger med løsningens udgaver.
- Udvidelser og tilføjelser · moduler fra tredjepart, som I selv har installeret oven på løsningen, fx i et indholdsstyringssystem.
- Dele, der hentes i browseren · scripts, som siden henter fra andre steder, når brugeren åbner den.
De to første lag ejer IT som regel. Biblioteker i løsningen ejer den, der bygger løsningen. Udvidelser kan være en gråzone, fordi IT har installeret dem, men ikke har skrevet dem. Scripts, der hentes i browseren, kan ligge uden for alles opmærksomhed, fordi de ikke findes på jeres egne servere.
Hvad testen afprøver, og hvad fundet betyder
En test ser, hvilke komponenter og udgaver løsningen afslører, og sammenligner med offentligt kendte svagheder. Kendte svagheder kan have et CVE-nummer, som gør det muligt at slå op, hvad svagheden går ud på, og om der findes en rettelse.
Et fund om en forældet komponent betyder ikke automatisk, at svagheden kan udnyttes i jeres løsning. Den kan sidde i en del, løsningen ikke bruger, eller være beskyttet på anden vis. Omvendt kan en enkelt forældet komponent være den vigtigste linje i rapporten. Rapporten bør skelne mellem det, testeren har påvist, og det, der er udledt af et versionsnummer. Spørg, hvis den ikke gør. → Versionsoplysninger og fejlmeddelelser
Hvem opdaterer hvad
Fordel fundene efter lag, og skriv ejeren på hvert fund:
- Platform og server · IT opdaterer i den normale vedligeholdelse, eller hostingudbyderen efter aftalen.
- Udvidelser, I har installeret · IT opdaterer eller fjerner, men spørg løsningens leverandør, om den nye udgave understøttes.
- Biblioteker i løsningen · leverandøren eller udviklerne skal levere en ny udgave. IT’s opgave er at bede om den og følge op. → Webløsninger, som IT drifter
- Hele løsningen er forældet · udgaven er ikke længere understøttet af leverandøren. Så er spørgsmålet ikke en opdatering, men en opgradering eller udskiftning.
Det sidste punkt er det sværeste. Det kræver penge og tid og kan ende som en beslutning for ledelsen. → Et system, der ikke kan opdateres
Prioritering
Ikke alle forældede komponenter skal opdateres samme dag. Prioritér efter:
- Kendt udnyttelse · den amerikanske myndighed CISA fører et katalog over sårbarheder, der vides at blive udnyttet i praksis. En komponent med en svaghed på listen bør gå forrest.
- Eksponering · en løsning på internettet kommer før en intern.
- Hvad løsningen giver adgang til · persondata, betalinger eller administrative funktioner vejer tungt.
- Om svagheden er påvist · et påvist fund kommer før et udledt.
Brug rapportens alvorlighed som udgangspunkt, men justér for jeres egne forhold. → Fra fund til opgave
Mens rettelsen er undervejs
Fra fundet står i rapporten, til en ny udgave er installeret, kan der gå tid. Leverandøren skal udvikle og teste rettelsen, og I skal teste den i jeres eget miljø, før den kommer i produktion. Den periode skal ikke bare overstås. Den skal håndteres.
Spørg først, om den sårbare del kan slås fra uden at stoppe løsningen. En funktion, få bruger, kan måske undværes i nogle uger. Dernæst om adgangen kan begrænses, fx så administrationsdelen kun kan nås fra driftens net, eller så løsningen kun er tilgængelig for kendte brugere. Til sidst om overvågningen kan skærpes, så forsøg på at bruge svagheden bliver set.
Ingen af de tiltag fjerner svagheden. De gør den sværere at nå og lettere at opdage, til den rigtige rettelse er på plads. Registrér hvert tiltag med en ejer og en dato, hvor det tages op igen, så det ikke bliver en permanent løsning ved en fejl. Fundet skal stå som åbent, indtil opdateringen er installeret og kontrolleret. → Midlertidige afhjælpninger
Overblik, der holder mellem testene
En test finder forældede komponenter på testtidspunktet. Nye svagheder bliver kendt hver uge. OWASP anbefaler en løbende oversigt over komponenter og udgaver, også de indirekte, og at følge med i kendte svagheder i de dele, I bruger. For IT-afdelingen betyder det i praksis:
- En komponentliste pr. løsning · bed leverandøren om en oversigt over de dele, løsningen består af. Den kaldes ofte en softwarestykliste.
- Abonnement på advarsler · fra leverandører og fra de myndigheder, der udsender advarsler.
- Fjern det, der ikke bruges · udvidelser og funktioner, der ikke bruges, kan ikke blive forældede.
- Løbende scanning · en sårbarhedsscanning mellem testene kan fange de mest åbenlyse udgaver. → Sårbarhedsscanning mellem testene
Overblikket over opdateringer på servere og klienter generelt er beskrevet for sig. → Opdateringsstatus
Krav til leverandøren
Mange fund i biblioteker kan kun rettes af leverandøren. Det gør aftalen vigtig. Når en aftale fornyes eller en ny løsning købes, kan I stille krav om:
- Hvor hurtigt leverandøren leverer en rettelse, når en komponent har en kendt svaghed.
- En komponentliste ved hver ny udgave.
- Hvor længe den aktuelle udgave understøttes.
Kravene skal stilles i aftalen. Leverandøren har ingen pligt til at levere det, der ikke er aftalt.
Det skal I lade være med
- At opdatere en udvidelse uden at spørge leverandøren af løsningen. Det kan bryde funktioner.
- At afvise fundet, fordi testeren ikke påviste en udnyttelse. Kendte svagheder kan udnyttes af andre senere.
- At vente på næste test for at se, om det er rettet. Brug jeres egen scanning.
- At beholde udvidelser, ingen bruger. Fjern dem.
- At lade et forældet system stå uden en registreret beslutning. Nogen skal have taget stilling.
Hvad kan og ikke kan konkluderes
Testen viser, hvilke forældede komponenter testeren kunne identificere fra sit udgangspunkt på testtidspunktet, og i nogle tilfælde, om en kendt svaghed kunne udnyttes. Den kan ikke se alle biblioteker inde i løsningen, og den kan ikke forudsige, hvilke svagheder der bliver kendt i morgen.
Kilder
- OWASP Top 10:2025 A03 Software Supply Chain Failures: forældede og ikke understøttede komponenter, oversigt over komponenter og udgaver, fjernelse af ubrugte dele og overvågning af kendte svagheder.
- CVE: det offentlige register over kendte sårbarheder med identifikationsnumre.
- CISA: Known Exploited Vulnerabilities Catalog: CISA’s katalog over sårbarheder, der vides at blive udnyttet.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Et system, der ikke kan opdateres · Leverandøren advarer om en kritisk sårbarhed
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
