Leverancens tilstand på overdragelsestidspunktet: sikring af miljøer og builds

Forside · Gennemgået oktober 2026 · Af John Nielsen

I tvister om IT-projekter er et af de centrale spørgsmål, hvad der faktisk var leveret på et bestemt tidspunkt: ved overdragelse, ved en milepæl, ved ophævelse eller ved leverandørskift. Svaret forsvinder hurtigt, fordi kode, databaser og miljøer ændres hver dag, og fordi den ene part ofte fortsætter udviklingen eller lukker miljøerne ned. En teknisk sikring fastholder tilstanden som et sæt kopier med hashværdier, så den senere kan undersøges af begge parter og en eventuel skønsmand.

Den juridiske ramme for et IT-skøn er beskrevet på digital-bevissikring.dk. Her gennemgås, hvad der teknisk skal sikres, og hvordan.

Hvad “leverancen” består af

En softwareleverance er sjældent én ting. Typisk består den af flere lag, der hver skal sikres for sig:

Kildekode · Repositories med fuld historik, grene og tags
Byggede artefakter · Installationspakker, containerbilleder, kompilerede filer, releases
Databaser · Skema, migrationsscripts, testdata og eventuelt produktionsdata
Konfiguration · Miljøvariabler, konfigurationsfiler, infrastruktur som kode, hemmeligheder (som referencer)
Miljøer · Test-, staging- og produktionsservere, cloudressourcer
Dokumentation · Kravspecifikation, testrapporter, driftsvejledning, ticket-historik

Spørgsmålet i sagen afgør, hvor dybt hvert lag skal sikres. Handler tvisten om manglende funktionalitet, er kode og et kørende miljø vigtigst. Handler den om ydeevne, skal miljøets dimensionering og konfiguration med. Handler den om, hvem der har ændret hvad, er historikken central.

Kildekode med historik

Kildekoden sikres med fuld historik, ikke som en zip-fil af den seneste version. En kopi af hele repositoriet med alle grene og tags bevarer commit-id’er, som kan bruges til at vise præcis, hvilken version der lå på overdragelsestidspunktet. Et Git-bundle giver én fil, der kan hashes. Hvorfor historikken skal fortolkes med forsigtighed, og hvad den ikke kan vise, er beskrevet i kildekode og Git som bevis.

Notér det commit-id, som leverancen svarer til. Er der et release-tag, så notér både tag og det commit, tagget peger på, fordi tags kan flyttes.

Byggede artefakter og reproducerbarhed

Den kode, der ligger i repositoriet, er ikke nødvendigvis den, der kører. Sikr derfor også de byggede artefakter, der faktisk var installeret: pakker, containerbilleder med deres digest, og release-filer. For containerbilleder er digest en hashværdi af billedets indhold og identificerer det entydigt, i modsætning til et tag som “latest”, der kan pege på noget nyt i morgen.

Kan koden bygges igen fra repositoriet med samme resultat, er det et stærkt spor for, at kode og artefakt hænger sammen. Lykkes det ikke, skyldes det ofte afhængigheder, der er hentet i nyere versioner, eller tidsstempler, der indlejres ved bygning. Det er ikke i sig selv et tegn på manipulation, men det skal forklares.

Databaser

Databaser sikres konsistent, så transaktioner ikke er halvt gennemført i kopien. Valget mellem dump, snapshot og kopi af filerne er beskrevet i konsistent sikring af en database. Skemaet og migrationshistorikken er ofte vigtigere end selve dataene, fordi de viser, hvor langt datamodellen var nået. Indeholder databasen persondata, bør omfanget afgrænses og begrundes.

Miljøer og cloudressourcer

Kørende miljøer sikres på to måder, der supplerer hinanden:

Kopier af diske og ressourcer, fx snapshots af virtuelle maskiner og cloud-diske. Fremgangsmåden er beskrevet i snapshots af cloud-diske.
Dokumentation af det kørende system: skærmoptagelse af centrale funktioner, versionssider, sundhedstjek og en liste over kørende tjenester og versioner.

En kopi af en server viser, hvad der var installeret. En dokumenteret gennemgang af det kørende system viser, hvad der virkede. Skal en skønsmand senere vurdere funktionaliteten, er det en fordel, hvis miljøet kan genetableres fra kopierne, men det kræver, at licenser, nøgler og eksterne afhængigheder også er beskrevet.

Konfiguration og hemmeligheder

Konfiguration ligger ofte uden for repositoriet: i cloudplatformens indstillinger, i pipeline-variabler eller i et nøglelager. Sikr konfigurationen, men håndter hemmeligheder som adgangskoder og API-nøgler særskilt. Det er normalt nok at dokumentere, at en nøgle fandtes, og hvilket navn den havde, uden at kopiere selve værdien til beviskopien. Skal miljøet senere genetableres til et skøn, kan det være nødvendigt at have adgang til nøglerne igen. Det bør i så fald aftales mellem parterne, og nøglerne opbevares adskilt fra beviskopien med begrænset adgang. Spørgsmålet om skønsmandens adgang er beskrevet på digital-bevissikring.dk.

Hashmanifest og samlet registrering

Når mange forskellige filer og kopier skal holdes sammen, laves et hashmanifest: en liste over alle sikrede filer med SHA-256-værdi, størrelse, kilde og tidspunkt. Manifestet hashes selv, så hele samlingen kan låses med én værdi. Se hashmanifest for filsamlinger.

Registrér for hver del:

hvorfra den er hentet (server, konto, repository) og af hvem,
tidspunkt med tidszone,
metode og værktøj med version,
hashværdi,
hvilket commit, digest eller versionsnummer den svarer til.

Rækkefølge i praksis

Når tilstanden skal fastholdes under tidspres, fx fordi en leverandør skal lukke adgangene om få dage, er rækkefølgen vigtig:

Kortlæg repositories, byggeservere, artefaktlagre, databaser, miljøer og cloudkonti, og notér, hvem der har administratoradgang til hver.
Frys ændringer, hvor det kan aftales: ingen nye deploys, ingen oprydning i repositories, ingen sletning af gamle byg.
Sikr de mest flygtige dele først: kørende miljøer, der kan blive nedlagt, og CI/CD-data med kort opbevaring.
Sikr kildekode og artefakter med fuld historik og digest.
Sikr databaser konsistent.
Dokumentér det kørende system med skærmoptagelser og versionsoplysninger.
Lav hashmanifestet, og udveksl det med den anden part.

Byggeserverens logs og testresultater er en del af tilstanden, fordi de viser, hvad der blev bygget og testet før overdragelsen. De er beskrevet i CI/CD-logs og testdokumentation. Ticket-systemet og kravdokumenterne sikres samtidig, så kravene kan holdes op mod det leverede.

Begge parter bør kunne efterprøve

Sikringen bliver stærkest, når begge parter kan se, hvordan den er foretaget. Det kan ske ved, at begge parters teknikere er til stede, eller ved, at hashværdier og manifest udveksles umiddelbart efter sikringen. Så kan ingen senere hævde, at kopien er ændret, uden at det kan efterprøves.

Er det kun den ene part, der har adgang, fx leverandøren, der driver miljøerne, bør sikringen dokumenteres så grundigt, at en uvildig kan følge hvert trin. Kundens perspektiv, når leverandøren ikke leverer, er beskrevet på bevissikring-digitalt.dk.

Typiske fejl

Kun den seneste kode sikres, uden historik eller uden de byggede artefakter.
Miljøet sikres efter, at den nye leverandør er gået i gang, så tilstanden blander to leverancer.
Containerbilleder registreres med tag i stedet for digest.
Tidspunktet for sikringen ligger langt fra det tidspunkt, sagen drejer sig om, uden at forskellen er beskrevet.
Hemmeligheder kopieres ukritisk og spredes med beviskopierne.
Eksterne afhængigheder, fx biblioteker fra offentlige pakkearkiver eller tredjeparts-API’er, beskrives ikke, så miljøet senere ikke kan genetableres med de samme versioner.
Sikringen dokumenteres kun med skærmbilleder af en mappeoversigt uden hashværdier.

Hvad sikringen kan og ikke kan bevise

En sikring viser tilstanden på sikringstidspunktet. Den viser ikke automatisk tilstanden på overdragelsestidspunktet, hvis der er gået tid imellem. Forskellen skal bygges op med historik: commits, deploy-logs og ændringslogs, der viser, hvad der er ændret mellem de to tidspunkter. Sikringen viser heller ikke, om leverancen opfyldte kravene. Det er en vurdering, der kræver kravspecifikation, test og faglig analyse, og som typisk hører hjemme i et skøn.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Monitoreringsdata som bevis: overvågning, APM og opbevaring · CI/CD-logs og testdokumentation: virkede det eller ej?

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik