SBOM für Embedded Systeme: CRA-Anforderungen pragmatisch umsetzen

Der Cyber Resilience Act (CRA) macht SBOMs zur Pflicht, aber in der industriellen Praxis fehlen oft die Werkzeuge, die im Web-Stack längst selbstverständlich sind.

Wie einfach SBOMs heute für Web, Mobile und Desktop funktionieren

In modernen Web- und Mobile-Stacks ist die SBOM-Erzeugung kein Hexenwerk mehr. Paketmanager wie npm, NuGet, Maven oder pip liefern strukturierte Dependency-Metadaten von Haus aus. Jedes package.json, jede .csproj oder requirements.txt ist bereits ein maschinenlesbares Inventar.

Ein typischer Workflow in einer .NET-Anwendung: Du baust dein Projekt, und Tools wie dotnet list package oder integrierte CI-Scanner erzeugen automatisch eine Liste aller direkten und transitiven Abhängigkeiten. GitHub Dependabot, Snyk oder Trivy scannen diese Listen gegen CVE-Datenbanken und melden Schwachstellen, bevor du sie überhaupt bemerkst.

Für Container-basierte Deployments ist es ähnlich komfortabel: Tools wie Syft oder Trivy analysieren ein Image Layer für Layer und liefern eine CycloneDX- oder SPDX-Datei. Die Integration in CI/CD-Pipelines ist oft ein Einzeiler.

Diese Einfachheit verdanken wir drei Faktoren:

• Standardisierte Paketformate: npm, NuGet, Maven und Co. definieren klare Metadaten-Strukturen.
• Zentralisierte Registries: npmjs.com, nuget.org oder Maven Central sind Single Sources of Truth.
• Reife Tooling-Ökosysteme: Scanner, Generatoren und Monitoring-Plattformen sind ausgereift und gut dokumentiert.

Im Web-Stack ist eine SBOM deshalb oft ein Nebenprodukt des normalen Build-Prozesses. Im Embedded-Umfeld sieht die Realität anders aus.

Warum Embedded-Entwicklung hier anders ist

Embedded-Systeme sind aus vielen heterogenen Komponenten zusammengesetzt: Hardware und Software, proprietäre und Open-Source-Teile, Vendor-SDKs und selbst geschriebener Code. Diese Vielfalt macht die SBOM-Erzeugung deutlich komplexer als im Web-Stack.

Fehlende Sichtbarkeit

Embedded-Systeme bestehen aus Schichten: Hardware-Abstraktionen, Board Support Packages (BSPs), RTOS oder Kernel, Middleware, Applikationslogik und nicht selten Binary Blobs von Drittanbietern. Jede Schicht hat eigene Abhängigkeiten, die oft nicht dokumentiert sind.

Im Web-Stack weißt du genau, welche npm-Pakete in deinem node_modules landen. Im Embedded-Umfeld sieht das anders aus: Ein Vendor-SDK landet als ZIP-Datei im Projekt, enthält statisch gelinkte Libraries, und niemand weiß genau, welche Versionen darin stecken. Ohne vollständige Sichtbarkeit über alle Komponenten ist eine akkurate SBOM nicht möglich.

Manuelle Prozesse

Wo automatisierte Tools fehlen, bleiben manuelle Prozesse. In vielen Embedded-Projekten ist die Inventur der Software-Komponenten ein Excel-Sheet, das von Hand gepflegt wird. Jede Komponente muss einzeln verifiziert werden: Welche Version? Welche Lizenz? Woher stammt sie?

Dieser manuelle Aufwand ist nicht nur zeitintensiv, sondern auch fehleranfällig. Komponenten werden vergessen, Versionen veralten, und bei jedem Release beginnt die Arbeit von vorn.

Fehlende Standardisierung

In der Web-Entwicklung haben sich npm, pip oder Maven als De-facto-Standards etabliert. In der Embedded-Welt mit C und C++ gibt es keinen vergleichbaren universellen Paketmanager. Projekte nutzen gleichzeitig Git-Submodules, manuell heruntergeladene Quellen, Conan, vcpkg oder gar keine Dependency-Verwaltung.

