SBOM-eksempler: CycloneDX- og SPDX-filer forklaret

Applikationen i eksemplerne

Begge filer beskriver example-api 2.4.0, en illustrativ Node.js-service med én direkte afhængighed, express. Express afhænger selv af accepts, så eksemplerne viser også én transitiv afhængighed. En rigtig SBOM af en Express-applikation angiver mange flere komponenter, men strukturen er den samme.

Eksempel på en CycloneDX-SBOM

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-30T09:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "example-sbom-tool", "version": "1.0.0" }
      ]
    },
    "component": {
      "type": "application",
      "bom-ref": "example-api",
      "name": "example-api",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/[email protected]",
      "name": "accepts",
      "version": "1.3.8",
      "purl": "pkg:npm/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "example-api", "dependsOn": ["pkg:npm/[email protected]"] },
    { "ref": "pkg:npm/[email protected]", "dependsOn": ["pkg:npm/[email protected]"] }
  ]
}

Felt	Hvad det fortæller dig
`specVersion`	Hvilken version af formatet filen bruger, så værktøjer kan parse den.
`serialNumber`, `version`	Hvilken SBOM det er, og hvilken revision af den.
`metadata.lifecycles`	Hvornår SBOM'en blev lavet. Her under buildet.
`metadata.tools`	Hvilket værktøj der producerede den. To værktøjer kan rapportere det samme commit forskelligt.
`metadata.component`	Det produkt, SBOM'en beskriver.
`purl`	Package URL'en, den identifikator, der lader et værktøj matche komponenten med advisories.
`licenses`	Komponentens deklarerede licens.
`dependencies`	Hvem der trækker hvem ind. Det er dette, der gør `accepts` synlig som transitiv afhængighed.

Eksempel på en SPDX-SBOM

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-api-2.4.0",
  "documentNamespace": "https://example.com/spdx/example-api-2.4.0",
  "creationInfo": {
    "created": "2026-10-30T09:00:00Z",
    "creators": ["Tool: example-sbom-tool-1.0.0"]
  },
  "packages": [
    {
      "name": "example-api",
      "SPDXID": "SPDXRef-Package-example-api",
      "versionInfo": "2.4.0",
      "downloadLocation": "NOASSERTION"
    },
    {
      "name": "express",
      "SPDXID": "SPDXRef-Package-express",
      "versionInfo": "4.21.2",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    },
    {
      "name": "accepts",
      "SPDXID": "SPDXRef-Package-accepts",
      "versionInfo": "1.3.8",
      "downloadLocation": "NOASSERTION",
      "licenseDeclared": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/[email protected]"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relationshipType": "DESCRIBES",
      "relatedSpdxElement": "SPDXRef-Package-example-api"
    },
    {
      "spdxElementId": "SPDXRef-Package-example-api",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-express"
    },
    {
      "spdxElementId": "SPDXRef-Package-express",
      "relationshipType": "DEPENDS_ON",
      "relatedSpdxElement": "SPDXRef-Package-accepts"
    }
  ]
}

Oplysningerne er de samme, bare arrangeret anderledes. SPDX har en packages-liste og angiver hver kobling mellem elementer i relationships. licenseDeclared er det, pakken siger om sig selv, og downloadLocation kan være NOASSERTION, når værktøjet ikke kender den. Se CycloneDX vs. SPDX for, hvordan de to formater adskiller sig ud over layoutet.

Sådan ser en svag SBOM ud

En fil kan være gyldig og alligevel næsten ubrugelig. Hold øje med dette:

Ingen afhængighedsrelationer. En flad liste fortæller, at en pakke er til stede, ikke hvad der trak den ind, og det er det, du skal vide for at rette en transitiv afhængighed.
Ingen package URLs. Uden en identifikator som en purl må matchningen af en komponent med advisories bygge på gæt ud fra navne.
Manglende licenser. Mange felter stående som NOASSERTION betyder, at SBOM'en ikke kan svare på spørgsmål om licenser.
Mistænkeligt få komponenter. En håndfuld komponenter for en stor applikation betyder som regel, at kun direkte afhængigheder er med, eller kun det, én lockfile deklarerede.
Intet om hvornår eller hvordan. Uden et værktøj og en genereringskontekst kan du ikke se, hvad du kan stole på, at SBOM'en dækker.
Tavshed om huller. En god SBOM siger, hvad den ikke kunne se. De fleste filer stopper bare, og læseren går ud fra, at de er komplette.

Sådan tjekker du din egen SBOM

Validér formatet. Kør den gennem en skemavalidator for dens format og version, for et værktøj, der ikke kan parse filen, kan ikke bruge den.
Tjek felterne. Sammenlign den med 2026 Minimum Elements eller den liste, din kunde har bedt om.
Søg efter noget, du kender. Vælg en transitiv afhængighed, en pakke fra dit base-image og et build-værktøj, og se, hvilke af dem der dukker op.
Sammenlign to kilder. Generér en anden SBOM med en anden metode, og se på forskellen. Hver ekstra komponent i den ene fil er et spørgsmål til den anden.

En build-time SBOM fra CRACI

CRACI eksporterer de samme formater. Forskellen er, hvor indholdet kommer fra: CRACI registrerer, hvad hvert GitHub Actions-job hentede, så hver komponent i SBOM'en faktisk blev trukket ind i buildet, og pakker gendannet fra CI-caches er markeret som sådan. GitHub Actions, som workflowet kørte, optræder også som komponenter, fastlåst til det anvendte commit. Hvert jobs SBOM har desuden en fuldstændighedsstatus, så hullerne er angivet i stedet for at være overladt til dig at finde. Se SBOM-generering under buildet eller hvordan SBOM-værktøjer klarer sig i sammenligning.

SBOM-eksempler: ofte stillede spørgsmål

Hvordan ser en SBOM ud?

Som regel er det en JSON-fil, nogle gange XML. Den starter med data om selve SBOM'en, såsom værktøj og tidsstempel, angiver derefter hver komponent med navn, version, identifikator og licens og beskriver til sidst, hvordan komponenterne afhænger af hinanden.

Er en SBOM en JSON-fil?

Som regel, fordi JSON er den mest udbredte kodning af både CycloneDX og SPDX. Begge formater har også andre kodninger, og SPDX har desuden en tag-value-tekstform.

Hvad er en purl i en SBOM?

En purl, eller package URL, er en standardidentifikator for en pakke, for eksempel pkg:npm/[email protected]. Den navngiver økosystem, pakke og version i én streng, så værktøjer pålideligt kan matche komponenten med sårbarhedsdata.

Hvor mange komponenter bør en SBOM have?

Der er intet rigtigt antal, men den bør omfatte transitive afhængigheder, der som regel langt overstiger de direkte i antal. Meget få komponenter for en stor applikation betyder som regel, at værktøjet kun så en del af den.

Kan man se en SBOM for et open source-projekt?

Nogle gange. Nogle projekter offentliggør SBOM'er sammen med deres releases, og GitHub kan eksportere en fra et repositorys afhængighedsgraf. Den eksport afspejler, hvad repositoriet deklarerer, snarere end hvad et bestemt build brugte.