SBOM in der Praxis: So bauen Sie die Software-Stückliste auf, die der Cyber Resilience Act verlangt

Im Juli haben wir die CRA-Meldepflichten ab dem 11. September 2026 auseinandergenommen — Meldekaskade, Fristen, To-do-Liste. Dieser Artikel ist die praktische Fortsetzung für die zweite große Baustelle: Ab dem 11. Dezember 2027 dürfen Produkte mit digitalen Elementen nur noch in Verkehr gebracht werden, wenn die Anforderungen aus Anhang I erfüllt sind. Und eine davon ist so konkret wie kaum eine andere Compliance-Anforderung: die SBOM, die Software-Stückliste.

Die gute Nachricht vorweg: Anders als bei vielen Compliance-Themen ist das hier ein Ingenieursproblem mit ausgereiften, kostenlosen Werkzeugen. Wer eine Build-Pipeline hat, kann in einer Woche eine funktionierende SBOM-Erzeugung stehen haben. Die schlechte: Eine SBOM zu erzeugen ist der einfache Teil. Sie aktuell zu halten, ihre Qualität zu sichern und die daraus fallenden Schwachstellenmeldungen zu bewerten — das ist der Teil, an dem die meisten scheitern. Der Reihe nach.

Was der CRA konkret verlangt — und was eine SBOM eigentlich ist

Eine SBOM (Software Bill of Materials) ist genau das, was der Name sagt: eine Stückliste, wie sie im Maschinenbau seit Jahrzehnten selbstverständlich ist — nur für Software. Sie listet auf, welche Komponenten, Bibliotheken und Abhängigkeiten in einem Software-Artefakt stecken, jeweils mit Name, Version, Hersteller und eindeutiger Kennung. Der Anlass ist immer derselbe: Wenn die nächste Log4Shell-artige CVE publik wird, müssen Sie in Minuten beantworten können, ob und wo die betroffene Komponente in Ihren Produkten steckt. Ohne SBOM ist das Archäologie, mit SBOM eine Datenbankabfrage.