Diese Heterogenität erschwert die Erstellung und den Austausch von SBOMs zwischen Organisationen. Wenn jeder sein eigenes Format und seine eigene Struktur verwendet, wird die Vergleichbarkeit und Aggregation von Inventaren zur Herausforderung.

Risiken in der Lieferkette

Drittanbieter-Software und -Komponenten bringen neue Risiken mit. Eine einzelne Schwachstelle in einer Library kann weitreichende Konsequenzen haben. Im Web-Stack sind diese Risiken durch etablierte Scanner und Datenbanken wie die National Vulnerability Database gut adressiert.

Im Embedded-Bereich ist die Situation komplizierter: Binary Blobs lassen sich nicht (so leicht) scannen, Vendor-Libraries haben oft keine öffentlichen CVE-Einträge, und die Abhängigkeiten in einem BSP sind selten transparent dokumentiert. Ohne detailliertes Wissen über die Komponenten und deren Abhängigkeiten kannst du Supply-Chain-Risiken nicht identifizieren, geschweige denn beheben.

Langlebigkeit und Varianten

Geräte stehen 10, 15 oder 20 Jahre im Feld. Damit wird SBOM-Archivierung und Reproduzierbarkeit zu einem echten Engineering-Problem. Dazu kommen Varianten und Konfigurationen. Ein Feature-Flag, ein anderes Board-Revision-Set, ein optionales Kommunikationsmodul, und plötzlich ist dein ausgeliefertes System nicht mehr identisch mit dem Build von letzter Woche.

Du brauchst eine Strategie für:

• Langzeit-Storage von SBOMs pro Release
• Zuordnung SBOM zu Geräten und Flotten (Seriennummern, Hardware-Revisions, Varianten)
• Nachvollziehbarkeit bei Hotfix-Builds und Backports

Praxisbeispiele: Mikrocontroller-Toolchains

Traditionelle IDEs für Mikrocontroller waren lange darauf ausgelegt, Hardware-Abstraktionen und effizienten Maschinencode zu generieren. Das strukturierte Management von Software-Abhängigkeiten stand nicht im Fokus. Der CRA zwingt Hersteller nun dazu, Sicherheitsaspekte tiefer in ihre Ökosysteme zu integrieren.

Diese Tabelle zeigt die gängigsten Ökosysteme und deren technische Basis. Für die SBOM-Pflicht im Cyber Resilience Act ist entscheidend, ob das Build-System (z. B. CMake) und das Paketmanagement (z. B. West) automatisierbar sind.

Legende zur Spalte SBOM-Potenzial

• Hoch: Nutzt moderne, textbasierte Manifest-Dateien und Build-Systeme (CMake/Python), die sich leicht in CI/CD-Pipelines für automatische SBOM-Exporte (SPDX/CycloneDX) integrieren lassen.
• Mittel: Bietet modulare SDKs, erfordert aber oft das Parsen von proprietären IDE-Projektdateien oder XML-Konfigurationen, um Abhängigkeiten zu identifizieren.
• Gering: Stark an grafische Konfiguratoren gebunden; Abhängigkeiten werden oft als statischer Quellcode ohne Metadaten in das Projekt kopiert.

Praxisbeispiele: PLC- und OT-Systeme

Die Welt der speicherprogrammierbaren Steuerungen (SPS/PLC) ist durch proprietäre Protokolle und geschlossene Engineering-Umgebungen geprägt. Hier ist die Generierung einer SBOM oft mit erheblichem manuellem Aufwand verbunden, da die Abhängigkeiten zwischen Funktionsbausteinen (FBs) und Bibliotheken tief im Projektfile verborgen sind.

Paketmanagement und Abhängigkeitsauflösung in C/C++

Eines der fundamentalen Hindernisse für eine präzise SBOM in der Embedded-Welt ist die Vielfalt der Paketmanagement-Methoden. Im Gegensatz zur Web-Entwicklung gibt es in C/C++ keinen sprachspezifischen Standard. Ein Projekt kann gleichzeitig Bibliotheken aus Git-Submodulen, System-Paketmanagern (apt), manuell kompilierten Quellen und modernen Managern wie Conan oder vcpkg enthalten.

Conan: Integrierte CycloneDX-Unterstützung

