En softwarestykliste er en varedeklaration for software: hver pakke, din applikation indeholder, med version og licens. Indtil for nylig var det noget, kun store virksomheder forholdt sig til. Nu lander det som et leverandørspørgeskema i helt almindelige virksomheders indbakker.
Grunden til, at det sker nu, er ikke, at idéen er ny — det er, at lovgivningen har sat en dato på. Men det praktiske problem, en SBOM løser, er meget ældre og værd at sige rent ud, før forkortelserne tager over.
Det problem, en SBOM faktisk løser
Når der bliver offentliggjort en alvorlig sårbarhed i et udbredt bibliotek, er det første spørgsmål, enhver virksomhed får — fra en kunde, et forsikringsselskab, en bestyrelse — det simplest mulige: er vi ramt?
De fleste virksomheder kan ikke svare hurtigt. Ikke fordi de er sjuskede, men fordi det ærlige svar kræver en liste, ingen vedligeholder. En moderne webapplikation erklærer måske fyrre afhængigheder og installerer flere hundrede, fordi de fyrre trækker deres egne med. Ingen har valgt de ekstra, og ingen har skrevet dem ned.
En SBOM er den liste — genereret, ikke vedligeholdt i hånden. Med den i hånden bliver "er vi ramt?" til en tekstsøgning i stedet for en uges arkæologi.
Hvad en SBOM indeholder
Som minimum hver komponent i din software med de oplysninger, der skal til for at identificere den entydigt:
- Navn og version — og de skal være præcise. "Nyeste" er ikke en version, og et pakkenavn uden sit økosystem er tvetydigt, for det samme navn findes på npm og PyPI som to forskellige stykker software.
- En entydig identifikator — typisk en package-URL som
pkg:npm/lodash@4.17.21, der samler økosystem, navn og version i én streng, værktøjer kan matche pålideligt. - Licens — hvad du juridisk må med den.
- Relationer — hvilken komponent der trak hvilken ind. Det er dét, der gør en flad liste til noget, du kan handle på.
- Dokumentets eget ophav — hvem der genererede det, hvornår og med hvilket værktøj.
Det sidste punkt lyder bureaukratisk og er det ikke. En SBOM uden dato er værdiløs: software ændrer sig ugentligt, så en stykliste beskriver et øjeblik — og et dokument, der ikke siger hvilket øjeblik, kan ikke holdes op mod noget.
SPDX og CycloneDX: hvad der reelt adskiller dem
Der er to formater i reel brug. De overlapper kraftigt, og valget betyder mindre, end de fleste sammenligninger antyder — men de kommer fra hver sin verden og er gode til hver sit.
SPDX startede som et format til licensoverholdelse og blev en ISO-standard i sin 2.2.1-revision. Tyngdepunktet er juridisk: præcise licensudtryk, klare udsagn om hvad der er kendt og ukendt, og de dokumentoplysninger, en revisor går op i. Når indkøb, en juridisk afdeling eller en lovtekst beder om "en SBOM" ved navn, er det som regel den her, de mener.
CycloneDX er opstået i OWASP og sikkerhedsmiljøet, og det kan man mærke: det har en indbygget plads til sårbarheder og vurderingen af dem ved siden af selve fortegnelsen. Det er siden blevet standardiseret som Ecma-424, så "ikke en standard" er ikke længere en grund til at foretrække det andet. Skal din SBOM læses af sikkerhedsværktøjer og ikke bare arkiveres, bærer CycloneDX mere af det, de vil have.
Det praktiske svar er at lave begge. De genereres ud fra den samme underliggende scanning, så de kan ikke være uenige, og det koster ingenting at udstede to filer i stedet for én. Så udleverer du bare den, modtageren kan læse.
Ærlighedsproblemet: NOASSERTION
Her ligger det, der skiller en brugbar SBOM fra en vildledende.
Nogle gange kan en komponents licens ikke fastslås — pakkens metadata er tom, eller licensfeltet indeholder fritekst, ingen parser genkender. Et værktøj har to muligheder: gætte eller sige, at det ikke ved det. SPDX har en bestemt værdi til det sidste, NOASSERTION, og den findes netop, fordi gætteriet er farligt.
Værktøjer nedstrøms behandler en SBOM som en kendsgerning. En gættet licens forbliver ikke et gæt: den bliver læst ind, rapporteret og til sidst lagt til grund for en beslutning om, hvorvidt I må sende produktet ud. Det samme gælder versioner — en komponent, hvis version ikke kan fastslås, bør stå som ukendt i stedet for at få et plausibelt tal, for det tal bliver slået op mod sårbarhedsdatabaser, som om det var sikker viden.
Når du vurderer et SBOM-værktøj, er det dét, du skal teste. Peg det mod et projekt med en pakke, det ikke kan opløse helt, og se hvad det skriver. Et værktøj, der aldrig siger "ukendt", er ikke dygtigere end et, der gør — det er mindre ærligt.
Hvem der kommer til at bede dig om en
Tre grupper, nogenlunde i den rækkefølge:
Dine erhvervskunder. Store organisationer skal styre deres egen forsyningskæde, og du er en del af den. Det lander som et sikkerhedsspørgeskema, ofte med en frist bundet til en kontraktfornyelse.
Dit forsikringsselskab. Tegning af cyberforsikring er blevet betydeligt mere konkret om, hvad en virksomhed kan dokumentere.
Lovgivningen. NIS2 kræver allerede forsyningskædesikkerhed af de omfattede organisationer, og de sender kravet videre til deres leverandører — og det er sådan, en lille softwareleverandør ender med at være omfattet uden at være nævnt i direktivet. EU's Cyber Resilience Act går videre og indfaser krav om stykliste for produkter med digitale elementer hen over 2026 og 2027.
Sådan laver du en
Ikke i hånden. En SBOM skrevet af et menneske er forældet den dag, den bliver skrevet, og forkert dagen efter.
Den bør genereres ud fra det samme opløsningstrin, der producerer dit faktiske afhængighedstræ — hvilket i praksis betyder, at den læser dine lockfiles. Et manifest som pom.xml eller en bar requirements.txt angiver hensigt og ikke resultat, så en SBOM bygget på det alene vil liste de pakker, du selv har valgt, og ingen af dem, de trak ind — hvilket som regel er det store flertal. Hvorfor de to tal er forskellige, og hvad man gør ved det, er værd at læse ved siden af.
Hvad er en SBOM helt enkelt?
En softwarestykliste er en maskinlæsbar liste over hver pakke, din software indeholder, med hver pakkes version og licens — en varedeklaration for software. Det praktiske formål er at lade dig svare hurtigt på ét spørgsmål: når der bliver offentliggjort en sårbarhed i et udbredt bibliotek, er vi så ramt? Uden en SBOM tager det spørgsmål dages undersøgelse; med en er det en søgning.
Hvad er forskellen på SPDX og CycloneDX?
SPDX og CycloneDX beskriver det samme og overlapper kraftigt. SPDX startede som et format til licensoverholdelse og er i dag en ISO-standard, så det er dét, indkøb, revisorer og lovgivning som regel beder om ved navn. CycloneDX kommer fra OWASP og sikkerhedsmiljøet, har en indbygget plads til sårbarheder og vurderingen af dem ved siden af fortegnelsen og er standardiseret som Ecma-424, så sikkerhedsværktøjer foretrækker typisk det. At generere begge ud fra samme scanning koster ingenting og betyder, at du kan udlevere den, modtageren kan læse.
Kræver NIS2 en SBOM?
NIS2 kræver forsyningskædesikkerhed af de omfattede organisationer i stedet for at nævne styklisten som dokument, men de organisationer opfylder kravet ved at bede deres egne leverandører gøre rede for, hvad deres software indeholder — og det er sådan, virksomheder, der ikke er direkte omfattet, alligevel får brug for en. EU's Cyber Resilience Act er mere eksplicit og indfaser krav om stykliste for produkter med digitale elementer hen over 2026 og 2027.
Hvordan genererer jeg en SBOM til mit projekt?
Generér SBOM'en ud fra dine lockfiles i stedet for at skrive den i hånden, for en lockfile angiver præcis, hvad der bliver installeret, inklusive de transitive pakker, ingen har erklæret. En håndskrevet SBOM er forældet dagen efter, den er skrevet. Har dit projekt kun et manifest som pom.xml eller en almindelig requirements.txt, bliver dokumentet ufuldstændigt, medmindre værktøjet opløser resten — og det bør sige det frem for i stilhed at liste færre komponenter.
Hvor CodeControl passer ind
CodeControl genererer begge formater — SPDX 2.3 og CycloneDX 1.5 — ud fra den samme scanning af dit forbundne repository, så de to dokumenter stemmer overens af konstruktion. En licens, vi ikke genkender, udstedes som NOASSERTION i stedet for et gæt, og scanningen melder, hvilke dele af dit projekt den ikke kunne læse, i stedet for i stilhed at liste færre komponenter. Den eksporterer også et VEX-dokument, som er den halvdel af historien, en SBOM ikke fortæller. Den tekniske beskrivelse gennemgår økosystemdækningen i detaljer.