Der Cyber Resilience Act formuliert die Pflicht in Anhang I, Teil II („Anforderungen an die Behandlung von Schwachstellen"), Nummer 1: Hersteller müssen Schwachstellen und Komponenten ihrer Produkte identifizieren und dokumentieren, „einschließlich der Erstellung einer Software-Stückliste in einem gebräuchlichen und maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten des Produkts erfasst". Drei Dinge stehen damit fest, ein viertes bleibt offen:

• Maschinenlesbar: Ein PDF oder eine Excel-Liste erfüllt die Anforderung nicht. Gemeint sind strukturierte Formate — in der Praxis CycloneDX oder SPDX.
• Mindestens die oberste Abhängigkeitsebene: Das ist eine Untergrenze, keine Empfehlung. „Oberste Ebene" heißt: die Komponenten, die Sie direkt einbinden — nicht deren Abhängigkeiten.
• Kein einmaliges Dokument: Die SBOM gehört zur technischen Dokumentation und muss über den Support-Zeitraum aktuell sein. Praktisch heißt das: neu erzeugen bei jedem Release, besser bei jedem Build.
• Offen bleibt: „Oberste Abhängigkeiten" definiert der CRA nirgends präzise. Die Auslegungshoheit liegt bei Marktüberwachung und kommenden Durchführungsrechtsakten — wer nur das Minimum liefert, wettet darauf, dass die Auslegung milde ausfällt.

Wichtig für die Einordnung: Herausgeben müssen Sie die SBOM nach aktuellem Stand nicht öffentlich. Sie gehört zur technischen Dokumentation (Anhang VII) und muss der Marktüberwachung auf Verlangen vorgelegt werden. Kunden haben aus dem CRA selbst keinen automatischen Anspruch — vertraglich wird er trotzdem zunehmend vereinbart, dazu später mehr. Und der übliche Hinweis: Wir sind Ingenieure, keine Juristen — dieser Artikel ist Praxiswissen, keine Rechtsberatung.

CycloneDX vs. SPDX: Die Formatfrage ehrlich beantwortet

Zwei Formate teilen den Markt unter sich auf, beide sind anerkannte Standards, beide erfüllen die CRA-Anforderung „gebräuchlich und maschinenlesbar". Die Wahl ist trotzdem keine Geschmacksfrage, weil die Ökosysteme unterschiedlich gewachsen sind:

Unsere Empfehlung für die typische Ausgangslage im Mittelstand — Produkte mit digitalen Elementen, kleine bis mittlere Entwicklungsteams, kein dediziertes Supply-Chain-Security-Team: CycloneDX als Primärformat. Drei Gründe: Es ist auf den Anwendungsfall gebaut, den der CRA adressiert (Schwachstellenbehandlung, nicht Lizenzverwaltung). Das Auswertungs-Ökosystem — allen voran Dependency-Track — ist darauf optimiert. Und das flache Datenmodell macht es leichter, die Qualität der eigenen SBOMs zu prüfen und zu debuggen.

In der Praxis: SPDX gewinnt dort, wo Lizenz-Compliance im Vordergrund steht oder ein Großkunde es explizit vorschreibt — im US-Behördenumfeld und in Teilen der Automobilindustrie kommt das vor. Da Syft und Trivy beide Formate aus derselben Analyse erzeugen, ist das kein Entweder-oder: Primärformat CycloneDX, SPDX auf Zuruf. Nur die Konvertierung zwischen beiden Formaten sollten Sie meiden, wo es geht — dabei gehen regelmäßig Felder verloren.

BSI TR-03183-2: Die deutsche Messlatte

Der CRA sagt dass, aber kaum wie. Die Lücke füllt in Deutschland die Technische Richtlinie BSI TR-03183 Teil 2 „Software Bill of Materials (SBOM)", aktuell in Version 2.1.0 vom August 2025 — die erste Fassung, die auf die finalen CRA-Anforderungen gemappt ist. Sie ist rechtlich nicht bindend, aber faktisch die Referenz, an der sich deutsche Auditoren, Prüfstellen und Einkaufsabteilungen orientieren werden. Die wichtigsten Festlegungen:

• Formate: CycloneDX ab 1.6 oder SPDX ab 3.0.1 — ältere Formatversionen gelten als nicht konform. Wer heute noch SPDX 2.3 erzeugt, erfüllt die TR nicht.
• Pflichtfelder pro Komponente: u. a. Ersteller, Name, Version, Abhängigkeitsbeziehungen, Lizenz, Hash der ausführbaren Komponente und eine eindeutige Kennung — in der Praxis die Package-URL (purl).
• Abhängigkeitstiefe: Die TR unterscheidet SBOM-Typen nach Tiefe und Aussagekraft; das CRA-Minimum „Top-Level" ist dort die unterste Stufe, nicht der Zielzustand.
• Neu in 2.1.0: explizites Mapping der TR-Datenfelder auf CycloneDX- und SPDX-Felder sowie das Konzept virtueller und referenzierter Komponenten — hilfreich für alles, was nicht klassisch paketiert ist.

Der pragmatische Rat: Nehmen Sie die TR-03183-2 als Qualitäts-Checkliste für Ihre eigenen SBOMs, bevor es ein Auditor tut. Ein Nachmittag mit der Richtlinie und einer selbst erzeugten SBOM im Vergleich deckt die typischen Lücken auf — fehlende Hashes, Komponenten ohne Versionsangabe, „NOASSERTION"-Lizenzen in Serie.

Tooling: Syft, Trivy, Grype, Dependency-Track — was wofür

Der Werkzeugkasten ist erfreulich reif und im Kern kostenlos. Wichtig ist, die drei Aufgaben auseinanderzuhalten, die gern in einen Topf geworfen werden: SBOMs erzeugen, SBOMs gegen Schwachstellen prüfen und SBOMs über Produkte und Versionen hinweg verwalten. Kein Open-Source-Tool macht alle drei gut — die Kombination schon:

Das Zusammenspiel: Syft (oder Trivy) erzeugt bei jedem Build die SBOM, Grype prüft sie sofort als Qualitäts-Gate, Dependency-Track sammelt sie ein und überwacht sie dauerhaft — auch Monate nach dem Release, wenn eine neue CVE für eine längst ausgelieferte Version publik wird. Genau dieser letzte Teil ist der, der die CRA-Meldepflicht bedient: Ohne kontinuierlichen Abgleich erfahren Sie von der ausnutzbaren Schwachstelle in Ihrem Bestandsprodukt aus der Presse.

Open Source vs. kommerziell

Der Open-Source-Stack trägt erstaunlich weit — Dependency-Track läuft produktiv in Unternehmen mit tausenden Projekten. Kommerzielle Plattformen (FOSSA, Anchore Enterprise, Snyk, Mend u. a.) kaufen Sie aus drei Gründen: kuratierte Schwachstellendaten mit weniger False Positives, tiefere Lizenz-Compliance-Workflows und einen Ansprechpartner mit SLA. Ehrlich: Für ein KMU mit einer Handvoll Produkte ist der Open-Source-Stack der richtige Start — die Betriebskosten sind ein kleiner Container-Host und ein paar Stunden Pflege im Monat. Kommerziell wird interessant, wenn Lizenz-Compliance ein eigenes Thema wird oder niemand da ist, der die Plattform betreiben will.

CI/CD-Integration: Eine SBOM pro Build-Artefakt

Die wichtigste Architekturentscheidung überhaupt: Die SBOM wird im Build erzeugt, nicht nachträglich. Eine SBOM, die jemand quartalsweise von Hand erstellt, ist am Tag ihrer Erstellung veraltet und beim Audit wertlos. Die Regel lautet: ein Build-Artefakt, eine SBOM, beide zusammen versioniert und archiviert. Der Einstieg ist unspektakulär:

Das Ergebnis ist ein JSON-Dokument, dessen Kern so aussieht — pro Komponente Name, Version und die Package-URL als eindeutige Kennung, dazu der Abhängigkeitsgraph:

In einer GitLab-Pipeline sind das zwei Jobs: einer erzeugt die SBOM als Build-Artefakt, einer lädt sie in Dependency-Track hoch. Wer GitLab ohnehin selbst betreibt — wie im Artikel GitLab selbst hosten beschrieben — hat damit die komplette Kette auf eigener Infrastruktur:

Zwei Praxis-Hinweise dazu. Erstens: Erzeugen Sie die SBOM vom fertigen Artefakt (Image, Installer, Firmware), nicht nur vom Quellcode — nur so landen auch Basis-Image, Laufzeitumgebung und einkompilierte Bibliotheken darin. Zweitens: Archivieren Sie die SBOMs außerhalb der Pipeline-Artefakte, die nach 30 Tagen expiren. Der CRA verlangt die technische Dokumentation zehn Jahre — die SBOM zu Release 1.4.2 muss auch 2033 noch auffindbar sein.

VEX: Die Antwort auf „Ist die CVE bei uns überhaupt ausnutzbar?"

Sobald Dependency-Track läuft, passiert etwas Vorhersehbares: Sie bekommen hunderte Schwachstellen-Treffer. Ein mittelgroßes Produkt mit vollem Abhängigkeitsbaum bringt es locker auf 200 bis 500 offene CVEs — und die große Mehrheit davon ist im konkreten Produkt nicht ausnutzbar: Die verwundbare Funktion wird nie aufgerufen, das Feature ist deaktiviert, der Angriffspfad existiert in der Einsatzumgebung nicht.

Genau dafür gibt es VEX — Vulnerability Exploitability eXchange. Ein VEX-Dokument ist die maschinenlesbare Aussage des Herstellers: „CVE-2026-XXXX betrifft Komponente Y in Produkt Z — Status: not_affected, Begründung: verwundbarer Code wird nicht aufgerufen." Die vier Status sind affected, not_affected, fixed und under_investigation. Drei Formate konkurrieren: CycloneDX VEX (nativ im SBOM-Ökosystem, von Dependency-Track direkt unterstützt), CSAF 2.0 (das Format der Behörden-Advisories, auch vom BSI genutzt — TR-03183 Teil 3 behandelt es) und OpenVEX (minimalistisch, im Open-Source-Umfeld verbreitet). Wer den CycloneDX-Stack fährt, nimmt CycloneDX VEX — alles andere erzeugt Reibung.

SBOMs von Lieferanten einfordern: Formulierungen für den Einkauf

Ihre eigene SBOM ist nur so vollständig wie das, was Ihre Zulieferer Ihnen mitgeben. Wer eine Steuerungskomponente, ein SDK oder eine White-Label-Firmware zukauft, integriert deren Abhängigkeiten — und übernimmt als Hersteller die Verantwortung dafür. Ab Ende 2027 gilt zudem: Auch Ihre Zulieferer sind, soweit sie im CRA-Scope liegen, selbst zur SBOM verpflichtet. Es gibt also keinen Grund mehr, sich mit „das ist Betriebsgeheimnis" abspeisen zu lassen. Was in die Einkaufsbedingungen bzw. den Liefervertrag gehört — als Anregung, nicht als Rechtsberatung; die finale Formulierung gehört zu Ihrem Juristen:

• Lieferpflicht: „Der Auftragnehmer liefert mit jeder Software-Lieferung und jedem Update eine Software-Stückliste (SBOM) im Format CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, inhaltlich mindestens gemäß BSI TR-03183-2, mit vollständigem Abhängigkeitsbaum."
• Aktualität: „Die SBOM entspricht exakt dem gelieferten Build-Stand und wird bei jedem Release aktualisiert mitgeliefert."
• Schwachstelleninformation: „Der Auftragnehmer informiert den Auftraggeber unverzüglich, spätestens binnen 48 Stunden, über bekannt gewordene aktiv ausgenutzte Schwachstellen in gelieferten Komponenten und stellt Bewertungen im VEX-Format bereit."
• Nachweis: „Auf Anforderung weist der Auftragnehmer die CRA-Konformität der gelieferten Produkte nach (Konformitätserklärung, technische Dokumentation im erforderlichen Umfang)."

Realistisch werden Sie 2026 noch auf Lieferanten treffen, die keine SBOM liefern können. Dann hilft die Abstufung: erstens vertraglich verankern (mit Übergangsfrist), zweitens übergangsweise selbst scannen — Syft über die gelieferte Firmware oder das gelieferte Image liefert eine brauchbare, wenn auch unvollständige Näherung — und drittens die Lücke im Risikoregister dokumentieren. Ein Lieferant, der auch auf Nachfrage keinerlei Weg zur SBOM aufzeigen kann, ist ab 2027 schlicht ein Beschaffungsrisiko.

Die Grenzen: Wo SBOMs heute noch schummeln

Damit kein falscher Eindruck entsteht: Eine SBOM ist ein Werkzeug, kein Wahrheitsserum. Die wichtigsten Grenzen, die Sie kennen sollten, bevor ein Auditor sie Ihnen erklärt:

• SBOM-Qualität schwankt massiv. Zwei Tools über dasselbe Artefakt liefern verschiedene Ergebnisse — unterschiedliche Erkennungslogik, unterschiedliche Tiefe. Eine SBOM mit 400 Komponenten kann schlechter sein als eine mit 250, wenn die 400 voller Duplikate und Versions-Rateversuche stecken. Stichproben gegen die TR-03183-Pflichtfelder sind kein Luxus.
• Binäranalyse ist Näherung. Bei Paketmanager-Ökosystemen (npm, Maven, PyPI, Go Modules) ist die Erkennung nahezu exakt — Manifeste und Lockfiles machen es leicht. Bei nackten Binaries und Firmware-Blobs rät das Tool anhand von Signaturen und Strings; statisch gelinkte Bibliotheken werden regelmäßig übersehen.
• Die C/C++-Welt ist der harte Teil. Genau dort, wo der CRA am härtesten trifft — Embedded, Steuerungen, Industrieelektronik — gibt es oft keinen Paketmanager: einkopierte Quellen, gepatchte Vendor-Forks, Yocto-Builds. Hier entsteht die SBOM nicht durch einen Scanner-Aufruf, sondern im Build-System selbst (Yocto etwa kann SPDX nativ erzeugen) — das ist echte Ingenieursarbeit und der Hauptgrund, früh anzufangen.
• Eine SBOM patcht nichts. Sie macht Lücken sichtbar — schließen müssen Sie sie selbst. Ohne funktionierendes Patch-Management und einen Update-Kanal zum Produkt ist die schönste Stückliste nur eine präzise Liste offener Probleme.

Fazit: Klein anfangen, aber im Build — nicht im Ordner

Die SBOM-Pflicht des CRA ist die seltene Compliance-Anforderung, deren Erfüllung unmittelbaren operativen Nutzen stiftet: Wer sie sauber umsetzt, beantwortet die „Sind wir betroffen?"-Frage bei der nächsten großen CVE in Minuten — und genau diese Fähigkeit braucht es auch für die 24-Stunden-Meldepflicht, die ab dem 11. September 2026 gilt. Der Weg dahin ist kein Großprojekt: Syft in die Pipeline (ein Tag), Grype als Gate (ein weiterer), Dependency-Track als Inventar (eine Woche inklusive Betriebsfragen). Danach beginnt die eigentliche Arbeit — Triage, VEX, Lieferantenkette — aber auf einem Fundament, das trägt.

Die meisten KMU scheitern nicht am Tooling, sondern an zwei Punkten: der Disziplin, die SBOM konsequent an jeden Build zu koppeln, und der Kapazität, den Schwachstellenstrom danach dauerhaft zu bewerten. Beim ersten hilft eine einmal sauber gebaute Pipeline. Beim zweiten ein Partner, der Monitoring und Schwachstellenbewertung im Dauerbetrieb übernimmt — ISO-27001-zertifiziert und aus deutschen Rechenzentren, wenn es nach uns geht.