SBOM – Software Bill of Materials einfach erklärt

Autor Christian Ehrmann · Stand 28.08.2026 · https://www.catenis.de/lexikon/sbom

Bei Zitat URL und Abrufdatum angeben. Keine Rechtsberatung.

Was es ist

Eine Software Bill of Materials listet Bestandteile und Herkunft einer Software; der CRA macht solche Transparenz zur Erwartung, Kunden fragen sie im Cyber-Premium-Fragebogen nach. Die SBOM belegt die Zusammensetzung, sie gibt die Software nicht frei.

Die Stückliste nennt Komponenten, Versionen, oft Lizenzen und Lieferanten der Bausteine. Sie beantwortet „was steckt drin?“, nicht „ist es sicher?“. Eine bekannte Schwachstelle in einer genannten Library wird auffindbar. Eine fehlende Zeile verschiebt das Risiko in die Blindheit.

Der CRA macht diese Transparenz zur Erwartung an Produkte mit digitalen Elementen. Kunden aus Industrie und regulierten Branchen fragen sie früher, oft ohne selbst Hersteller zu sein. Catenis holt die Frage und die Datei im Cyber-Premium-Fragebogen ein. Es prüft die SBOM nicht automatisch gegen CVE-Listen.

Freigabe der Software bleibt ein anderer Akt: Test, Review, Vertrag, im CRA-Fall die Konformitätsarbeit. Wer die Stückliste mit einer Abnahme verwechselt, lässt unsichere Versionen in die Linie, nur weil die Liste vollständig wirkt.

Firmware und Container-Images gehören dazu, sobald sie mitgeliefert werden. Eine SBOM nur für die Windows-Hilfssoftware, während die Steuerung ungeprüft bleibt, beantwortet die Kundenfrage nicht. Catenis speichert, was hochgeladen wird. Es prüft nicht, ob das Artefakt vollständig ist.

Herkunft meint oft Lieferant der Komponente und Quelle des Codes, nicht das Land als Slogan. Eine Zeile ohne Version und ohne Lieferantenname trägt die nächste CVE-Suche nicht.

Geltungsbereich

Hersteller und bestimmte Inverkehrbringer müssen die Zusammensetzung nachvollziehbar halten. Betreiber und Einkauf brauchen sie, um Erwerb, Wartung und Lieferkette nach NIS-2 zu steuern. Dieselbe Datei bedient beide Seiten, wenn Version und Produkt übereinstimmen.

Formate (CycloneDX, SPDX und andere) sind Werkzeugfrage. Entscheidend ist: Bezug auf genau das gelieferte Artefakt, Datum, wer erzeugt hat. Eine generische Liste „unser Produkt enthält Open Source“ ohne Version ist keine SBOM.

DORA kann im Finanzkreis ähnliche Transparenz zu IKT-Dritten verlangen. Das ändert den Adressaten, nicht die Dateilogik. Catenis hat kein DORA-Modul; die Datei hängt am Premium-Bogen und an der Lieferantenakte.

Eigenentwicklung, zugekaufte Libraries und Cloud-Dienste mischen sich in einer Liste. Wer SaaS nutzt, bekommt oft keine klassische SBOM, sondern eine Aussage des Anbieters. Die Lücke gehört in die Akte, nicht in eine erfundene Datei. Der Bogen darf „nicht lieferbar“ tragen, wenn das Datum und die Begründung da sind.

Mehrere Versionen im Feld (Altgeräte, Patchstände) brauchen mehrere Bezüge. Eine Liste „gilt für alle Generationen“ ist später die erste, die ein Auditor zerlegt.

Was zu tun ist

Von Software- und Gerätepartnern eine SBOM zum konkreten Lieferstand verlangen. In Catenis im Premium-Bogen ablegen, mit Datum. Fehlt sie, die Lücke offen halten, nicht mit einem Whitepaper ersetzen.

Intern klären, wer die Liste liest: IT-Sicherheit bei eigenen Systemen, Einkauf bei Zulauf. Eine Datei ohne Leser ist Dekoration. Schwachstellenprozesse bleiben außerhalb – Scanner, Tickets, Patch.

Die NIS-2-Maßnahme Erwerb und Wartung mit der SBOM verknüpfen, wo Software eingekauft wird. Ohne Zusammensetzung ist Schwachstellenverantwortung eine Parole.

Bei eigener Herstellung die Erzeugung der SBOM in die Build-Kette legen, nicht in eine einmalige Excel. Catenis speichert den Nachweis für den Kunden, es erzeugt die Liste nicht aus dem Quellcode.

Ablauf und Ersatzstand führen. Eine SBOM ohne Datum veraltet mit dem nächsten Patch. In Catenis den Nachweis wie jedes andere Dokument mit Frist behandeln. Fehlt der Nachzug, die Ampel nicht grün lassen.

Weitergabe an den eigenen Kunden nur mit dem Stand, der zur gelieferten Version passt. Eine interne Vollständigkeitsliste und eine geglättete Kundenfassung zu mischen, ohne das zu kennzeichnen, zerlegt das Vertrauen beim ersten Diff.

Scanner und Tickets außerhalb halten, die SBOM in Catenis als Nachweis. Die Liste zeigt die Bestandteile. Das Ticket zeigt, was dagegen getan wurde. Beides verwechseln heißt, eine vollständige Datei als geschlossene Schwachstelle zu verkaufen.

Typischer Fehler

Der häufigste Fehler: eine Stückliste aus dem Marketingjahr an einen Build von diesem Quartal zu heften. Der zweite: die SBOM als Freigabe zu behandeln und den Pen-Test oder das Review zu streichen. Der dritte: nur Direct Dependencies zu listen und Transitives zu verschweigen, obwohl genau dort die alte Library sitzt.

Wer die Datei intern nicht wiederfindet, wenn der Kunde nachfasst, hat denselben Stand wie ohne SBOM.

Der vierte: eine Lizenzliste als SBOM zu verkaufen. Lizenzen sind Teil, nicht das Ganze. Der fünfte: die Datei nur per Mail zu haben und in Catenis „liegt vor“ zu klicken, ohne Upload. Beim nächsten Owner ist sie weg. Wer eine Liste ohne Versionsbezug weitergibt, hat dem Kunden eine andere Software beschrieben als geliefert.

Grenze

Das Lexikon sagt nicht, welches SBOM-Format Pflicht ist oder ob eine konkrete Liste vollständig ist.

Catenis fragt und speichert die SBOM als Nachweis im Premium-Bogen. Es gibt die Software nicht frei, bewertet keine Konformität und spricht nicht mit Behörden. Die Liste belegt die Zusammensetzung zum genannten Stand, sonst nichts.