SBOM verstehen: Ein Blick auf CycloneDX, SPDX und SWID

Moderne Anwendungen sind keine riesigen Monolithen mehr, sie sind eine Sammlung von Microservices, Open-Source-Komponenten und Drittanbieter-Tools. Dies macht es jedoch sehr schwierig, das Innenleben unserer Anwendungen wirklich zu verstehen, insbesondere wenn man bedenkt, dass unsere Open-Source-Abhängigkeiten ebenfalls Open-Source-Abhängigkeiten haben!

Die Software-Stückliste SBOM) spielt dabei eine wichtige Rolle. SBOMs bieten eine detaillierte Bestandsaufnahme aller Softwarekomponenten. Dies hilft uns nicht nur, unsere Software besser zu verstehen, sondern ermöglicht es uns auch, Risiken zu identifizieren und unsere compliance Governance-Anforderungen zu erfüllen.

Damit SBOMs gut funktionieren, müssen sie standardisiert sein und sich leicht über verschiedene Systeme und Tools hinweg austauschen lassen. Hier kommen SBOM ins Spiel.

SBOM verstehen

SBOM legen ein gemeinsames Format für die Erstellung und den Austausch SBOM fest. Sie bieten eine einheitliche Sprache und gewährleisten so eine konsistente Kommunikation zwischen verschiedenen Organisationen und Tools.

Eine Standardisierung ist notwendig, da SBOMs sehr umfangreich sein können und zahlreiche Details zu Komponenten, Versionen, Lizenzen und Abhängigkeiten enthalten. Ohne ein Standardformat wird die Interpretation und Verwendung SBOM für verschiedene Unternehmen zu einer Herausforderung.

Derzeit sind drei wichtige SBOM in der Branche weit verbreitet:

1. CycloneDX: Ein leichter Standard mit Fokus auf Sicherheit, der verschiedene BOM-Typen unterstützt, einschließlich Software, Hardware und Services.
2. SPDX (Software Package Data Exchange): Der einzige von der ISO anerkannte SBOM , der für seinen umfassenden Ansatz in Bezug auf Komponentendaten und seine Ursprünge in der Softwarelizenzierung bekannt ist.
3. SWID (Software Identification) Tags: Konzentriert auf die Softwareidentifikation, um die Nachverfolgung installierter Software für das Asset-Management zu unterstützen.

Jeder Standard hat spezifische Stärken und Anwendungsfälle, die wir weiter erörtern werden.

CycloneDX auf einen Blick

• Speziell für Sicherheitsanwendungsfälle entwickelt (z. B. Schwachstellen-Tracking, VEX-Unterstützung, Komponenten-Hashing).
• Unterstützt nativ VEX (Vulnerability Exploitability eXchange) und Abhängigkeitsbäume.
• Kompatibel mit modernen DevSecOps und Tools wie OWASP Dependency-Check, Anchore, GitHub Advanced Security.
• Einfacher in CI/CD-Umgebungen zu integrieren (leichtgewichtig, JSON-freundlich).

CycloneDX zeichnet sich durch seine Effizienz und robusten Sicherheitsfunktionen aus. Sein Design ermöglicht eine schnelle Integration, was es ideal für Teams macht, die Agilität und Sicherheit schätzen. CycloneDX deckt Software, Hardware und dienstleistungsbezogene Materialien ab, wodurch es vielseitig für verschiedene Technologieumgebungen einsetzbar ist.

CycloneDX unterstützt mehrere Datenformate, darunter XML, JSON und Protobuf, und gewährleistet so die Kompatibilität mit verschiedenen Tools. Unter dem Dach von OWASP entwickelt sich CycloneDX kontinuierlich weiter, um aktuellen Sicherheitsherausforderungen in Software-Lieferketten zu begegnen.

Beispiel CycloneDX-Formatierung​


