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 hier eine Schlüsselrolle. SBOMs bieten eine detaillierte Bestandsaufnahme aller Softwarekomponenten. Dies hilft uns nicht nur, unsere Software zu verstehen, sondern ermöglicht uns auch, Risiken zu identifizieren und unsere Compliance- und Governance-Anforderungen zu erfüllen.
Damit SBOMs effektiv sind, müssen sie standardisiert und über verschiedene Systeme und Tools hinweg einfach austauschbar sein. Hier spielen SBOM-Standards eine entscheidende Rolle.
SBOM-Standards verstehen
SBOM-Standards legen ein gemeinsames Format für die Erstellung und den Austausch von SBOM-Daten fest. Sie bieten eine einheitliche Sprache und gewährleisten so eine konsistente Kommunikation zwischen verschiedenen Organisationen und Tools.
Standardisierung ist notwendig, da SBOMs umfangreich sein und detaillierte Informationen über Komponenten, Versionen, Lizenzen und Abhängigkeiten enthalten können. Ohne ein Standardformat wird die Interpretation und Nutzung von SBOM-Daten für verschiedene Akteure schwierig.
Aktuell sind drei wichtige SBOM-Standards in der Branche verbreitet:
- CycloneDX: Ein leichter Standard mit Fokus auf Sicherheit, der verschiedene BOM-Typen unterstützt, einschließlich Software, Hardware und Services.
- SPDX (Software Package Data Exchange): Der einzige von der ISO anerkannte SBOM-Standard, bekannt für seinen umfassenden Ansatz bei Komponentendaten und seine Ursprünge im Software-Lizenzmanagement.
- 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-Pipelines 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 der einzige SBOM-Standard mit ISO-Akkreditierung anerkannt, was seine Glaubwürdigkeit erhöht. Ursprünglich für das Software-Lizenzmanagement entwickelt, hat sich SPDX erweitert, um umfassendere Anforderungen an die Softwaretransparenz zu erfüllen.
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: example-sbom
DocumentNamespace: http://spdx.org/spdxdocs/example-sbom
Creator: Tool: SPDX-Tools
Created: 2025-05-08T12:00:00Z
PackageName: example-lib
SPDXID: SPDXRef-Package-example-lib
PackageVersion: 1.0.0Package
DownloadLocation: NOASSERTION
PackageLicenseConcluded: MIT
PackageLicenseDeclared: MIT
PackageChecksum: SHA256: abcdef1234567890abcdef1234567890abcdef1234569uiSWID-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-Standards
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-Standards
Es reicht nicht aus, ein SBOM nur in einem Format zu generieren. Verschiedene Stakeholder – seien es interne Auditoren, Regierungsbehörden oder Unternehmenskunden – benötigen das SBOM möglicherweise in einem bestimmten Format, um es 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-Formate für die Durchsetzung von Richtlinien oder automatisiertes Scanning.
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 Security vereinfachen diesen Prozess, indem sie SBOMs während Ihrer Build-Pipeline oder bei Sicherheitsscans automatisch generieren und diese bei 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.
