SBOM: Die Grundlage für sichere Software-Lieferketten

Beim Lebensmitteleinkauf geht der Blick so gut wie immer auf die entsprechende Produktrückseite, um die Produktzutatenliste zu studieren. Schließlich wollen wir als Verbraucher genau wissen, welche Zutaten sich in unseren Lebensmitteln befinden. In den letzten Jahren und Jahrzehnten haben sich diesbezüglich die Deklarierungspflichten stark verschärft.

Der Hersteller muss genau angeben, welche Zutaten also aus welchen Komponenten der leckere Joghurt besteht und wie viel Zucker in der süßen Schokolade ist. Das Ziel ist es, dem Konsumenten eine Transparenz zu geben, aus welchen Inhaltsstoffen das Produkt besteht.

Genau die gleiche Idee gibt es in der Softwareentwicklung. Bei den Produkten handelt es sich jedoch um Smartphone-Apps, SaaS-Produkte, IoT-Produkte oder generell um jedes Produkt, in dem Software verbaut ist. Die Zutatenliste heißt in diesem Fall SBOM (Software Bill of Materials).

In diesem Blogartikel geht es darum, zu erläutern, was eine SBOM konkret ist, welche Spezifikationen es gibt und wie eine SBOM erstellt werden kann. Weiterhin gehe ich darauf ein, warum das Thema SBOM durch den Cyber Resilience Act in Zukunft immer wichtiger und teilweise sogar verpflichtend wird.

Eine SBOM ist eine detaillierte Inventarliste an allen Komponenten, welche in der jeweiligen Software benutzt wurden. Das sind vor allem Open-Source Komponenten, es können jedoch auch proprietäre Komponenten sein. Die Struktur einer SBOM ist standardisiert und folgt entweder dem SPDX oder CycloneDX Standard. Das Format ist entweder XML oder JSON, wobei JSON deutlich häufiger in der Praxis zu finden ist. Ein Vorteil der Standardisierung ist die Maschinenlesbarkeit. Eine SBOM kann meistens ohne Probleme von einem Tool erstellt werden und von einem komplett anderen weiterverarbeitet, wenn der Standard eingehalten wird.

Was ist eine SBOM?

Eine SBOM ist eine detaillierte Inventarliste an allen Komponenten, welche in der jeweiligen Software benutzt wurden. Das sind vor allem Open-Source Komponenten, es können jedoch auch proprietäre Komponenten sein. Die Struktur einer SBOM ist standardisiert und folgt entweder dem SPDX oder CycloneDX Standard. Das Format ist entweder XML oder JSON, wobei JSON deutlich häufiger in der Praxis zu finden ist. Ein Vorteil der Standardisierung ist die Maschinenlesbarkeit. Eine SBOM kann meistens ohne Probleme von einem Tool erstellt werden und von einem komplett anderen weiterverarbeitet, wenn der Standard eingehalten wird.

Welche Bestandteile hat eine SBOM?

Eine SBOM gibt nicht nur an, welche Komponenten für das entsprechende Softwareprodukt verwendet wurden, sondern auch welche Abhängigkeiten diese hat. Das bedeutet beispielsweise, dass nicht nur die tatsächlich genutzten Bibliotheken aufgelistet werden, sondern auch welche weiteren Abhängigkeiten die eingesetzte Bibliothek benötigt haben. Diese Abhängigkeiten nennt man Transitive Abhängigkeiten. Des Weiteren verfügen die SBOM Standards CycloneDX und SPDX um jede Menge Properties, mit denen die Komponenten beschrieben werden können: Hier eine Liste der wichtigsten Attribute, um die Komponenten detailliert zu beschreiben:

• Component name
• Component version
• PURL
• CPE
• Copyright
• Author
• Dependencies
• Description
• Associated Licenses
• External References
• Hash Value
• Type of the component (e.g. Library)

Die Auflistung ist auf Englisch, um einen besseren Bezug zu den Standards zu gewährleisten. Die hier genannten Attribute stellen nur einen Ausschnitt dar. Hier findest du den aktuellen CycloneDX Standard.

Zusätzlich hat sie SBOM an sich weitere Eigenschaften, welche zum Teil auch mandatory sind. Ein sehr verkürztes Beispiel für eine SBOM findest du hier:

