Forside · Gennemgået oktober 2026 · Af John Nielsen
En SBOM (software bill of materials) er en struktureret liste over de komponenter, en software består af, med navne, versioner og afhængigheder. Sammen med de byggede artefakter og deres hashværdier kan den dokumentere, hvad der faktisk blev leveret, og hvornår. I en tvist om indhold, licenser eller sårbare komponenter er det ofte det mest præcise svar på spørgsmålet: hvad var der i leverancen? Artiklen er skrevet til udviklingshuse og IT-projektledere.
Sikring af hele leverancens tilstand er beskrevet i leverancens tilstand på overdragelsestidspunktet. Her handler det om, hvordan SBOM og artefakter bruges som dokumentation, og hvor de kan svigte.
Hvad en SBOM er
CISA beskriver en SBOM som en indlejret oversigt, en ingrediensliste over de komponenter, en software er bygget af. To formater dominerer:
- SPDX, der er standardiseret som ISO/IEC 5962 og især har rødder i licensdokumentation.
- CycloneDX, der er standardiseret som ECMA-424 og bredt dækker komponenter, tjenester, afhængigheder og sårbarheder.
Begge kan udtrykkes maskinlæsbart, typisk som JSON, og begge kan rumme komponentnavn, version, leverandør, unikke identifikatorer, hashværdier af komponenterne og relationerne mellem dem. Kravene til, hvilke felter der som minimum bør med, er under udvikling, og CISA har på tidspunktet for gennemgangen (oktober 2026) opdateret sin vejledning om minimumselementer.
Kildekode, build og SBOM: tre forskellige ting
Det er vigtigt at skelne mellem, hvad der er i kildekoden, hvad der blev bygget, og hvad SBOM’en siger:
- Kildekoden angiver afhængigheder i manifest- og låsefiler, fx
package-lock.json,requirements.txtellerpom.xml. Uden låsefil kan samme manifest give forskellige versioner på forskellige dage. - Byggeartefaktet (container-image, installationspakke, binær fil) indeholder de komponenter, der faktisk blev hentet ved bygningen.
- SBOM’en er en påstand om artefaktets indhold. Den er kun så god som det værktøj og det tidspunkt, den blev dannet.
En SBOM dannet ud fra kildekoden kan derfor afvige fra en SBOM dannet ud fra det færdige artefakt. Til dokumentation af en leverance er en SBOM dannet ved bygningen og knyttet til artefaktets hashværdi det stærkeste udgangspunkt.
Kæden fra commit til leveret fil
Leverancen dokumenteres bedst som en kæde, hvor hvert led kan efterprøves:
- Commit-id i versionsstyringen, der angiver præcis hvilken kildekode der blev bygget; se kildekode og Git som bevis.
- Byggejob i CI/CD med log, tidspunkt og byggemiljø; se CI/CD-logs og testdokumentation.
- Artefakt med hashværdi, gemt i et artefaktlager eller containerregister.
- SBOM dannet i samme byggejob og knyttet til artefaktets hashværdi.
- Leveringen: hvornår og hvordan artefaktet blev overdraget eller deployet hos kunden.
Mangler et led, svækkes kæden. En SBOM uden reference til en bestemt artefakt-hash kan ikke vise, at den beskriver netop det, der blev leveret.
Reproducerbare builds
En build er reproducerbar, når samme kildekode, byggemiljø og byggeinstruktioner giver bit-for-bit identiske artefakter, uanset hvem der bygger. Er byggeprocessen reproducerbar, kan en uafhængig part genskabe artefaktet og dermed bekræfte, at det leverede svarer til kildekoden. Det er sjældent fuldt opnået i almindelige projekter. Tidsstempler, byggestier og hentede afhængigheder får ofte artefakterne til at afvige en smule, og afvigelsen skal så forklares, ikke bortforklares.
Hvor SBOM’en bruges i en tvist
- Hvad blev leveret? Var en aftalt funktion, et modul eller en komponent med i den leverede version?
- Licenser. Indeholdt leverancen open source-komponenter under licenser, der stiller krav, som kunden ikke var gjort opmærksom på? Den juridiske side er beskrevet på digital-bevissikring.dk.
- Sårbare komponenter. Var en komponent med kendt sårbarhed med i leverancen, og var en rettet version tilgængelig på leveringstidspunktet?
- Kodeoprindelse. Ved påstand om kopieret kode kan SBOM’en vise, hvilke tredjepartskomponenter der var med, så de kan skilles fra den egenudviklede kode, før kodelighed vurderes.
Sammenligning af to SBOM’er
I mange tvister er spørgsmålet ikke, hvad én version indeholdt, men hvad der ændrede sig mellem to versioner, fx mellem den version, der blev godkendt ved accepttest, og den, der kørte, da fejlen opstod. To SBOM’er dannet med samme værktøj kan sammenlignes komponent for komponent, så tilføjede, fjernede og opgraderede komponenter fremgår. Sammenligningen er kun meningsfuld, hvis begge SBOM’er beskriver artefakter af samme type, fx to container-images, og ikke ét image og ét kildekodetræ.
Resultatet bør præsenteres som en tabel med komponent, version før, version efter og kilde. Hvor en ændring skyldes en automatisk opdatering af en afhængighed og ikke en bevidst ændring i koden, bør det fremgå, fordi det ofte er netop det skel, parterne diskuterer.
SBOM som en del af aftalen
Stadig flere kunder kræver en SBOM ved hver leverance. Det er en fordel for begge parter, når tvisten kommer: leverancens indhold er dokumenteret på leveringstidspunktet og ikke rekonstrueret bagefter. Udviklingshuse, der allerede danner SBOM’er i byggeprocessen, bør gemme dem sammen med artefakterne i hele aftalens løbetid og i en periode derefter.
Sikring
Sikr SBOM-filen sammen med det artefakt, den beskriver, byggeloggen og låsefilerne fra det pågældende commit. Hash alle filer, og registrér dem i et samlet hashmanifest. Er artefaktet gemt i et register, så notér registerets digest for image eller pakke, ikke kun et versionsnavn, da et tag som latest kan pege på noget andet i morgen.
Mangler der en SBOM fra leveringstidspunktet, kan en dannes bagefter ud fra det bevarede artefakt. Rapporten skal da tydeligt angive, at SBOM’en er dannet efterfølgende, med hvilket værktøj og hvilken version, fordi forskellige værktøjer kan finde forskellige komponenter i samme artefakt.
Fejlkilder
- Værktøjsforskelle. To SBOM-værktøjer kan give forskellige lister for samme artefakt. Brug samme værktøj til sammenligninger, og dokumentér versionen.
- Ufuldstændig dækning. Statisk linkede biblioteker, kopieret kode og komponenter uden pakkemetadata findes ofte ikke af værktøjerne.
- Flytbare tags. Versionsnavne kan genbruges. Kun hashværdier binder en SBOM til en bestemt fil.
- Udviklings- og testafhængigheder. De kan stå i SBOM’en uden at være med i det leverede produkt.
- Manuelt redigerede SBOM’er. En SBOM er en tekstfil og kan ændres efter dannelsen. Sammenhold derfor altid med byggeloggen og, hvor det er muligt, med en ny SBOM dannet ud fra det bevarede artefakt. Er SBOM’en signeret eller attesteret i byggeprocessen, bør signaturen kontrolleres og resultatet noteres.
Hvad SBOM’en kan og ikke kan bevise
En SBOM knyttet til en artefakt-hash kan vise, hvilke komponenter et bestemt artefakt indeholdt, efter det anvendte værktøjs bedste vurdering. Den kan ikke vise, om komponenterne blev brugt, om en sårbarhed var udnyttelig i den konkrete opsætning, eller hvad parterne havde aftalt om indholdet. Det kræver analyse af koden og af aftalegrundlaget.
Kilder og versioner
- CISA: Software Bill of Materials (SBOM)
- ISO/IEC 5962:2021: SPDX Specification V2.2.1
- Ecma International: ECMA-424 (CycloneDX)
- Reproducible Builds: definition
Senest gennemgået: oktober 2026.
Næste skridt
Læs også: Kunden påstår fejl i jeres software: sikring af produktion · Teknisk mangelsvurdering af software: metode for den sagkyndige
→ Uvildig IT-sagkyndig med forensic-baggrund · For udviklingshuse · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
