SBOM ohne Zweitprozess: die Stückliste aus derselben Quelle wie der Build

Die erste SBOM eines Herstellers entsteht fast immer von Hand: jemand setzt sich hin, geht die Abhängigkeiten durch, trägt Namen und Versionen in eine Tabelle. Das Ergebnis ist korrekt — für genau einen Build. Beim nächsten Patch-Release stimmt es nicht mehr, und niemand merkt es, weil die Tabelle in einem anderen Werkzeug lebt als der Code.

Das ist der Kern des Problems: Eine Stückliste, die neben dem Build gepflegt wird, ist ein Zweitprozess. Zweitprozesse driften.

Was der CRA verlangt — und was nicht

Der Cyber Resilience Act fordert in Annex I Teil II, dass Hersteller die im Produkt enthaltenen Komponenten und deren Schwachstellen identifizieren und dokumentieren. Dazu gehört ausdrücklich eine Softwarestückliste in einem verbreiteten, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt.

Drei Punkte daran werden regelmäßig überlesen:

„Maschinenlesbar” schließt die Tabelle aus. Ein PDF oder eine Excel-Datei erfüllt die Anforderung nicht. Gemeint sind Formate wie SPDX oder CycloneDX.

„Mindestens Top-Level” ist ein Minimum, kein Ziel. Für die eigene Schwachstellenarbeit sind transitive Abhängigkeiten oft die interessanteren — dort sitzen die Bibliotheken, die niemand bewusst ausgewählt hat.

Die SBOM ist kein Auslieferungsartefakt für jedermann. Sie gehört zur technischen Dokumentation und ist den Marktüberwachungsbehörden auf Verlangen zugänglich zu machen. Die verbreitete Sorge, man müsse seine Stückliste veröffentlichen, entspricht nicht dem Rechtstext.

Die einzige Stelle, an der die Wahrheit steht

Eine belastbare SBOM hat genau eine Eigenschaft: Sie wird aus derselben Quelle erzeugt, aus der auch das Artefakt entsteht. Alles andere ist eine Beschreibung des Wunschzustands.

Für Embedded-Projekte heißt das in der Regel:

• Yocto / OpenEmbedded: Die Stückliste entsteht aus dem Image-Rezept, nicht aus dem Gedächtnis des Integrators. Die Layer- und Recipe-Struktur kennt Versionen und Lizenzen bereits.
• Buildroot: Der Paketsatz der Konfiguration ist die Quelle; die Konfiguration ist damit ein Nachweisartefakt und gehört versioniert zum Release.
• Applikationscode: Lockfiles der jeweiligen Toolchain sind die verbindliche Quelle, nicht die Manifest-Datei mit ihren Versionsbereichen.
• Von Hand eingebundene Bibliotheken: der Problemfall. Alles, was als Kopie im Repository liegt, taucht in keiner automatischen Erhebung auf und muss explizit erfasst werden — am besten mit dem Ziel, diese Fälle abzubauen.

Erzeugt wird die SBOM im Build, abgelegt wird sie zusammen mit dem Release-Artefakt und mit derselben Versionskennung. Eine SBOM ohne eindeutige Zuordnung zu einem Firmware-Stand ist im Ernstfall wertlos: Die Frage lautet nie „welche Bibliotheken nutzen Sie?”, sondern „welche Bibliothek steckt in der Version, die bei diesem Kunden läuft?”.

Vom Artefakt zum Prozess

Die Stückliste allein ist noch kein Nutzen. Sie wird erst dann zum Werkzeug, wenn sie an zwei Stellen andockt:

Schwachstellenüberwachung. Neue Meldungen müssen gegen die SBOMs der ausgelieferten Stände geprüft werden — automatisiert, nicht anlassbezogen. Genau hier zahlt sich das maschinenlesbare Format aus.

Lieferantenpflege. Komponenten von Dritten brauchen eine Zusage, wie lange sie gepflegt werden. Eine Bibliothek ohne erkennbaren Pflegepfad ist ein Produktrisiko mit Ansage — und in 62443-4-1 ein Thema der Practice Security Management. Die Auswahl ist der billigste Hebel: Eine sorgfältig gewählte, aktiv gepflegte Open-Source-Komponente in aktueller Version erspart mehr Schwachstellenarbeit als jedes nachgelagerte Scanning.

Wer konkretere Vorgaben zu Inhalt und Detailtiefe sucht, findet sie in der BSI-Richtlinie TR-03183 — sie ist an mehreren Stellen strenger und präziser als der Rechtstext selbst.

Was im Audit tatsächlich gefragt wird

Nicht: „Haben Sie eine SBOM?” Sondern: „Zeigen Sie mir die SBOM zur Firmware 2.4.1, und zeigen Sie mir, wie sie entstanden ist.” Wer an dieser Stelle in den Build-Job zeigen kann, ist fertig. Wer in ein Dokumentenmanagement zeigt, beginnt zu erklären.

Fachliche Einordnung, kein Rechtsrat. Für die verbindliche Auslegung im Einzelfall ziehen Sie bitte den Rechtstext und juristische Beratung heran.