Kundeportalen, bookingsystemet, intranettet og webdelen af ERP-systemet kan være købt hos en leverandør, men installeret og drevet af IT-afdelingen. Når sådan en løsning bliver testet, kommer der fund, som IT kan rette selv, og fund, som kun leverandøren kan rette. Det afgørende spørgsmål efter testen er derfor ikke kun, hvor alvorligt et fund er, men hvem der ejer det. Svaret hviler på en enkel skillelinje: fejl i koden ligger hos den, der har skrevet den, og fejl i installationen, opsætningen og omgivelserne ligger hos den, der drifter. Det er den skillelinje, IT-afdelingen skal have på plads, før rapporten kommer.
Tre slags fund i samme rapport
Fundene i en test af en købt webløsning kan falde i tre grupper:
- Fund i koden · svagheder i selve programmet, fx i hvordan det kontrollerer adgang eller behandler indtastninger. Dem kan kun leverandøren rette.
- Fund i opsætningen af programmet · indstillinger i løsningen, som I har valgt eller ikke har ændret, fx standardkonti, roller eller funktioner, der er slået til uden at blive brugt.
- Fund i omgivelserne · webserveren, styresystemet, forbindelsen, certifikater og de komponenter, som installationen bygger på. → Webserverens opsætning
De to sidste grupper er IT’s. De kan udgøre en stor del af rapporten, og mange af dem kan rettes uden at involvere leverandøren. Den første gruppe kræver en henvendelse og en aftale.
Hvad IT-afdelingen forbereder
En god test af en købt løsning kræver, at testeren kender grænsen mellem kode og drift. Det er IT, der kan tegne den:
- Hvem leverede hvad · hvilken udgave af løsningen der kører, hvem der har installeret den, og hvilke tilpasninger der er lavet.
- Leverandørens kontakt · hvem hos leverandøren der skal orienteres om testen og modtage fund i koden.
- Leverandørens regler · om aftalen med leverandøren siger noget om test af løsningen. Nogle aftaler kræver varsel.
- Miljøet · om testen skal ske i produktion eller i et testmiljø, der ligner. → Testmiljø til webtesten
- Brugere og roller · testkonti med de roller, løsningen har, så adgangskontrollen kan afprøves mellem dem.
Køberens valg af afgrænsning og testtype ved webtest er forklaret på penetrationtest.dk. Her handler det om, hvad driften skal have klar.
Fund i opsætning og omgivelser: dem retter I selv
Mange fund i en købt løsning handler slet ikke om koden. Typiske eksempler:
- Forældede komponenter · webserver, programmeringsplatform eller biblioteker, som installationen bygger på, er ikke opdateret. → Forældede komponenter og biblioteker
- Standardindstillinger · administrationssider, eksempelfiler eller testkonti, der fulgte med installationen og aldrig blev fjernet.
- Roller i løsningen · brugere med flere rettigheder end opgaven kræver, fordi rollerne ikke er tilpasset. → Roller og rettigheder i forretningssystemer
- Krypteret forbindelse · gamle protokoller eller certifikater med svagheder.
- Fejlmeddelelser og versionsoplysninger · løsningen fortæller mere om sig selv, end nødvendigt.
De rettes som anden drift: i den normale ændringsproces, med test før og en vej tilbage. Hvis en rettelse kan påvirke løsningens funktion, så spørg leverandøren, om den understøttes, før I gennemfører den.
Fund i koden: leverandørens opgave, jeres opfølgning
Når en svaghed sidder i selve programmet, er det leverandøren, der skal rette. IT’s opgave er at sørge for, at det sker:
- Send fundet videre · med den dokumentation fra rapporten, der er nødvendig, og intet mere end nødvendigt.
- Bed om en vurdering og en plan · hvornår kommer en rettelse, og i hvilken udgave?
- Aftal en midlertidig beskyttelse · fx at begrænse adgangen til den berørte funktion, til rettelsen er installeret.
- Følg op · og registrer fundet som åbent, til rettelsen er installeret og kontrolleret.
Svagheder i udbredte produkter kan få et offentligt CVE-nummer, når de er kendt og registreret. Det gør det lettere at følge med i, om andre brugere af samme produkt er ramt, og om der er kommet en rettelse. Er svagheden ny og ukendt, skal leverandøren have tid til at rette den, før den omtales bredt. Aftal derfor med testeren og leverandøren, hvordan oplysningerne håndteres, indtil rettelsen er ude.
Fordeling og prioritering, når fundene har to ejere
Prioriteringen skal ske på tværs af de to ejere. Et alvorligt fund i koden kan ikke rettes af IT, men IT kan måske gøre det mindre farligt i mellemtiden ved at begrænse, hvem der kan nå funktionen. Et mindre alvorligt fund i opsætningen kan derimod rettes med det samme. Rækkefølgen bliver derfor ikke kun et spørgsmål om alvor, men også om, hvem der kan handle hvornår.
Gå rapporten igennem sammen med ejeren af løsningen i forretningen, og fordel fundene, før de sendes videre:
- ☐ Er hvert fund markeret som kode, opsætning eller omgivelser?
- ☐ Har hvert fund en ejer, enten IT eller leverandøren?
- ☐ Er de alvorligste fund i koden sendt til leverandøren med en aftalt svarfrist?
- ☐ Er der aftalt midlertidig beskyttelse, hvor rettelsen må vente?
- ☐ Er fund i opsætning og omgivelser planlagt i driften?
Er I i tvivl om, hvilken gruppe et fund hører til, så spørg testeren. Det behøver ikke være svært at afgøre for den, der har fundet det.
Når leverandøren ikke retter
Ikke alle leverandører retter hurtigt, og nogle produkter er ikke længere understøttet. Så har IT og ejeren af løsningen et valg: leve med risikoen for en tid, beskytte løsningen udefra eller skifte den ud. En webapplikationsfirewall kan være en midlertidig beskyttelse, men den retter ikke fejlen. → Webapplikationsfirewall og testen
Det britiske NCSC skriver i sin vejledning om sårbarhedsstyring, at det er en beslutning for ledelsen at lade være med at opdatere, og at tid, budget og risiko bør registreres. Det gælder også, når det er leverandøren, der ikke leverer. Skriv beslutningen ned med en dato for, hvornår den tages op igen. → Et system, der ikke kan opdateres
Det skal I lade være med
- At sende hele rapporten til leverandøren uden at tænke. Del de fund, der vedrører løsningen.
- At vente på leverandøren med alt. Fund i opsætning og omgivelser kan rettes nu.
- At rette i koden selv. Det kan bryde løsningen og jeres aftale.
- At lade fund i koden ligge uden ejer. De skal registreres og følges som alle andre. → Fra fund til opgave
- At teste uden at orientere leverandøren. Aftalen kan kræve det, og leverandøren skal kunne hjælpe.
Hvad kan og ikke kan konkluderes
Testen viser, hvordan den installerede løsning holdt i jeres miljø på testtidspunktet, med de roller og funktioner, der var aftalt. Den kan ikke dokumentere kvaliteten af leverandørens kode i andre installationer eller i nye udgaver. En ny udgave fra leverandøren kan både rette og indføre fejl. Fund i opsætning og omgivelser siger noget om jeres drift og kan bruges til at forbedre installationen af den næste løsning.
Kilder
- OWASP Top 10: OWASP’s oversigt over de mest kritiske sikkerhedsrisici i webapplikationer, beskrevet som et dokument til bevidstgørelse af udviklere.
- NCSC: Vulnerability management: opdatering som udgangspunkt, overblik over systemer og ejere, prioritering, og at beslutningen om ikke at opdatere er en ledelsesbeslutning.
- CVE: det offentlige register over kendte sårbarheder med identifikationsnumre.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Testmiljø til webtesten · Et system, der ikke kan opdateres
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