{  
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "example-lib",
      "version": "1.0.0",
      "purl": "pkg:npm/example-lib@1.0.0",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

SPDX erkunden

• Gerichtet an Rechtsteams und IP Due Diligence (starkes Lizenz-Metadatenmodell).
• Umfassende Lizenzausdruckssprache (SPDX-Lizenzliste).
• Standardisiert unter ISO/IEC 5962:2021.
• Wird in wichtigen Initiativen wie OpenChain, ORT und Tern verwendet.

SPDX ist weltweit als einziger SBOM mit ISO-Zertifizierung anerkannt, was seine Glaubwürdigkeit erhöht. Ursprünglich für die Softwarelizenzierung entwickelt, wurde SPDX erweitert, um den umfassenderen Anforderungen an die Softwaretransparenz gerecht zu werden.

SPDX unterstützt mehrere Datenformate wie Tag/Value, JSON, XML, YAML und RDF und integriert sich nahtlos in verschiedene Tools und Plattformen. Es bietet detaillierte Einblicke in Softwarekomponenten und dokumentiert Dateien und Code-Snippets für ein detailliertes Compliance- und Sicherheitstracking.

Beispiel SPDX-Formatierung​


SPDXVersion:SPDX-2.3
 DataLicense:CC0-1.0
 SPDXID: SPDXRef-DOCUMENT
DocumentName:sbom
-sbom
DocumentNamespace:sbom
Creator: Tool: SPDX-Tools
Created:  2025-05-08T12:00:00Z

PackageName: example-libSPDXID: SPDXRef-Package-example-libPackageVersion: 1.0.0PackageDownloadLocation: NOASSERTIONPackageLicenseConcluded: MITPackageLicenseDeclared: MIT
PackageChecksum: SHA256: abcdef1234567890abcdef1234567890abcdef1234569ui

SWID-Tags verstehen

• Ausgerichtet auf das Management von Unternehmenssoftwarebeständen.
• Standardisiert als ISO/IEC 19770-2 — sehr auf Regierung/Militär ausgerichtet.
• Wird verwendet in FedRAMP, NIST 800-171 und verwandten Compliance-Frameworks.

SWID Tags konzentrieren sich auf eine klare Abgrenzung von Softwareprodukten. Im Gegensatz zu umfassenden SBOMs identifizieren SWID Tags einzelne Softwarepakete, was für ein präzises Bestandsmanagement entscheidend ist.

Im Asset Management bieten SWID-Tags eine standardisierte Methode zur Verfolgung von Softwareinstallationen, wodurch Organisationen eine genaue Softwarelandschaft aufrechterhalten können. Dies hilft bei der Compliance und der Optimierung von Asset-Management-Strategien.

SWID Tags integrieren sich in Frameworks wie SCAP und TCG-Standards und stärken so ihre Rolle in Security und Compliance.

Beispiel SWID-Formatierung​


<SoftwareIdentity xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"                     name="example-lib"
version="1.0.0"
tagId="example-lib@1.0.0"
patch="false"
                  
</SoftwareIdentity>

Vergleich von SBOM

Um CycloneDX, SPDX und SWID Tags zu unterscheiden, beginnen Sie mit ihren Funktionen. CycloneDX eignet sich für ein flexibles BOM-Management in dynamischen Sicherheitsumgebungen. SPDX zeichnet sich durch Compliance-Tracking aus, während SWID Tags sich auf die präzise Softwareidentifikation konzentrieren. Hier ist ein schneller Vergleich:

Die Struktur von CycloneDX trägt dem Bedürfnis nach Transparenz Rechnung. SPDX bietet detaillierte Dokumentation und Datenintegrität für die Compliance-Überwachung.

Jeder Standard erfüllt spezifische Anforderungen. CycloneDX eignet sich für Teams, die eine schnelle, sichere Entwicklung priorisieren. SPDX spricht Organisationen an, die sich auf Compliance konzentrieren. SWID Tags verbessern das Asset Management durch präzise Nachverfolgung.

Konvertierungstools zwischen diesen Formaten sind unerlässlich, um die Interoperabilität aufrechtzuerhalten. Fortschrittliche Lösungen ermöglichen es Organisationen, von den Stärken jedes Standards zu profitieren und Strategien an spezifische Anforderungen anzupassen.

Auswahl des richtigen SBOM

Es reicht nicht aus, eine SBOM nur SBOM einem Format zu erstellen. Verschiedene Interessengruppen – seien es interne Auditoren, Regierungsbehörden oder Unternehmenskunden –benötigen die SBOM möglicherweise SBOM einem bestimmten Format, um sie in ihre bestehenden Tools oder Workflows zu integrieren. Zum Beispiel:

• Ein Bundesvertrag kann SPDX erfordern, während ein Sicherheitsanbieter, der eine Risikobewertung durchführt, möglicherweise CycloneDX bevorzugt.
• Einige CI/CD-Systeme unterstützen möglicherweise nur bestimmte SBOM für die Durchsetzung von Richtlinien oder automatisierte Scans.

Tooling ist wichtig: Wählen Sie eines, das mehrere Formate unterstützt

Angesichts dieser Variabilität müssen Sie ein Tool wählen, das SBOMs in mehreren Formaten aus denselben Quellartefakten generieren kann. Tools wie Aikido vereinfachen diesen Prozess, indem sie SBOMs während Ihrer Build-Pipeline oder Sicherheitsscans automatisch generieren und sie je nach Bedarf in Formaten wie CycloneDX, SPDX und anderen exportieren.

Diese Multi-Format-Fähigkeit stellt sicher, dass Sie die Compliance bei verschiedenen Anforderungen einhalten, ohne Arbeit zu duplizieren oder Fehler durch manuelle Konvertierungen einzuführen.