Über unsMediaKontaktImpressum
Marcel Isenmann & Manuel Pfemeter 13. Februar 2024

SBOM mit CycloneDX – Überwachung der Software-Lieferkette

Das Arbeiten mit Software Bill of Materials (SBOM) kann sehr hilfreich sein. In der heutigen Software-Landschaft ist Transparenz in der Lieferkette von entscheidender Bedeutung. Aus Gründen der Cyber-Sicherheit wurden bereits erste Richtlinien von Regierungen für die Software-Entwicklung und Leitfäden zur Generierung einer SBOM erstellt [1].

So wie die Bill of Materials (BOM, Deutsch: Stückliste) sich als De-facto-Standard im produzierenden Gewerbe etabliert hat, so passiert das auch im Bereich der Software-Entwicklung mit der SBOM. Die Herausforderungen umfassen Standardisierung von Metadaten und deren Integration in den Software-Lifecycle. Ziel ist die Verbesserung der Sicherheit, Interoperabilität, Automatisierung und Überwachung innerhalb der Lieferkette. Als gängige Praxis hat sich dabei die Verwendung von SBOM durchgesetzt. Wir wollen einen tieferen Einblick in SBOM geben und dies am Beispiel von CycloneDX verdeutlichen.

Wie sollte eine SBOM aussehen?

Eine SBOM sollte Eigenschaften aufweisen, die zur Identifikation und Analyse aller Software-Artefakte beitragen. Folgende Informationen und Kriterien sind dazu wichtig:

  • Darstellung von Metainformationen: SBOM-Format, Herstellernamen, Komponentennamen, Komponentenversion, Abhängigkeiten, Zeitstempel
  • Automatisierungsunterstützung: menschen- und maschinenlesbare Formate, wie z. B. SPDX, CycloneDX oder SWID Tag
  • Auflistung von Komponenten, Lizenzen, Vulnerabilities und Dependencies

Beispiel einer SBOM auf Basis von CycloneDX

CycloneDX ist eine leichtgewichtige Spezifikation, die zum Einsatz im Bereich Software-Sicherheit und Komponentenanalyse entworfen wurde. Mit CycloneDX können SBOM generiert werden. Die Besonderheit ist die menschen- und maschinenlesbare sowie weiterverarbeitende Aufbereitung der Daten. Deshalb empfehlen wir die Verwendung eines offenen Standards. Die SBOM wird in Form von XML oder JSON abgebildet und kann daher einfach mit dem menschlichen Auge gelesen werden. Weitere Details zum umfangreichen Format und den spezifizierten Versionen können der entsprechenden CycloneDX-Website entnommen werden [2]. Eine mit CycloneDX erstellte SBOM für ein .NET-Modul sieht wie folgt aus:

Listing 1: Beispiel-SBOM generiert mit CycloneDX

Beispiele für Überwachungs- und Lizenzüberprüfungen

Für die verwendeten Komponenten innerhalb der SBOM existiert eine Beschreibung mit Auflistung der Lizenzen als SPDX-License-ID. Im Weiteren besteht damit die Möglichkeit, auf Basis von JSONPath oder XPath alle innerhalb des Software-Produkts verwendeten Lizenzen herauszufinden [3]. Als nächster Schritt kann auf einfache Weise eine Prüfung dieser Lizenzen erstellt werden. Beispielsweise eignen sich hier Schritte innerhalb der Build-Pipeline, sodass eine Validierung bereits kontinuierlich während der Software-Entwicklungsphase stattfindet.

Listing 2: Darstellung der Lizenzen in einer durch CycloneDX generierten SBOM

Warum ist CycloneDX eine gute Wahl?

Moderne Software-Produkte bestehen häufig aus einer Vielzahl an Komponenten, welche heutzutage auf verschiedenen Technologie-Stacks aufgebaut sind; beispielsweise ist Backend-Code auf .NET-Basis in C# und das Frontend in TypeScript geschrieben. Für .NET ist Nuget der Quasistandard in Sachen Paketverwaltung und für JavaScript bzw. TypeScript ist dies NPM. CycloneDX bietet bereits eigene Werkzeuge für diese zwei Technologien zur Erstellung der SBOM.

