Moderne Anwendungen sind keine riesigen Monolithen mehr, sondern eine Sammlung von Mikrodiensten, Open-Source-Komponenten und Tools von Drittanbietern. Dies macht es jedoch sehr schwierig, das Innenleben unserer Anwendungen zu verstehen, insbesondere wenn man bedenkt, dass unsere Open-Source-Abhängigkeiten auch Open-Source-Abhängigkeiten haben!
Die Software Bill of Materials (SBOM) spielt dabei eine Schlüsselrolle. SBOMs liefern ein detailliertes Inventar aller Softwarekomponenten. Dies hilft uns nicht nur, unsere Software zu verstehen, sondern ermöglicht uns auch, Risiken zu erkennen und unsere compliance und Governance-Anforderungen zu erfüllen.
Damit SBOMs gut funktionieren, müssen sie standardisiert sein und leicht über verschiedene Systeme und Werkzeuge hinweg ausgetauscht werden können. An dieser Stelle werden SBOM-Standards wichtig.
Verständnis der SBOM-Standards
SBOM-Standards legen ein gemeinsames Format für die Erstellung und den Austausch von SBOM-Daten fest. Sie bieten eine einheitliche Sprache, die eine konsistente Kommunikation über verschiedene Organisationen und Werkzeuge hinweg gewährleistet.
Eine Standardisierung ist notwendig, da SBOMs sehr umfangreich sein können und viele Details über Komponenten, Versionen, Lizenzen und Abhängigkeiten enthalten. Ohne ein Standardformat wird die Interpretation und Verwendung von SBOM-Daten für verschiedene Unternehmen zur Herausforderung.
Derzeit sind in der Branche drei SBOM-Standards verbreitet:
- CycloneDX: Ein leichtgewichtiger Standard mit Schwerpunkt auf Sicherheit, der verschiedene Stücklistentypen unterstützt, darunter Software, Hardware und Dienstleistungen.
- SPDX (Software Package Data Exchange): Der einzige von der ISO anerkannte SBOM-Standard, bekannt für seinen umfassenden Ansatz für Komponentendaten und seine Ursprünge in der Softwarelizenzierung.
- SWID-Etiketten (Software-Identifizierung): Konzentriert sich auf die Software-Identifizierung und hilft bei der Verfolgung installierter Software für die Bestandsverwaltung.
Jede Norm hat spezifische Stärken und Anwendungsfälle, die wir im Folgenden erörtern werden.
CycloneDX auf einen Blick
- Speziell für Sicherheitszwecke entwickelt (z. B. Aufspüren von Schwachstellen, VEX-Unterstützung, Komponenten-Hashing).
- Unterstützt nativ VEX (Vulnerability Exploitability eXchange) und Abhängigkeitsstrukturen.
- Kompatibel mit modernen DevSecOps-Pipelines und Tools wie OWASP Dependency-Check, Anchore, GitHub Advanced Security.
- Leichtere Integration in CI/CD-Umgebungen (leichtgewichtig, JSON-freundlich).
CycloneDX zeichnet sich durch seine Effizienz und robusten Sicherheitsfunktionen aus. Sein Design ermöglicht eine schnelle Integration und ist damit ideal für Teams, die Wert auf Flexibilität und Sicherheit legen. CycloneDX deckt Software, Hardware und dienstleistungsbezogene Materialien ab und ist damit vielseitig für unterschiedliche Technologieumgebungen einsetzbar.
CycloneDX unterstützt mehrere Datenformate, darunter XML, JSON und Protobuf, und gewährleistet so die Kompatibilität mit verschiedenen Tools. Unter dem Dach der OWASP wird CycloneDX kontinuierlich weiterentwickelt, um aktuelle Sicherheitsherausforderungen in Software-Lieferketten anzugehen.
Beispiel für die 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 erforschen
- Ausgerichtet auf Rechtsteams und IP-Due-Diligence-Prüfungen (starkes Lizenzierungs-Metadatenmodell).
- Umfangreiche Lizenzausdruckssprache (SPDX-Lizenzliste).
- Genormt unter ISO/IEC 5962:2021.
- Wird in großen Projekten wie OpenChain, ORT und Tern verwendet.
SPDX ist weltweit als einziger SBOM-Standard mit ISO-Akkreditierung anerkannt, was seine Glaubwürdigkeit unterstreicht. Ursprünglich für die Softwarelizenzierung entwickelt, wurde SPDX erweitert, um breitere Anforderungen an die Softwaretransparenz zu erfüllen.
SPDX unterstützt mehrere Datenformate wie Tag/Wert, JSON, XML, YAML und RDF und lässt sich problemlos in verschiedene Tools und Plattformen integrieren. Es bietet tiefe Einblicke in Softwarekomponenten und dokumentiert Dateien und Codeschnipsel für eine detaillierte compliance und Sicherheitsverfolgung.
Beispiel für die SPDX-Formatierung
SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
Dokumentenname: beispiel-sbom
DocumentNamespace: http://spdx.org/spdxdocs/example-sbom
Ersteller: Tool: SPDX-Tools
Erstellt: 2025-05-08T12:00:00Z
Paketname: beispiel-lib
SPDXID: SPDXRef-Paket-example-lib
PaketVersion: 1.0.0Paket
DownloadStandort: NOASSERTION
PaketLizenzGeschlossen: MIT
PackageLicenseDeclared: MIT
PackageChecksum: SHA256: abcdef1234567890abcdef1234567890abcdef1234569ui
Verstehen von SWID-Tags
- Ausgerichtet auf die Software-Bestandsverwaltung in Unternehmen.
- Genormt als ISO/IEC 19770-2 - sehr auf Behörden/Militärs ausgerichtet.
- Verwendet in FedRAMP, NIST 800-171 und verwandten compliance .
SWID-Tags konzentrieren sich auf eine klare Abgrenzung der Softwareprodukte. Im Gegensatz zu umfassenden SBOMs identifizieren SWID-Tags einzelne Softwarepakete, die für eine genaue Bestandsverwaltung entscheidend sind.
In der Anlagenverwaltung bieten SWID-Tags eine standardisierte Methode zur Verfolgung von Software-Installationen und stellen sicher, dass Unternehmen eine genaue Software-Landschaft pflegen. Dies hilft bei der compliance und der Optimierung von Asset-Management-Strategien.
SWID-Tags lassen sich in Rahmenwerke wie SCAP- und TCG-Standards integrieren, was ihre Rolle in Bezug auf Sicherheit und compliance stärkt.
Beispiel für die 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>
SBOM-Standards im Vergleich
Um CycloneDX, SPDX und SWID Tags zu unterscheiden, sollten Sie mit ihren Funktionen beginnen. CycloneDX eignet sich für die flexible Stücklistenverwaltung in dynamischen Sicherheitsumgebungen. SPDX zeichnet sich durch die Verfolgung der compliance aus, während sich SWID Tags auf die präzise Identifizierung von Software konzentrieren. Hier ist ein kurzer Vergleich:
Die Struktur von CycloneDX trägt dem Bedürfnis nach Transparenz Rechnung. SPDX bietet eine detaillierte Dokumentation und Datenintegrität für die Überwachung der compliance .
Jeder Standard entspricht spezifischen Anforderungen. CycloneDX eignet sich für Teams, die Wert auf schnelle und sichere Entwicklung legen. SPDX eignet sich für Unternehmen, die auf die compliance achten. SWID-Tags verbessern das Asset-Management, indem sie eine präzise Verfolgung gewährleisten.
Konvertierungstools zwischen diesen Formaten sind für die Aufrechterhaltung der Interoperabilität unerlässlich. Mit fortschrittlichen Lösungen können Unternehmen von den Stärken der einzelnen Standards profitieren und ihre Strategien an die jeweiligen Anforderungen anpassen.
Die Wahl des richtigen SBOM-Standards
Es reicht nicht aus, eine SBOM in nur einem Format zu erstellen. Verschiedene Interessengruppen - seien es interne Prüfer, Behörden oder Unternehmenskunden -benötigen die SBOM möglicherweisein einem bestimmten Format, um sie in ihre bestehenden Tools oder Arbeitsabläufe einzubinden. Zum Beispiel:
- Ein Bundesvertrag kann SPDX erfordern, während ein Sicherheitsanbieter, der eine Risikobewertung durchführt, CycloneDX vorzieht.
- Einige CI/CD-Systeme unterstützen möglicherweise nur bestimmte SBOM-Formate für die Durchsetzung von Richtlinien oder die automatische Überprüfung.
Werkzeuge sind wichtig: Wählen Sie eines, das mehrere Formate unterstützt
Angesichts dieser Variabilität müssen Sie ein Werkzeug wählen, das SBOMs in mehreren Formaten aus denselben Quellartefakten erzeugen kann. Werkzeuge wie Aikido Sicherheit vereinfachen diesen Prozess, indem sie während der Build-Pipeline oder bei Sicherheitsscans automatisch SBOMs generieren und sie je nach Bedarf in Formate wie CycloneDX, SPDX und andere exportieren.
Diese Multiformat-Fähigkeit stellt sicher, dass Sie bei unterschiedlichen Anforderungen konform bleiben, ohne dass es zu Doppelarbeit oder Fehlern durch manuelle Konvertierungen kommt.