Conan hat sich als leistungsfähiger Paketmanager für C/C++ etabliert und bietet mit dem Modul conan.tools.sbom eine direkte Möglichkeit zur Erzeugung von CycloneDX-Dateien. Durch Funktionen wie cyclonedx_1_4 oder cyclonedx_1_6 kannst du den vollständigen Abhängigkeitsgraph deines Projekts in eine JSON-Datei exportieren. Das ermöglicht eine kontinuierliche Analyse der verwendeten Pakete und eine einfache Integration in CI/CD-Pipelines.

vcpkg: Fokus auf SPDX und Serialisierung

vcpkg, der Paketmanager von Microsoft, generiert für jedes installierte Paket automatisch eine SPDX-JSON-Datei. Diese Dateien enthalten detaillierte Informationen über den Namen, die Version und den ABI-Hash der Binärdatei. Ein derzeitiger Kritikpunkt der Community (an dem gearbeitet wird) ist jedoch, dass vcpkg-SBOMs oft keine externen Identifikatoren wie CPE oder PackageURL (purl) enthalten, was das automatisierte Schwachstellen-Matching erschweren kann.

PlatformIO: Meta-Tool zwischen Maker- und Industrie-Welt

Neben den klassischen Vendor-Tools gewinnen Meta-Tools wie PlatformIO an Bedeutung. Sie bieten zwar durch die platformio.ini ein hervorragendes, zentrales Inventar, stellen Teams aber vor Herausforderungen: Viele automatisierte SBOM-Generatoren der Hersteller greifen hier ins Leere, da PIO eigene Abstraktionsschichten nutzt. Hier ist oft zusätzliche Handarbeit oder der Einsatz von generischen Scannern wie Syft oder Trivy auf Dateisystem-Ebene gefragt. Wenn du PlatformIO einsetzt, lohnt sich deshalb ein pragmatischer Check: Kommen die gelisteten Libraries wirklich in deiner finalen SBOM an, oder entstehen hier blinde Flecken, die du manuell oder durch Artefakt-Scans schließen musst?

Das Yocto Projekt: Goldstandard für industrielle Linux-Systeme

Für Hersteller, die auf Embedded Linux setzen, bietet das Yocto Projekt die wohl ausgereifteste Lösung für die SBOM-Pflicht. Durch das Erben der Klasse create-spdx generiert das Build-System automatisch SPDX-Dokumente für jedes Rezept und jedes Paket.

Die resultierenden Dateien (z. B. IMAGE-MACHINE.spdx.json) enthalten nicht nur eine Liste der installierten Software, sondern auch Informationen über die Herkunfts-URLs, Lizenzen und kryptografische Hashes. Mit der Einführung von SPDX 3.0 in neueren Yocto-Releases (z. B. Styhead) wird die Verknüpfung von Dokumenten und die Integration von VEX-Informationen weiter vereinfacht. Dies ermöglicht es Herstellern, eine vollständige technische Dokumentation zu erstellen, die den strengen Anforderungen des CRA an die Transparenz gerecht wird.

Lieferkette & Verantwortlichkeiten: Supplier-SBOMs, Verträge, Übergaben

CRA-Logik ist an der Stelle klar: Auch externe Komponenten, egal ob zugekauft oder nicht, sind Teil deines Risikos. Der CRA spricht explizit über Due Diligence bei Drittkomponenten (siehe Verordnungstext, u.a. Pflichten zur Sorgfalt beim Integrieren von Third-Party-Komponenten).

Praktisch heißt das: Du brauchst Supplier-Anforderungen, die du einkaufs- und projekttauglich formulieren kannst. Eine kurze, vertragstaugliche Checkliste kann so aussehen:

• SBOM in SPDX oder CycloneDX, maschinenlesbar (JSON/XML), pro geliefertem Artefakt
• Eindeutige Versionierung (SemVer, Build-ID) und Hashes der gelieferten Binaries
• Supplier- und Herkunftsangaben (Download/Repo/Release-Notes)
• Update- und Support-Zusagen (Support-Period, Security-Fixes)
• Optional: VEX für bekannte CVEs, mindestens für High/Critical Findings

