SBOM: einfach erklärt

Dieser Begriff gehört zur Vertiefung „OT-Security und Regulierung“ und ist nicht in der App enthalten.

Kurzdefinition

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste der Softwarekomponenten eines Produkts: Bibliotheken, Betriebssystemteile, Open-Source-Pakete, jeweils mit Name, Version und Herkunft. Sie zeigt, was in einer Firmware oder Anwendung steckt.

Schematische Grafik: aus einem Produkt wird eine Software-Stückliste mit Bibliotheken, Versionen, Lizenzen und Lieferanten, die gegen Schwachstellen abgeglichen wird; gängige Formate SPDX und CycloneDX.
Grafik: DMNK Digital, KI-erstellt

Erklärung

Moderne Steuerungen, Bediengeräte, Switches und Gateways enthalten eine Menge fremder Software: ein eingebettetes Betriebssystem, einen Webserver, Kryptobibliotheken, Protokollstacks. Wird in einer dieser Komponenten eine Schwachstelle bekannt, lautet die erste Frage: Welche unserer Produkte oder Geräte sind betroffen? Ohne SBOM ist das oft mühsame Recherche, mit SBOM eine Suche in einer Liste.

Eine SBOM enthält pro Komponente typischerweise den Namen, die Version, den Lieferanten bzw. die Herkunft, eine eindeutige Kennung und die Abhängigkeiten untereinander. Verbreitete Formate sind SPDX (als ISO/IEC 5962 genormt) und CycloneDX. Beide lassen sich automatisch aus dem Build-Prozess erzeugen und von Werkzeugen auswerten.

SBOM und CRA: Der Cyber Resilience Act verlangt in seinen Anforderungen an die Behandlung von Schwachstellen (Anhang I, Teil II), dass Hersteller die Komponenten ihrer Produkte identifizieren und dokumentieren, unter anderem mit einer SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Ein bestimmtes Format schreibt die Verordnung nicht vor. Die SBOM gehört zur technischen Dokumentation; eine allgemeine Pflicht, sie zu veröffentlichen, besteht nicht. Diese Pflicht gilt mit den Hauptpflichten ab 11.12.2027. Das BSI beschreibt in der Technischen Richtlinie TR-03183-2 (aktuell Version 2.1.0) formale und technische Anforderungen an SBOMs. Die Richtlinie ist eine Orientierungshilfe zur Vorbereitung auf den CRA, aber nicht verbindlich und kein Nachweis der Konformität.

SBOM in der OT-Praxis: Für Betreiber ist die SBOM ein Werkzeug, kein Selbstzweck. Zusammen mit dem Asset-Inventar (welches Gerät mit welcher Firmware steht wo?) zeigt sie, welche Anlagen von einer Schwachstelle betroffen sein könnten. Ergänzend gibt es VEX-Dokumente (Vulnerability Exploitability eXchange), in denen Hersteller angeben, ob eine bekannte Schwachstelle in ihrem Produkt tatsächlich ausnutzbar ist. So lassen sich Fehlalarme vermeiden.

Eine SBOM ist immer eine Momentaufnahme eines bestimmten Software- oder Firmwarestands. Mit jedem Update ändert sie sich und muss mitgepflegt werden.

Praxisbeispiel

Eine Schwachstelle in einer verbreiteten Kryptobibliothek wird veröffentlicht. Ein Hersteller von Bediengeräten durchsucht die SBOMs aller ausgelieferten Firmwarestände und findet die betroffene Version in zwei Gerätereihen. Ein Betreiber gleicht die Herstellerinformation mit seinem Inventar ab: Drei Panels in Halle 1 laufen mit dem betroffenen Stand. Laut VEX-Angabe ist die Lücke nur ausnutzbar, wenn der Webserver aktiv ist. Der Betreiber prüft das und deaktiviert den Webserver, bis das Update freigegeben ist.

Typische Fehler

  • SBOM einmal erstellen und vergessen. Nach dem nächsten Release stimmt sie nicht mehr.
  • Nur eigenen Code erfassen. Gerade die Fremd- und Open-Source-Komponenten sind interessant.
  • SBOM ohne Inventar. Der Betreiber weiß, was im Produkt steckt, aber nicht, wo das Produkt steht.
  • Jeden Treffer als Notfall behandeln. Nicht jede gelistete Schwachstelle ist im Produkt ausnutzbar.
  • Format ohne Werkzeug. Eine SBOM als PDF lässt sich nicht automatisch auswerten.

Verwandte Begriffe

Praxisnotiz von Dominik

Ich frage Lieferanten inzwischen gezielt, ob sie zu ihren Geräten eine SBOM oder VEX-Angaben bereitstellen können, und in welchem Format. Die Antwort sagt mir einiges darüber, wie ein Lieferant mit dem Thema Schwachstellen umgeht. Für meine Arbeit zählt am Ende, dass ich die Angaben mit meinem Inventar abgleichen kann.

Weiterlesen im Blog

Quellen

Stand: 10/2026 · keine Rechtsberatung · Normen werden nur referenziert, nicht zitiert.