Die Darstellung einer SBOM ist und sollte technologieunabhängig sein. Für CycloneDX gibt es eine große Anzahl an unterstützten Technologien; neben .NET und NPM sind Implementierungen für gängige Technologien wie z. B. Python, Java, Rust etc. vorhanden. Entsprechende Projekte mit Beispielen wurden von CycloneDX auf GitHub veröffentlicht. Aufgrund der hohen Unterstützung an Technologien können Software-Produkte möglichst vollumfänglich via CycloneDX durch SBOM beschrieben werden.

Visuelle Darstellungen & Management – Licensing und SBOM

Für eine Software-Produktlandschaft und komplexe Software-Produkte ist eine tool-unterstützte Verwaltung von SBOM, Lizenzen und aller produktrelevanten Artefakte hilfreich. Eine visuelle Aufbereitung und Verwaltung von SBOM auf Basis von CycloneDX kann durch Tools wie z. B. in Dependency-Track erreicht werden. Dependency-Track ist eine Open-Source-Plattform und unterstützt damit den unternehmensweiten Einsatz sowie die Integration in Build-Pipelines. Desweiteren gibt es Möglichkeiten zum Management von Schwachstellen und die Definition von Richtlinien zur Evaluierung von Lizenzbestimmungen. Entsprechende Dashboards und visuelle Darstellungen helfen bei der Verwaltung der Software-Artefakte.

Was gibt es noch zu wissen? – SPDX und SWID Tags

CycloneDX ist nicht der einzige Standard. SPDX und SWID sind weitere Möglichkeiten, welche die Darstellung eines SBOM gewährleisten.

  • SPDX ist ursprünglich ein Projekt der Linux Foundation zur Erstellung von SBOM.
  • CycloneDX ist ein Projekt der OWASP Foundation zur Komponentenanalyse in der Software Supply Chain.
  • SWID ist ein Standard zur Erstellung von Software Identification Tags.

Was gibt es noch zu wissen? – xBOM, SaaSBOM, HBOM etc.

CycloneDX unterstützt Erweiterungen des SBOM-Standards. Spezifische xBOM-Formate – mit einem Fokus auf die entsprechende Umgebung – helfen die Software-Lieferkette besser abzubilden. So gibt es beispielsweise ein Format für Software-as-a-Service (SaaSBOM) und ein Format für Hardware (HBOM). Es bestehen weitere Möglichkeiten für den Bereich Software Security (Vulnerability Disclosure Report (VDR) und Vulnerability Exploitability eXchange (VEX)) zur konkreten Analyse. Eine komplette Liste aller unterstützten Formate und deren spezifischer Ausprägungen finden Sie auf der CycloneDX-Website.

Fazit

Im Verlauf des Artikels wurde verdeutlicht, wie eine SBOM mit CycloneDX erstellt wird und wie diese aussieht. Dies ist der erste und wichtigste Schritt zur Verwaltung der Software-Lieferkette. Die Überwachung der Software-Lieferkette ist wichtig, um Schwachstellen und Angriffsvektoren in der Software zu erkennen, Compliance-Verstöße zu vermeiden und die Sicherheit sowie Integrität von Software-Produkten zu gewährleisten. Im Weiteren steht die Mitigation von Risiken im Fokus. Schwachstellen in Abhängigkeiten können erkannt und priorisiert werden. Das hilft Entwicklern und Sicherheitsteams bei der schnellen Identifikation von Schwachstellen und deren Beseitigung in Anwendungen, um so die Sicherheit zu erhöhen.

Autoren
Marcel Isenmann

Marcel Isenmann

Marcel Isenmann ist Software-Entwickler bei der AIT GmbH & Co. KG. Er unterstützt Firmen bei der Realisierung von individuellen Software-Lösungen auf Basis von .NET, Azure und Azure DevOps.
>> Weiterlesen
Manuel Pfemeter

Manuel Pfemeter

Manuel Pfemeter ist ein erfahrener IT Solution Architect bei der AIT GmbH & Co. KG. Er verfügt über mehr als ein Jahrzehnt Fachkenntnisse in Systemarchitektur und Cloud Computing.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben