Forside · Gennemgået oktober 2026 · Af John Nielsen
Ved software escrow deponerer leverandøren kildekoden hos en tredjepart, så kunden kan få den udleveret, hvis leverandøren går konkurs eller ikke længere vedligeholder løsningen. Deponeringen er kun nyttig, hvis koden faktisk kan bygges til den software, kunden kører, af en anden end leverandøren og uden adgang til leverandørens systemer. Det kan efterprøves teknisk. Det sker sjældnere, end det burde, og manglerne opdages ofte først, når udleveringen er sket og tiden er knap.
Artiklen beskriver de tekniske trin i en verifikation. Kundens situation, når leverandøren lukker, er beskrevet på bevissikring-digitalt.dk, og kuratorens tekniske overtagelse af IT er beskrevet i konkursboets IT: teknisk overtagelse.
Niveauer af verifikation
Verifikation kan ske i flere niveauer, og det er vigtigt at vide, hvilket der er gennemført:
- Indholdskontrol. Deponeringen kan åbnes, er ikke beskadiget, og indholdet svarer til en fortegnelse med hashværdier. Det siger intet om, hvorvidt koden kan bygges.
- Fuldstændighedskontrol. Der findes kildekode til alle moduler, byggeskripter, låsefiler, dokumentation og databaseskemaer. Mangler som eksterne moduler, der kun henvises til, findes her.
- Bygning. Koden bygges i et rent miljø ud fra deponeringen og dens dokumentation alene. Lykkes det, findes artefakter, der kan sammenlignes med det, der kører.
- Sammenligning. De byggede artefakter holdes op mod de artefakter, der kører hos kunden.
- Funktionstest. Den byggede software installeres i et testmiljø og afprøves mod udvalgte funktioner og data.
Kun niveau 3 til 5 svarer på spørgsmålet, om deponeringen kan bruges. Et certifikat om, at deponeringen er modtaget, svarer kun på niveau 1.
Hvad deponeringen skal indeholde
En brugbar deponering indeholder mere end kildekoden:
- kildekode til alle egenudviklede moduler med versionshistorik eller i det mindste et entydigt versions-id
- byggeskripter, CI/CD-konfiguration og en beskrivelse af byggeprocessen trin for trin
- låsefiler, så de samme versioner af afhængigheder kan hentes; se SBOM og byggeartefakter som dokumentation
- selve afhængighederne eller adgang til et spejl af dem, da offentlige registre kan fjerne versioner
- versioner af compilere, runtime, SDK’er og byggeværktøjer, gerne som et byggeimage
- databaseskemaer, migreringsskripter og nødvendige grunddata
- infrastruktur som kode og konfiguration af driftsmiljøet
- en liste over hemmeligheder og certifikater, der skal bruges, uden selve værdierne, med en beskrivelse af, hvordan nye dannes
- oplysning om kommercielle komponenter og licenser, som kunden selv skal anskaffe
Det rene byggemiljø
Det centrale trin er at bygge uden leverandørens hjælp og uden adgang til leverandørens interne systemer. I praksis:
- Opret et nyt, isoleret miljø, fx en virtuel maskine eller container, med kun det, der står i dokumentationen.
- Afbryd adgangen til internettet, eller begræns den til de kilder, deponeringen selv angiver. Ellers kan bygningen hente noget fra leverandørens interne pakkeregister eller fra internettet, som ikke er en del af deponeringen.
- Følg dokumentationen bogstaveligt, og notér hvert sted, hvor den er utilstrækkelig, og hvad der skulle til for at komme videre.
- Gem byggeloggen fuldt ud.
Hvert sted, hvor bygningen kræver viden, der ikke står i deponeringen, er et fund. Det kan være en miljøvariabel, et internt certifikat, et privat pakkeregister, en manuel rettelse eller et værktøj, som kun én udvikler havde installeret.
Sammenligning med det, der kører
Lykkes bygningen, er næste spørgsmål, om resultatet svarer til den software, kunden bruger. Det kan undersøges på flere måder:
- Bitidentiske artefakter. Er byggeprocessen reproducerbar, giver samme kildekode og miljø identiske filer, og hashværdierne kan sammenlignes direkte; se hash af en fil.
- Komponentvis sammenligning. Er bygningen ikke reproducerbar, kan indholdet sammenlignes: filer, versioner, komponentlister og indlejrede versionsoplysninger.
- Versionsoplysninger. Mange byggeprocesser indlejrer commit-id eller byggenummer i artefakterne. Stemmer de med deponeringen?
- Herkomstdata. Hvis byggeprocessen danner signerede herkomstoplysninger, fx efter SLSA-rammeværket, kan de vise, hvilken kilde et bestemt artefakt blev bygget fra.
Afvigelser er almindelige: tidsstempler, byggestier og rækkefølgen af filer i arkiver. De skal forklares og adskilles fra reelle forskelle i indhold.
Funktionstesten
Når byggede artefakter er fremstillet, skal det vises, at de faktisk kan køre. Installér dem i et testmiljø, opret databasen ud fra de deponerede skemaer, og afprøv et udvalg af centrale funktioner, gerne de samme som indgik i den oprindelige overtagelsesprøve. Brug syntetiske eller pseudonymiserede data frem for produktionsdata. Dokumentér for hver funktion, om den virkede, og hvad der eventuelt skulle tilpasses. Testen viser ikke, at alt virker, men den afslører hurtigt, om væsentlige dele mangler, fx en integration, et job, der kører om natten, eller en rapportmotor, som kun findes i produktion.
Rapporten fra verifikationen
Rapporten bør angive, hvilken deponering der er undersøgt, med dato og hashværdier, hvilke niveauer der er gennemført, byggemiljøets sammensætning, alle afvigelser fra dokumentationen og hvad der skulle til for at komme forbi dem, samt resultatet af sammenligningen og funktionstesten. Fund opdeles i, hvad der forhindrer bygning, hvad der forsinker den, og hvad der blot er utilstrækkeligt beskrevet.
Hyppige huller
- Deponeringen er gammel. Den seneste deponering er ældre end den version, der kører. Sammenlign versions-id’er.
- Moduler mangler. Fælles biblioteker, som leverandøren bruger på tværs af kunder, er ikke deponeret.
- Byggeprocessen bor i CI. Byggetrinnene står kun i leverandørens CI-system, ikke i deponeringen.
- Interne pakker. Afhængigheder hentes fra et privat register, der lukker sammen med leverandøren.
- Manuelle trin. Nogle trin er udført i hånden og aldrig beskrevet.
- Data og konfiguration mangler. Koden kan bygges, men løsningen kan ikke startes uden konfiguration eller grunddata.
Løbende verifikation
En verifikation er et øjebliksbillede. Ved hver ny udgivelse bør deponeringen opdateres, og bygningen bør gentages, gerne automatisk. NIST’s ramme for sikker softwareudvikling (SSDF) anbefaler, at de nødvendige filer og understøttende data, herunder integritets- og herkomstoplysninger, arkiveres sikkert for hver udgivelse. En leverandør, der allerede gør det, kan levere en deponering med langt færre huller.
Ved udlevering i en tvist eller konkurs
Når deponeringen udleveres, er der ofte uenighed: kunden mener, den er ufuldstændig, og leverandøren eller boet mener, den opfylder aftalen. Sikr derfor deponeringen, som den blev udleveret, med hashværdier og dokumentation for modtagelsen, før den åbnes, og gennemfør verifikationen på en kopi. Dokumentér alle trin, så en anden sagkyndig kan gentage dem. En uvildig IT-sagkyndig kan vurdere de tekniske spørgsmål om fuldstændighed og byggebarhed; se uvildig teknisk undersøgelse. Se også leverancens tilstand på overdragelsestidspunktet.
Hvad verifikationen kan og ikke kan bevise
En gennemført verifikation kan vise, om deponeringen kan bygges med det, den indeholder, hvad der mangler, og om resultatet svarer til den software, der kører. Den kan ikke vise, om deponeringen opfylder aftalen i juridisk forstand, og en vellykket bygning siger ikke noget om kodens kvalitet eller om, hvor let den er at videreudvikle for en ny leverandør.
Kilder og versioner
- NIST: SP 800-218, Secure Software Development Framework
- Reproducible Builds: definition
- SLSA: Supply-chain Levels for Software Artifacts
Senest gennemgået: oktober 2026.
Næste skridt
- Kildekode og Git som bevis
- Ticket-systemer: ændringshistorik i Jira, ServiceNow og lignende
- SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
Læs også: Prior art i software: dokumentation af tidligere kendt teknik · Kildekode og Git som bevis
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