{
    "bom-ref": "brick/math-0.9.3.0",
    "type": "library",
    "name": "math",
    "version": "0.9.3",
    "group": "brick",
    "description": "Arbitrary-precision arithmetic library",
    "licenses": [
        {
            "license": {
                "id": "MIT"
            }
        }
    ],
    "purl": "pkg:composer/brick/math@0.9.3",
    "externalReferences": [
        {
            "type": "distribution",
            "url": "https://api.github.com/repos/brick/math/zipball/ca57d18f028f84f777b2168cd1911b0dee2343ae"
        }
    ]
}

Warum ist eine SBOM wichtig?

Die Wichtigkeit einer SBOM ist in den letzten Jahren stark gestiegen. Der Grund dafür ist unter anderem die vermehrte Verwendung von Open-Source Softwarekomponenten innerhalb der Softwareentwicklung. 96 % aller Softwareapplikationen enthalten Open-Source Softwarekomponenten, Tendenz steigen. Mehr als 20,000 neue Softwarekomponentenversionen gibt es täglich! Ich habe in den letzten Jahren kein einziges Softwareprojekt ohne Open-Source begleitet und aufgrund der aktuellen geopolitischen Situation (Stand April 2025) wird Open-Source in der Zukunft noch wichtiger werden. Mit der steigenden Nutzung von Open-Source Softwarekomponenten kommen neue Herausforderungen. Auf diese Herausforderungen möchte ich kurz eingehen:

Hierbei ist vor allem das Thema Lizenzen, also unter welchen Bedingungen Open-Source Komponenten genutzt werden dürfen, zu beachten.

Transparenz

In der Einleitung habe ich das Beispiel einer Zutatenliste von einem Lebensmittelprodukt erläutert. Das Ziel ist hier dem Konsumenten die Möglichkeit zu geben zu verstehen, aus welchen Bestandteilen das Produkt besteht. Diese Transparenz bietet die SBOM ebenfalls. Das hat Vorteile für das Unternehmen, welches die Software entwickelt, für den Käufer einer Software oder auch für den Endnutzer, welche die Software am Ende benutzt. Wie auch bei einem Lebensmittelprodukt ist es ohne die Zutatenliste einer externen Person sonst nichts möglich zu erkennen, aus welchen Bausteinen das Produkt besteht. Diese Transparenz ist die Grundlage für die Themen Sicherheit und Compliance.

Sicherheit

Mit der steigenden Anzahl von verwendeten Open-Source Softwarekomponenten steigt auch die potenzielle Anzahl an möglichen Schwachstellen. Software ist lebendig und entwickelt sich immer weiter. Das bedeutet, dass implementierte Open-Source Softwarekomponenten Schwachstellen aufweisen können. Diese Schwachstellen müssen bestenfalls vor dem Release erkannt und gefixed werden. Allerdings ist damit das Thema nicht erledigt. Schwachstellen können auch nach dem Produktrelease für genutzte Open-Source Softwarekomponenten auftreten. In dieser Situation muss schnell erkannt werden, ob die entsprechende Komponente benutzt wird, in welchen Produkten sie benutzt wird, ob sie in dem Kontext vulnerabel ist und wie möglichst schnell die Schwachstellen gefixed werden können. Eine Beseitigung der Schwachstelle erfolgt in der Regel durch eine neue Version der Open-Source Softwarekomponente oder im schlimmsten Fall durch den kompletten Austausch.

Compliance

Beim Thema Compliance sind zwei Themen zu berücksichtigen. Einmal geht es um die jeweiligen Lizenzen, welche mit dem Einsatz einer Open-Source Softwarekomponenten zu beachten sind. Zum Anderen geht es um die regulatorischen Bedingungen, eine SBOM zu erstellen und diese zu veröffentlichen. Eine Open-Source Softwarekomponente kommt in der Regel mit der Lizenz, welche oftmals vom Autor ausgewählt wird. Eine Lizenz ist eine Art Vertrag zwischen dem Anbieter der Software, also dem Author der Open-Source Komponente und dem Nutzer. Das Thema Lizenzen kann sehr kompliziert werden und hier tummeln sich gefährliche Fallstricke, welche beispielsweise zur Offenlegung des gesamten Source Codes führen können.

Der Cyber Resilience Act betont nochmal die Wichtigkeit der SBOM. Eine SBOM ist spätestens ab 2027 verpflichtend zu erstellen und ggf. zur Verfügung zu stellen. Das gilt für jedes digitale Produkt, welches innerhalb der EU verkauft werden soll. Der Cyber Resilience Act gibt eine sehr genaue Definition vor, wie diese SBOM auszusehen hat. In dem Blogartikel Cyber Resilience Act und Cyber Resilience Act und SBOM findest du weitere Informationen.

Vorteile einer SBOM für Unternehmen

Neben den regulatorischen Anforderungen, eine SBOM zu erstellen und zur Verfügung zu stellen, hat eine SBOM und die Weiterverarbeitung der darin enthaltenen Daten für die Unternehmen wichtige Vorteile. Mit anderen Worten es lohnt sich, eine SBOM zu erstellen und mit den Daten zu arbeiten auch ohne regulatorischen Druck.

Risikomanagement

Peter Drucker sagt: “You can’t manage what you can’t measure.”

Zwar messen wir in diesem Sinne keine Metriken, allerdings brauchen wir eine transparente Übersicht über eingesetzte Softwarekomponente. Nur damit kann während der Softwareentwicklung und vor allem vor Softwarerelease sichergestellt werden, Komponenten ohne Schwachstellen und zu akzeptierten Lizenzbedingungen zu nutzen. In der Praxis wird es dennoch Komponenten geben, welche ggf. Schwachstellen haben oder eine entsprechende Lizenz. In diesem Fall muss im Rahmen eines Risikomanagements entschieden werden, wie mit diesem Risiko umgegangen wird. Ohne eine SBOM und die Übersicht der verwendeten Softwarekomponenten wäre jedoch eine Risikobeurteilung überhaupt nicht möglich.

Effizienz

Bei dem Auftreten einer sicherheitsrelevanten Schwachstelle geht es vor allem um eine schnelle Reaktion. Es muss zügig geklärt werden, ob die verwundete Komponente verbaut wurde und in welchem Softwareprodukt diese existiert. Je nach Produkt und Schwachstelle muss entweder die Sicherheitslücke schnell gelöst werden und eine entsprechende Kommunikation an Kunden und Nutzer bereitgestellt werden. Wichtig ist aber, dass zeitnah gehandelt werden kann und nicht eine komplette Organization lahm gelegt wird, um zu erkennen, ob eine Softwarekomponente genutzt wurde oder nicht.

Vertrauen

Der Einsatz von SBOMs und den dazugehörigen Prozessen wie zum Beispiel einem Open Source Compliance Program sorgt für Vertrauen bei Kunden und Partnern. Es gibt ein Indiz darüber wie sorgfältig im Allgemeinen die Softwareentwicklung ist und wie sauber die Dokumentation ist. Gerade bei Produkten, welche hinsichtlich Vertraulichkeit, Integrität oder Verfügbarkeit einen erhöhten Schutzbedarf haben, ist eine sorgfältige Arbeit und ordentliche Dokumentation zwingend erforderlich.

Fazit

In diesem Blogartikel ist beschrieben, was eine SBOM ist und welche Vorteile diese Unternehmen bieten. Die SBOM ist Grundlage für eine sichere Nutzung von Open-Source Softwarekomponenten und risikobasierten Entscheidungen im Fall von gefundenen Schwachstellen. Eine SBOM bietet mir Transparenz über meine eingesetzten Komponenten, welche mir viele nachgelagerte Diskussionen erst ermöglichen.

Das Thema steht erst am Anfang, das zeigt auch die steigende Anzahl an Tools, welche sowohl die Erstellung, als auch die Weiterverarbeitung ermöglichen. Mit dem Cyber Resilience Act gewinnt das Thema SBOM auch in europäischen Unternehmen weiter an Priorität.

SecuraPoint bietet ein Open Source Compliance Programm an, mit dem wir dich und dein Unternehmen an die Hand nehmen, um Open Source Komponenten sicher zu nutzen. Dazu gehört natürlich auch die Toolunterstütze Erstellung einer SBOM.

In Kürze erscheinen weitere Blogartikel rund um das Thema SBOM, Open Source Compliance und Cyber Resilience Act.

Melde dich gerne bei weiteren Fragen.