Forside · Gennemgået oktober 2026 · Af John Nielsen
Når en sikkerhedsfejl i leveret software ender i en tvist, er de tekniske kernespørgsmål næsten altid de samme: var fejlen til stede i den version, der blev leveret, var den kendt eller burde den have været undgået på leveringstidspunktet, hvad stod der om sikkerhed i aftalen, og hvem havde ansvaret for at rette den bagefter? Hvert spørgsmål kan besvares med konkrete data, men kun hvis den leverede version, tidspunkterne og kravene er sikret og holdt adskilt.
Artiklen handler om fejl i selve softwaren: egenudviklet kode, konfiguration og indbyggede komponenter. Spørgsmålet om, hvordan en angriber faktisk kom ind, er beskrevet i indgangsvejen: sådan underbygges konklusionen. Tvisten med IT-leverandøren efter et angreb er beskrevet fra advokatens side på digital-bevissikring.dk.
Tre typer sikkerhedsfejl
Det er nyttigt at skelne, fordi de vurderes forskelligt:
- Fejl i egenudviklet kode, fx manglende adgangskontrol, utilstrækkelig validering af input eller forkert håndtering af sessioner. De er leverandørens egne, og spørgsmålet er, om de strider mod aftalte krav eller sædvanlig god praksis.
- Sårbare tredjepartskomponenter, fx et bibliotek med en kendt sårbarhed. Her er tidspunktet afgørende: var sårbarheden offentligt kendt, og fandtes en rettet version, da softwaren blev leveret?
- Usikker konfiguration, fx standardadgangskoder, åbne administrationsflader, debugtilstand i produktion eller hemmeligheder i kildekoden. Her skal det afklares, hvem der satte konfigurationen, og hvornår.
Var fejlen der ved leveringen?
Første skridt er at fastlægge den leverede version og undersøge den, ikke den version, der kører i dag. Det kræver:
- Commit-id og hashværdi for den leverede kildekode og de byggede artefakter.
- Leverancens konfiguration og driftsmiljø på overdragelsestidspunktet.
- En sammenligning med den version, hvor fejlen blev konstateret, så senere ændringer kan udskilles.
Med Git-historikken kan man ofte finde den commit, der introducerede fejlen, og dermed vise, om den var med fra leveringen eller kom til senere, og af hvem. Se kildekode og Git som bevis og leverancens tilstand på overdragelsestidspunktet.
Var den kendt?
For sårbare komponenter er tidslinjen central:
- Hvornår blev sårbarheden offentliggjort? CVE-poster og leverandørens sikkerhedsmeddelelser har datoer. NVD og projekternes egne meddelelser kan give forskellige datoer, så kilden skal angives.
- Hvornår fandtes en rettet version? Ses i projektets udgivelseshistorik.
- Hvornår blev komponenten hentet og leveret? Ses i låsefiler, byggelogs og SBOM. Se SBOM og byggeartefakter som dokumentation.
- Blev sårbarheden udnyttet aktivt? CISA’s katalog over kendte, udnyttede sårbarheder (KEV) angiver, hvornår en sårbarhed blev optaget i kataloget. Det siger noget om, hvor presserende rettelsen var.
For fejl i egenudviklet kode er spørgsmålet i stedet, om fejltypen var velkendt. Mange typer er beskrevet i CWE-kataloget og i OWASP’s materialer gennem mange år, og det kan indgå i vurderingen af, hvad der var sædvanlig praksis.
Alvorlighed: score og konkret risiko
CVSS, der vedligeholdes af FIRST og nu findes i version 4.0, giver en standardiseret score for en sårbarheds alvorlighed. Den grundlæggende score beskriver sårbarheden generelt. Den siger ikke, hvor alvorlig den var i det konkrete miljø.
Den konkrete vurdering tager stilling til:
- om den sårbare funktion faktisk blev brugt i løsningen
- om den var tilgængelig fra internettet, kun internt eller kun for godkendte brugere
- hvilke data og funktioner en udnyttelse ville give adgang til
- om andre kontroller begrænsede risikoen
En høj score for en komponent, hvis sårbare funktion aldrig kaldes, kan være uden praktisk betydning. Omvendt kan en middel score være alvorlig, hvis den rammer en central funktion med persondata. Begge forhold skal fremgå.
Hvad var aftalt?
Sikkerhedskrav i kontrakter er ofte vage, fx “sikkerhed efter bedste praksis”. Er der henvist til en standard, giver det en konkret målestok. OWASP Application Security Verification Standard (ASVS), der kom i version 5.0 i 2025, opdeler krav til webapplikationer i tre niveauer. En henvisning til et bestemt niveau og en bestemt version gør det muligt at vurdere krav for krav. Uden en sådan henvisning må vurderingen bygge på, hvad der var sædvanligt for den type løsning, og det skal begrundes.
Lige så vigtigt er ansvaret efter leveringen. Hvem skulle opdatere komponenter, overvåge sikkerhedsmeddelelser og rulle rettelser ud? Det fremgår af drifts- og vedligeholdelsesaftaler og af den faktiske praksis, som kan ses i ticketsystemer, deployment-historik og ændringslog. Se CI/CD-logs og testdokumentation.
Rettelsen og dens omfang
I mange tvister handler uenigheden lige så meget om rettelsen som om fejlen. For en sårbar komponent kan rettelsen være en opdatering til en ny version, men en ny hovedversion kan kræve ændringer i den kode, der bruger komponenten. For en fejl i egenudviklet kode kan rettelsen være en enkelt kontrol eller en ændring af hele adgangsmodellen. Den sagkyndige kan beskrive, hvad rettelsen teknisk omfatter, hvilke dele af løsningen den berører, og om den kunne være udført inden for den tid, der var til rådighed. Har leverandøren allerede rettet fejlen, viser historikken, hvornår og hvordan.
Verifikation uden at skade
Fejlen skal vises, men undersøgelsen må ikke skade systemer eller data. I praksis:
- Undersøg i et isoleret testmiljø bygget fra den sikrede version, ikke i produktion.
- Påvis fejlen med den mindst indgribende metode, fx ved kodegennemgang og en kontrolleret test, der viser, at kontrollen mangler.
- Indhent skriftlig tilladelse fra systemets ejer, før der testes på noget, der ikke er en kopi.
- Gem testens input, output og tidspunkt.
Rapporten beskriver fejlen så præcist, at en sagkyndig kan efterprøve den, men uden at være en vejledning i at udnytte den. Følsomme detaljer kan lægges i et fortroligt bilag.
Typiske fejlkilder
- Scanning af den nuværende version i stedet for den leverede.
- Scannerresultater som konklusion. Sårbarhedsscannere giver falske fund og overser fejl i forretningslogik. Fund skal efterprøves.
- Datoer fra én kilde. Offentliggørelse, optagelse i databaser og tilgængelig rettelse kan ligge på forskellige dage.
- Bagklogskab. En fejltype, der er velkendt i dag, var ikke nødvendigvis det på leveringstidspunktet.
- Uklar rollefordeling. Har kunden eller en driftsleverandør ændret konfigurationen, skal det skilles fra leverancen.
Sikring
Sikr den leverede kode og de leverede artefakter med hashværdier, konfiguration fra driftsmiljøet, låsefiler og SBOM’er, scannerrapporter fra projektets egen proces, ticket- og ændringshistorik samt de eksterne kilder om sårbarheden, fx CVE-posten og leverandørens meddelelse, som de så ud på undersøgelsestidspunktet. Eksterne sider ændres, så gem dem i en form, der kan dokumenteres; se webarkivering i forensisk kvalitet.
Hvad vurderingen kan og ikke kan bevise
En teknisk vurdering kan vise, om fejlen var til stede i den leverede version, om den var kendt eller af en kendt type på det tidspunkt, hvor alvorlig den var i det konkrete miljø, og hvordan den forholder sig til aftalte krav. Den kan ikke afgøre, om fejlen er en mangel i juridisk forstand, og den kan ikke alene vise, at en senere hændelse skyldtes netop denne fejl. Den sammenhæng kræver en særskilt undersøgelse af hændelsen.
Kilder og versioner
- FIRST: Common Vulnerability Scoring System (CVSS)
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP: Application Security Verification Standard
- MITRE: Common Weakness Enumeration (CWE)
Senest gennemgået: oktober 2026.
Næste skridt
Læs også: Kodekvalitet og teknisk gæld som mangel: sådan kan det måles i en tvist · Arkitektur og skalerbarhed, når systemet ikke kan bære belastningen
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
