Software-Stücklisten werden für Hersteller digitaler Produkte zur Pflicht, doch ihr Nutzen steht und fällt mit ihrer Nachprüfbarkeit. Eine SBOM zeigt zwar, welche Komponenten enthalten sein sollen, beweist aber weder Herkunft noch Unverändertheit. Digitale Signaturen können diese Lücke schließen, wenn sie sauber in Build-, Freigabe- und Lieferkettenprozesse eingebettet sind.

Software Bills of Materials, kurz SBOMs, entwickeln sich von einer freiwilligen Best Practice zur festen Anforderung. Ab dem 11. Dezember 2027 verpflichtet der Cyber Resilience Act Hersteller von Produkten mit digitalen Elementen dazu, eine maschinenlesbare Software-Stückliste zu erstellen, aktuell zu halten und in die technische Dokumentation aufzunehmen. Damit ist jedoch erst eine Frage beantwortet: Welche Komponenten sollen in der Software enthalten sein? Für einen belastbaren Sicherheitsnachweis müssen Unternehmen noch drei weitere Fragen klären: Gehört die SBOM tatsächlich zu dieser Produktversion? Wer hat sie erstellt? Und wurde sie seitdem verändert?

Eine unsignierte SBOM bleibt eine Behauptung.

Eine SBOM kann formal korrekt aussehen und trotzdem veraltet, unvollständig oder manipuliert sein. Auch ein sicherer Übertragungsweg löst dieses Problem nur teilweise. Er schützt Daten während der Übertragung, sagt aber wenig darüber aus, was davor oder danach mit ihnen geschehen ist.

Eine digitale Signatur setzt genau hier an. Sie bindet den Inhalt der SBOM kryptografisch an eine Identität. Bei der Prüfung lässt sich feststellen, ob die Datei seit der Signatur verändert wurde und ob sie vom erwarteten Aussteller stammt. Das ist besonders wichtig, wenn SBOMs zwischen Herstellern, Zulieferern, Kunden, Prüfern und Behörden ausgetauscht oder über Jahre archiviert werden.

Allerdings ist eine Signatur kein Qualitätssiegel. Sie bestätigt nicht, dass alle Abhängigkeiten erfasst wurden, Komponenten richtig bezeichnet sind oder die SBOM tatsächlich das ausgelieferte Produkt beschreibt. Eine fehlerhafte SBOM bleibt auch dann fehlerhaft, wenn sie korrekt signiert wurde. Integrität, Authentizität und inhaltliche Qualität sind deshalb getrennte Anforderungen.

Die Anforderungen werden konkreter.

Der CRA verlangt eine SBOM in einem gängigen, maschinenlesbaren Format, mindestens für die obersten Abhängigkeitsebenen. Wie ihre Herkunft technisch nachgewiesen wird, legt die Verordnung jedoch nicht im Detail fest. Andere technische Leitlinien gehen weiter. So beschreibt das BSI in seiner Technischen Richtlinie TR-03183-2 konkrete Anforderungen an maschinenlesbare SBOMs und empfiehlt dort Signaturen. Im Juli 2026 veröffentlichte zudem die amerikanische Cybersecurity and Infrastructure Security Agency (CISA) gemeinsam mit dem BSI und weiteren internationalen Partnern die neuen »2026 Minimum Elements for a Software Bill of Materials«. Darin werden Signaturen bereits zu den »Minimum Elements« gezählt.

Gleichzeitig zeigt eine aktuelle ENISA-Erhebung, dass die Praxis noch nicht so weit ist [1]. 62 Prozent der Befragten bewerten eine hohe Vollständigkeit als erhebliche technische Herausforderung. 69 Prozent halten Interoperabilität für wichtig (39 %) oder kritisch (30 %). Die bloße Erzeugung einer SBOM reicht also nicht. Sie muss sich zuverlässig austauschen, prüfen und in Sicherheitsprozessen verwenden lassen.

Standards können signieren – aber nicht automatisch zusammenarbeiten.

