IT-Sicherheit Glossar

Was ist eine SBOM?

Eine Software Bill of Materials (SBOM) ist eine strukturierte Stückliste der Komponenten, aus denen eine Softwareversion besteht. Sie erfasst direkte und transitive Abhängigkeiten, Versionen, Identifikatoren, Beziehungen und nach Möglichkeit Herkunft sowie Prüfsummen. Eine SBOM macht Software nicht automatisch sicher; sie beantwortet aber schneller, wo eine betroffene Komponente tatsächlich eingesetzt wird.

Welche Informationen sollte eine SBOM enthalten?

  • Komponente:
    Name, Version, Hersteller oder Supplier und eindeutige Kennung wie Package URL (purl) oder CPE.
  • Beziehungen:
    Welche Anwendung enthält welche Bibliothek und welche Abhängigkeiten sind transitiv.
  • Integrität:
    Hashes, Erstellungszeitpunkt und Tool, das die SBOM erzeugt hat.
  • Lizenz und Herkunft:
    Lizenzinformationen, Downloadquelle und gegebenenfalls externe Referenzen.
  • Release-Bezug:
    Exakte Zuordnung zu Artefakt, Image, Firmware oder ausgelieferter Version.

CycloneDX und SPDX

FormatSchwerpunkt
CycloneDXOWASP-Standard mit starkem Fokus auf Security Use Cases, Komponenten, Services, Abhängigkeiten und VEX.
SPDXISO/IEC 5962; umfangreicher Standard für Komponenten, Dateien, Pakete, Lizenzen und Lieferketteninformationen.

Das passende Format hängt von Empfängern und Werkzeugkette ab. Wichtiger als die Wahl ist, dass die SBOM automatisiert, vollständig, pro Release reproduzierbar und gegen das tatsächliche Artefakt erzeugt wird.

Beispiel eines kleinen CycloneDX-Ausschnitts

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [{
    "type": "library",
    "name": "example-library",
    "version": "1.2.3",
    "purl": "pkg:npm/example-library@1.2.3",
    "hashes": [{ "alg": "SHA-256", "content": "..." }]
  }]
}

Wie wird eine SBOM praktisch genutzt?

  1. SBOM während des Builds oder direkt aus dem finalen Container/Image erzeugen.
  2. Mit Release und Artefakt signiert oder anderweitig manipulationsgeschützt speichern.
  3. Komponenten laufend gegen CVE-, Hersteller- und Threat-Intelligence-Daten abgleichen.
  4. Treffer auf tatsächliche Erreichbarkeit, verwendete Funktion und Kompensationsmaßnahmen prüfen; optional VEX pflegen.
  5. Bei neuen Lücken betroffene Produkte, Kunden und Supportzeiträume auswerten.

Nützliche Open-Source-Werkzeuge

Syft und cdxgen erzeugen SBOMs für viele Ökosysteme. OSV-Scanner, Grype und Trivy gleichen Komponenten mit Schwachstellendaten ab. Ergebnisse benötigen eine fachliche Bewertung; Paketname und Version beweisen nicht automatisch, dass verwundbarer Code erreichbar ist.

Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.

Hast du Feedback zum Thema SBOM? Schreib uns!