Wenn ein Vendor nur ein PDF liefert, ist das ein guter Startpunkt, aber kein Endzustand. Definiere ein Zielbild (z.B. CycloneDX JSON) und biete eine Übergangsphase an, in der PDF parallel akzeptiert wird, aber machine-readable verpflichtend wird.

Was ist mit Komponenten, die in keiner SBOM auftauchen?

Genau hier liegt in vielen Embedded- und OT-Projekten der Knackpunkt: Nicht alles kommt über einen Paketmanager. Du hast Vendor-SDKs als ZIP, statisch gelinkte Libraries, Binary Blobs, zugekaufte Kommunikationsmodule, Engineering-Tools, oder eine proprietäre PLC-Library. Dafür gibt es oft keine maschinenlesbare SBOM.

Die gute Nachricht: Du kannst diese Komponenten trotzdem sauber in deine SBOM aufnehmen, ohne dass du dafür jede Toolchain komplett automatisieren musst. Du brauchst dafür im Wesentlichen zwei Dinge: einen pragmatischen Mindestdatensatz und einen Prozess, der mit jedem Release wiederholbar ist.

Pragmatischer Ansatz: „Manuelle Ergänzungen“ als eigener, versionierter Input

Statt Excel als einmalige Doku zu sehen, behandelst du die Liste als zusätzliche Quelle für deine SBOM:

Damit es nicht ausufert, reicht für den Anfang ein „CRA-tauglicher“ Mindestdatensatz pro Komponente:

Optional (wenn verfügbar, aber nicht erzwingen): Hash (SHA-256) des Binaries, CPE (Common Platform Enumerator)/purl (Package Url), Produktnummer, Support-Enddatum.

Wie kommt das dann in die SBOM?

Ohne in Spezifikationsdetails abzutauchen: CycloneDX und SPDX sind als De-facto-Standards am Ende strukturierte Listen von Komponenten. Für den CRA ist entscheidend, dass du am Ende eine auslieferbare SBOM in einem zulässigen Format hast, nicht ob jede Zeile vollautomatisch entstanden ist.

In der Praxis gibt es dafür zwei gangbare Varianten:

• Variante A: Eine SBOM pro Release (empfohlen): Du führst die automatisch ermittelte Liste und die manuell gepflegte Liste zu einer SBOM zusammen. Das ist für Kunden, Auditoren und Tools am angenehmsten, weil sie nur eine Datei konsumieren müssen.
• Variante B: Zwei SBOMs, beide im SBOM-Standardformat: Du lieferst zwei Dateien aus, z.B. eine SBOM für die automatisiert ermittelten Abhängigkeiten und eine zweite SBOM für die manuell zusammengetragenen Komponenten. Wichtig ist dann vor allem Konsistenz. Beide SBOMs tragen die gleiche Produkt-/Release-Version und beide werden gemeinsam als Release-Artefakt ausgeliefert (und idealerweise in den Release Notes gemeinsam referenziert).

Das ist weniger komfortabel als eine zusammengeführte SBOM, aber es ist ein klarer, auditierbarer Schritt hin zu SBOMs, die versioniert und gemeinsam mit jedem Release ausgeliefert werden.

Fazit: SBOMs für Embedded pragmatisch, aber belastbar

Im Embedded- und OT-Umfeld ist eine SBOM selten nur ein Knopfdruck. Entscheidend ist, dass du eine wiederholbare Release-Praxis etablierst: Automatisiere, was dein Ökosystem hergibt, und ergänze die blinden Flecken (Vendor-SDKs, Binaries, Engineering-Tools) mit einem klar definierten Mindestdatensatz.

Ob du am Ende eine zusammengeführte SBOM oder zwei SBOMs auslieferst, ist vor allem eine Frage von Konsumierbarkeit und Prozessreife. Wichtig ist die Konsistenz pro Release, die Nachvollziehbarkeit der Quellen und dass deine Lieferkette SBOMs als normales Lieferartefakt behandelt.

Wenn du willst, nimm mit uns Kontakt auf und wir reviewen deine SBOM-Strategie gegen CRA-Minimum und gegen die Frage, ob sie im Betrieb wirklich tragfähig ist.

Wie setzt du SBOMs heute in Embedded- oder OT-Projekten um, und wo hakt es am meisten? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.