SBOM-Beispiele: CycloneDX- und SPDX-JSON-Dateien erklärt

Die Anwendung in diesen Beispielen

Beide Dateien beschreiben example-api 2.4.0, einen beispielhaften Node.js-Dienst mit einer direkten Abhängigkeit, express. Express hängt seinerseits von accepts ab, die Beispiele zeigen also auch eine transitive Abhängigkeit. Eine echte SBOM einer Express-Anwendung listet deutlich mehr Komponenten, die Struktur ist aber dieselbe.

CycloneDX-SBOM-Beispiel

{
  "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]"] }
  ]
}

Feld	Was es Ihnen sagt
`specVersion`	Welche Version des Formats die Datei nutzt, damit Tools sie parsen können.
`serialNumber`, `version`	Um welche SBOM es sich handelt und um welche Revision davon.
`metadata.lifecycles`	Wann die SBOM entstanden ist. Hier: während des Builds.
`metadata.tools`	Welches Tool sie erzeugt hat. Zwei Tools können denselben Commit unterschiedlich melden.
`metadata.component`	Das Produkt, das die SBOM beschreibt.
`purl`	Die Package-URL, die Kennung, mit der ein Tool die Komponente Advisories zuordnen kann.
`licenses`	Die deklarierte Lizenz der Komponente.
`dependencies`	Wer wen nachzieht. Dadurch wird `accepts` als transitive Abhängigkeit sichtbar.

SPDX-SBOM-Beispiel

{
  "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"
    }
  ]
}

Die Informationen sind dieselben, nur anders angeordnet. SPDX führt eine packages-Liste und nennt jede Verbindung zwischen Einträgen in relationships. licenseDeclared ist das, was das Paket über sich selbst angibt, und downloadLocation kann NOASSERTION sein, wenn das Tool den Ort nicht kennt. Wie sich die beiden Formate über das Layout hinaus unterscheiden, lesen Sie unter CycloneDX vs. SPDX.

Woran Sie eine schwache SBOM erkennen

Eine Datei kann gültig und trotzdem fast nutzlos sein. Achten Sie auf Folgendes:

Keine Abhängigkeitsbeziehungen. Eine flache Liste zeigt, dass ein Paket vorhanden ist, aber nicht, was es nachgezogen hat, und genau das brauchen Sie, um eine transitive Abhängigkeit zu beheben.
Keine Package-URLs. Ohne eine Kennung wie eine purl bleibt für den Abgleich mit Advisories nur das Raten anhand von Namen.
Fehlende Lizenzen. Stehen viele Felder auf NOASSERTION, kann die SBOM keine Lizenzfragen beantworten.
Verdächtig wenige Komponenten. Eine Handvoll Komponenten für eine große Anwendung bedeutet meist, dass nur direkte Abhängigkeiten erfasst sind oder nur das, was ein einziges Lockfile deklariert hat.
Keine Angabe zu Zeitpunkt und Methode. Ohne Tool und Generierungskontext können Sie nicht beurteilen, was die SBOM verlässlich abdeckt.
Schweigen über Lücken. Eine gute SBOM sagt, was sie nicht sehen konnte. Die meisten Dateien enden einfach, und Leser gehen davon aus, dass sie vollständig sind.

So prüfen Sie Ihre eigene SBOM

Das Format validieren. Prüfen Sie die Datei mit einem Schema-Validator für ihr Format und ihre Version, denn ein Tool, das die Datei nicht parsen kann, kann sie auch nicht nutzen.
Die Felder prüfen. Vergleichen Sie sie mit den 2026 Minimum Elements oder der Liste, die Ihr Kunde verlangt hat.
Nach etwas Bekanntem suchen. Wählen Sie eine transitive Abhängigkeit, ein Paket aus Ihrem Basis-Image und ein Build-Tool, und sehen Sie nach, welche davon auftauchen.
Zwei Quellen vergleichen. Erzeugen Sie eine zweite SBOM mit einer anderen Methode und sehen Sie sich den Unterschied an. Jede zusätzliche Komponente in der einen Datei ist eine Frage an die andere.

Eine SBOM zur Build-Zeit von CRACI

CRACI exportiert dieselben Formate. Der Unterschied liegt darin, woher der Inhalt kommt: CRACI zeichnet auf, was jeder GitHub-Actions-Job geladen hat, sodass jede Komponente in der SBOM tatsächlich in den Build gelangt ist, und aus CI-Caches wiederhergestellte Pakete sind als solche gekennzeichnet. Die GitHub Actions, die der Workflow ausgeführt hat, erscheinen ebenfalls als Komponenten, gepinnt auf den verwendeten Commit. Die SBOM jedes Jobs trägt außerdem einen Vollständigkeitsstatus, sodass Lücken benannt werden, statt dass Sie sie selbst finden müssen. Siehe SBOM-Generierung zur Build-Zeit oder SBOM-Tools im Vergleich.

SBOM-Beispiele: häufig gestellte Fragen

Wie sieht eine SBOM aus?

Meist ist sie eine JSON-Datei, manchmal XML. Sie beginnt mit Daten über die SBOM selbst, etwa Tool und Zeitstempel, listet dann jede Komponente mit Name, Version, Kennung und Lizenz und beschreibt schließlich, wie die Komponenten voneinander abhängen.

Ist eine SBOM eine JSON-Datei?

Meistens, denn JSON ist die am weitesten verbreitete Kodierung von CycloneDX und SPDX. Beide Formate haben auch andere Kodierungen, und SPDX kennt zusätzlich eine Textform aus Tag-Wert-Paaren.

Was ist eine purl in einer SBOM?

Eine purl, kurz für Package-URL, ist eine standardisierte Kennung für ein Paket, zum Beispiel pkg:npm/[email protected]. Sie nennt Ökosystem, Paket und Version in einer Zeichenkette, sodass Tools die Komponente zuverlässig mit Schwachstellendaten abgleichen können.

Wie viele Komponenten sollte eine SBOM haben?

Eine richtige Zahl gibt es nicht, aber die SBOM sollte transitive Abhängigkeiten enthalten, die die direkten meist deutlich überwiegen. Sehr wenige Komponenten für eine große Anwendung bedeuten meist, dass das Tool nur einen Teil gesehen hat.

Kann man die SBOM eines Open-Source-Projekts einsehen?

Manchmal. Einige Projekte veröffentlichen SBOMs mit ihren Releases, und GitHub kann eine aus dem Abhängigkeitsgraphen eines Repositorys exportieren. Dieser Export spiegelt wider, was das Repository deklariert, nicht, was ein bestimmter Build verwendet hat.