Die etablierten Formate bringen wichtige Voraussetzungen mit. CycloneDX unterstützt digitale Signaturen für SBOMs und nennt vor allem JSF als integriertes Signaturformat. Für SPDX-Dokumente werden Signaturen außerhalb des Dokuments empfohlen, etwa in OCI-Repositories mit Cosign. Über standardisierte Signaturformate für kommende Versionen wie CycloneDX 2.0 und SPDX 3.1 wird gerade beraten.

Der Reality-Check liegt zwischen Spezifikation und Betrieb. Unterschiedliche Signaturformate, Zertifikate, Identitätsmodelle und Werkzeugunterstützung führen schnell zu Inkompatibilitäten. Eine Signatur schafft nur dann Nutzen, wenn der Empfänger sie automatisiert prüfen kann und weiß, welcher Identität er für welchen Zweck vertraut. Dazu gehören auch Regeln für zugelassene Algorithmen, abgelaufene oder widerrufene Zertifikate und fehlgeschlagene Prüfungen.

Was Early Adopter heute tun können.

Unternehmen müssen nicht auf die nächste Standardversion warten. Entscheidend ist, SBOMs nicht als nachträglich erzeugte Dokumentation, sondern als Bestandteil des Release-Prozesses zu behandeln.

Erstens sollte für jeden Build beziehungsweise jedes Release automatisiert eine eigene SBOM entstehen. Zweitens muss sie über einen eindeutigen Hashwert mit genau dem ausgelieferten Software-Artefakt verbunden sein. Drittens sollte die Signatur der SBOM durch eine kontrollierte Organisations- oder Workload-Identität erfolgen, nicht durch einen persönlichen Entwicklerschlüssel. Viertens gehört die Prüfung der Signatur in den automatisierten Annahme-, Freigabe- oder Deployment-Prozess. Eine ungültige Signatur oder eine Abweichung zum Software-Artefakt darf nicht nur protokolliert werden, sondern muss eine definierte Reaktion auslösen.

Auch Lieferantenanforderungen sollten präziser werden. Statt lediglich »eine SBOM« zu verlangen, müssen Verträge Format und Version, Abdeckung, Aktualisierungsfrequenz, Bezug zur Produktversion, Signaturverfahren und benötigte Verifikationsinformationen festlegen. Eine sinnvolle Orientierung für solche Mindestanforderungen bieten die 2026 veröffentlichten »Minimum Elements for a Software Bill of Materials«, die einen international abgestimmten Ausgangspunkt für Struktur und Austausch von SBOM-Daten schaffen. Ergänzende Aussagen, etwa zur tatsächlichen Ausnutzbarkeit einer Schwachstelle, gehören in dafür vorgesehene Formate wie VEX und sollten ebenfalls einem Aussteller zugeordnet werden.

SBOMs schaffen Transparenz über die Bestandteile von Software. Erst eine überprüfbare Verbindung zwischen Software, Stückliste und Aussteller macht daraus jedoch belastbare Evidenz. Wer Erzeugung, Signatur und Verifikation in seine Lieferkette integriert, schafft die Voraussetzung dafür, im Ernstfall schnell und nachvollziehbar zu belegen, was tatsächlich ausgeliefert beziehungsweise eingesetzt wurde.

Stefan Wenig, CEO,
SignPath GmbH

[1] European Union Agency for Cybersecurity (ENISA), SBOM Adoption State of Play – 2026, S. 23 und 26 (vgl. https://www.enisa.europa.eu/sites/default/files/2026-06/SBOM%20Adoption%20State%20of%20Play%202026.pdf; zuletzt abgerufen am 18. August 2026)

Illustration: Valeriy Kachaev | dreamstime.com

37 Artikel zu „Stückliste Software SBOM“

IT-Security | Lösungen | News

SBOM Stücklisten für Software: Unerlässlich für mehr Cybersicherheit

17. Januar 2023

Softwarestücklisten (Software Bill of Materials, kurz SBOM) bilden ein wichtiges Fundament für die Sicherheit von Softwarelieferketten, aber auch für andere Bereiche der IT-Sicherheit im Unternehmen. Deshalb kann heute kein Unternehmen auf SBOMs verzichten. Die meisten proprietären Anwendungen und viele Open-Source-Programme enthalten nicht nur eigenen Quellcode, sondern oft auch weiteren, externen Code für bestimmte Funktionen.…