Eine SBOM für eine Webanwendung zu erzeugen ist meist unkompliziert. Ein Paketmanager hat den Abhängigkeitsgraphen bereits aufgelöst, Namen und Versionen vergeben und in einem Lockfile festgehalten. Ein SBOM-Generator muss diese strukturierten Daten im Wesentlichen nur noch nach CycloneDX oder SPDX übersetzen.
Embedded-Firmware ist anders.
Ein typisches Firmware-Image kombiniert unter Umständen generierten Code, ein Hersteller-SDK, ein RTOS, Middleware, kopierte Quellbäume, statische Archive, Compiler-Laufzeitbibliotheken, proprietäre Binär-Blobs und Anwendungscode. Manche Komponenten werden in einer IDE ausgewählt. Andere tauchen nur in Compiler-Aufrufen, Linkerskripten oder der finalen Linker-Map auf. Ein universelles Paketmanifest gibt es oft nicht – und keine einzelne Datei, die die ganze Wahrheit erzählt.
Die wiederkehrenden Fragen in den Communities von STMicroelectronics, NXP und Nordic deuten alle auf dasselbe Problem:
Wie erstelle ich eine SBOM für die Firmware, die ich tatsächlich ausliefere – und nicht nur für das SDK-Verzeichnis, mit dem ich gestartet bin?
Dieses Q&A beantwortet diese Frage – und die schwierigen Fragen dahinter.
Was ist eine Embedded- oder IoT-SBOM?
Eine Embedded-SBOM ist ein maschinenlesbares Inventar (eine Softwarestückliste) der Softwarekomponenten, die zu einem bestimmten Firmware-Release eines Geräts gehören.
Sie sollte mindestens das Produkt und das Release identifizieren, die enthaltenen Dritt- und Open-Source-Komponenten, deren Versionen und Lieferanten sowie die Beziehungen zwischen ihnen. Wo möglich, sollte sie außerdem Lizenzen, Hashes, externe Identifikatoren wie Package URLs und Nachweise enthalten, die erklären, wie jede Komponente identifiziert wurde.
Die entscheidenden Worte sind bestimmtes Firmware-Release. Ein Inventar von allem, was in einem Hersteller-SDK verfügbar ist, ist nützliche Lieferanteninformation – aber nicht automatisch die SBOM Ihres Produkts.
Warum sind SBOMs für Web-, Mobile- und Desktop-Anwendungen einfacher?
Moderne Anwendungs-Ökosysteme bieten üblicherweise drei Dinge:
Standardisierte Manifeste und Lockfiles wie
package-lock.json,pom.xml,packages.lock.jsonoderpoetry.lockZentrale Registries mit normalisierten Paketnamen, Versionen, Lizenzen und Identifikatoren
Paketmanager, die direkte und transitive Abhängigkeiten vor dem Build auflösen
Für Embedded-C und -C++ gibt es kein universelles Gegenstück. Abhängigkeiten werden nach Drivers/ kopiert, als Git-Submodule eingebunden, als ZIP-Archive geliefert, über einen grafischen Konfigurator ausgewählt oder aus einer proprietären Toolchain gelinkt.
Der Abhängigkeitsgraph existiert – aber er ist über Projektdateien, Build-Befehle, Include-Pfade, generierte Konfiguration, Archive und Linker-Ausgaben verstreut.
Löst eine vom Hersteller bereitgestellte SDK-SBOM das Problem?
Sie löst einen Teil des Problems.
ST veröffentlicht inzwischen CycloneDX-SBOMs für eine wachsende Zahl von STM32Cube-Paketen; das STM32CubeF1-Repository enthält beispielsweise eine sbom_cdx.json. Das ist wertvoll, denn der Lieferant kann die Komponenten, Versionen, Herkünfte und Lizenzen seiner eigenen Distribution am besten identifizieren.
Eine SDK-SBOM beantwortet jedoch die Frage:
Welche Komponenten hat der Hersteller in diesem SDK-Release ausgeliefert?
Ihre Produkt-SBOM muss beantworten:
Welche Komponenten, Versionen, Patches, Konfigurationen und Binärobjekte wurden in diesem Firmware-Build verwendet?
Das ist nicht dieselbe Frage. Ein vollständiges STM32Cube-Paket kann Treiber für viele Boards enthalten, Beispiele, die Sie nie kompilieren, mehrere Middleware-Optionen und Evaluierungskomponenten, die nie in Ihr Produkt gelangen. Ihr Team patcht vielleicht einen HAL-Treiber, ersetzt eine Middleware-Version oder ergänzt ein RTOS und eine proprietäre Bibliothek.
Behandeln Sie die Lieferanten-SBOM als maßgebliche Upstream-Metadaten. Gleichen Sie sie mit Ihren Build- und Link-Nachweisen ab, um die Produkt-SBOM zu erzeugen.
Kann STM32CubeMX die finale SBOM für meine Firmware erzeugen?
STM32CubeMX-Metadaten sind nützlich – aber Konfigurationsabsicht allein reicht nicht.
Die .ioc-Datei kann unter anderem identifizieren:
MCU-Familie und Baustein
STM32Cube-Firmware-Paket und Version
CubeMX-Version
Konfigurierte Middleware
Projekt- und Toolchain-Auswahl
Das ist starker Kontext. Er kann einem SBOM-Generator sagen, dass ein Projekt auf STM32F4 zielt und ein bestimmtes STM32Cube-Firmware-Paket deklariert. Er beweist aber für sich genommen nicht, dass jede konfigurierte Middleware-Komponente im finalen Binary angekommen ist.
Projekte driften. Entwickler regenerieren nur Teile eines Projekts, ändern generierte Dateien, aktualisieren Middleware manuell, schließen Dateien in der IDE aus oder behalten eine alte .ioc-Datei, nachdem der Build geändert wurde.
Die verlässliche Reihenfolge der Nachweise lautet:
Lieferanten-Metadaten sagen Ihnen, was das SDK enthält.
Projekt- und Konfigurator-Metadaten sagen Ihnen, was der Build verwenden soll.
Compiler- und Build-System-Metadaten sagen Ihnen, was kompiliert wurde.
Linker-Nachweise sagen Ihnen, was im Firmware-Artefakt angekommen ist.
Manuelle, geprüfte Eingaben schließen die verbleibenden Lücken.
Warum reicht das Scannen des Quellverzeichnisses nicht aus?
Ein Verzeichnis-Scan sieht Verfügbarkeit, nicht Verwendung.
Enthält ein Repository FreeRTOS, lwIP, Mbed TLS, FatFs, USB-Host, USB-Device und Dutzende Board-Beispiele, meldet ein Scanner über den gesamten Baum unter Umständen alle davon. Das erzeugt False Positives: Komponenten, die im Quellbaum existieren, aber nicht Teil der ausgelieferten Firmware sind.
Auch das umgekehrte Problem tritt auf. Ein Quell-Scan kann übersehen:
Vorkompilierte
.a-ArchiveProprietäre Binärbibliotheken
Compiler-Laufzeitbibliotheken
Außerhalb des Repositorys generierten Code
Abhängigkeiten, die über einen externen SDK-Pfad referenziert werden
Objekte, die erst beim Linken hinzukommen
Quell-Scans bleiben nützlich, um einkopierte Fremdquellen zu identifizieren und Lizenznachweise zu extrahieren. Deutlich verlässlicher werden sie, wenn sie durch den Build-Graphen eingegrenzt und mit dem finalen Link abgeglichen werden.
Gehören ungenutzte oder vom Linker verworfene Komponenten in die SBOM?
Es gibt zwei vertretbare Ansätze.
Für eine kundenorientierte Produkt-SBOM lassen Teams häufig Komponenten weg, die nachweislich nicht im ausgelieferten Artefakt enthalten sind. Das hält Schwachstellenergebnisse auf das Produkt fokussiert.
Für Engineering- und Audit-Workflows kann es wertvoll sein, diese Komponenten mit einem expliziten „excluded"-Scope zu behalten. Das bewahrt die Nachweiskette und erklärt, warum eine im Projekt sichtbare Komponente nicht als ausgeliefert erscheint.
Die wichtige Regel: „vorhanden", „verfügbar", „optional" und „ausgeschlossen" niemals stillschweigend vermischen. Der Scope sollte explizit sein und durch Nachweise gestützt werden.
Wie sollten statisch gelinkte Bibliotheken abgebildet werden?
Eine statische Bibliothek sollte als Komponente abgebildet werden, wenn sie eine belastbare Identität hat: Name, Version, Lieferant oder Herkunft und idealerweise ein Hash oder externer Identifikator.
Der schwierige Teil ist der Nachweis, ob Code aus dem Archiv tatsächlich übernommen wurde. Dass libfoo.a auf der Linker-Kommandozeile erscheint, beweist nicht, dass der Linker ein Member daraus extrahiert hat. Eine Linker-Map kann oft zeigen, welche Archiv-Member zum finalen Image beigetragen haben.
Wenn ein statisches Archiv proprietär ist oder Versionsmetadaten fehlen, erfassen Sie mindestens:
Lieferant und Bibliotheksname
Release- oder Lieferkennung
SHA-256-Hash
Bezugsquelle
Lizenzeinstufung
Support- oder End-of-Life-Informationen, sofern verfügbar
Ändert sich das Archiv, während der Dateiname gleich bleibt, wird der Hash besonders wichtig.
Was ist mit proprietären Binär-Blobs, SoftDevices, Funk-Stacks und Bootloadern?
Sie gehören in die SBOM, wenn sie Teil des ausgelieferten Produkts sind – auch wenn ihr Inneres eine Blackbox ist.
Die Diskussion in der Nordic-Community rund um das ältere nRF5-SDK bringt die Praxis auf den Punkt: Scans von Drittanbietern helfen, aber vorkompilierte Bibliotheken und nicht automatisch erkennbare Details erfordern unter Umständen manuelle Einträge. Eine Binärkomponente ist nicht davon ausgenommen, nur weil kein Quellcode vorliegt.
Erfassen Sie für eine intransparente Komponente die bestmögliche Identität:
Feld | Warum es wichtig ist |
|---|---|
Name | Stabile, menschenlesbare Identität |
Version oder Release-ID | Update- und Schwachstellen-Korrelation |
Lieferant | Verantwortlichkeit und Eskalationspfad |
SHA-256 | Exakte Identität der gelieferten Bytes |
Bezugsquelle | Nachvollziehbarkeit für Einkauf und Audit |
Lizenz | Nutzungs- und Weitergabepflichten |
Produkt- oder Teilenummer | Korrelation mit Lieferantendokumentation |
Support-Enddatum | Langfristiges Produktrisiko |
Lieferanten-SBOM- oder VEX-Referenz | Schwachstellenkontext downstream |
Eine Komponente mit begrenzten Metadaten ist immer noch besser als eine unsichtbare Komponente.
Gehören Compiler, IDEs, Debugger und Flash-Tools in die SBOM?
Trennen Sie Software im Produkt von Software zum Bauen des Produkts.
Compiler, IDE, Codegenerator, Debugger und Flash-Utility werden üblicherweise nicht in der Geräte-Firmware ausgeliefert. Sie sollten nicht als gewöhnliche Laufzeitkomponenten des Produkts abgebildet werden. Sie sind dennoch wichtige Build-Abhängigkeiten und gehören in die Build-Provenance oder als Build-Tool-Beziehungen dokumentiert.
Compiler-Laufzeitcode ist ein anderer Fall. Bibliotheken wie libgcc, C-Laufzeitbibliotheken, IAR-DLIB-Varianten oder anderer Laufzeit-Support können statisch in die Firmware gelinkt sein. Diese Bytes sind Teil des Artefakts und sollten für die Produkt-SBOM berücksichtigt werden.
Diese Unterscheidung verhindert zwei häufige Fehler: gelinkten Laufzeitcode wegzulassen – und fälschlich zu behaupten, eine IDE oder ein Debugger sei auf dem Gerät installiert.
Wie geht man mit generiertem Code um?
Generierter Code sollte sowohl zu den gelieferten Quelldateien als auch zum Generator-Kontext zurückverfolgbar sein.
CubeMX-generierter Initialisierungscode kann nach der Generierung angepasst worden sein. Die Produkt-SBOM sollte das relevante STM32Cube-Paket und die gelinkten HAL- oder Middleware-Komponenten identifizieren, während die Build-Provenance die verwendete CubeMX-Version und -Konfiguration festhält.
Behandeln Sie „generiert von Tool X" nicht als Ersatz für Komponentenidentität. Generator, Template- oder SDK-Paket, ausgewählte Module, lokale Änderungen und das final gelinkte Ergebnis sind separate Fakten.
Wie gehe ich mit Patches an Hersteller- oder Open-Source-Code um?
Behalten Sie die Upstream-Identität bei – und dokumentieren Sie, dass die Komponente modifiziert ist.
Ein praxistauglicher Eintrag umfasst:
Upstream-Komponentenname und -Version
Upstream-Repository oder Lieferant
Exakten lokalen Commit- oder Quell-Hash
Patch-Satz oder interne Änderungsreferenz
Lizenz
Beziehung zum Produkt-Release
Erfinden Sie keine neue Version, die wie ein Upstream-Release aussieht. Verwenden Sie einen lokalen Qualifier oder eine Property, die den modifizierten Zustand eindeutig kennzeichnet. So bleibt das Schwachstellen-Matching erhalten, und zugleich ist klar, dass die Bytes nicht mit dem Lieferanten-Release identisch sind.
Was tun, wenn eine Komponente keine Version hat?
Nicht raten.
Versuchen Sie, in dieser Reihenfolge:
Release Notes oder Paketmetadaten des Lieferanten
Git-Tag und Commit
Quell-Header oder Versionsmakros
Archivpfad und Toolchain-Metadaten
Kryptografischer Hash plus Lieferkennung
Einen geprüften manuellen Override
Bleibt eine Version unbekannt, sagen Sie das – und geben Sie eine Diagnose aus. Ein transparentes „unbekannt" ist belastbarer als eine selbstbewusste, aber falsche Version.
Sind Header Abhängigkeiten, Komponenten oder nur Dateien?
Das hängt von ihrer Rolle ab.
Header können sein:
Teil einer größeren, bereits in der SBOM abgebildeten Komponente
Header-only-Bibliotheken, die in die Anwendung einkompiliert werden
Generierte Konfigurationseingaben
Öffentliche Schnittstellen einer Binärbibliothek
Ungenutzte Dateien, die lediglich in einem SDK liegen
Jeden Header als eigenständige Softwarekomponente zu listen erzeugt meist Rauschen. SBOM-Details auf Dateiebene können für Nachweise oder Audits nützlich sein, aber die Komponentenidentität sollte in der Regel auf Ebene von Bibliothek, SDK-Modul, RTOS, Middleware oder Anwendungsmodul bleiben.
Für Header-only-Code liefern Compile-Abhängigkeiten und Include-Pfade stärkere Nachweise als ein Verzeichnis-Scan allein.
Wie erzeuge ich SBOMs für verschiedene Firmware-Varianten?
Erzeugen Sie eine SBOM pro auslieferbarer Konfiguration.
Debug-Build, Release-Build, Bootloader, Anwendungs-Image, Board-Revision, regionsspezifische Funkkonfiguration und Feature-Flag-Kombinationen können unterschiedliche Komponenten enthalten. Eine einzige „Master-SBOM" für das Repository kann sie nicht zuverlässig alle abbilden.
Jede SBOM sollte verknüpft sein mit:
Produkt und Firmware-Version
Build-ID oder Artefakt-Hash
Ziel-MCU oder Hardware-Revision
Build-Konfiguration
Feature- oder Produktvariante
Quellcode-Revision
Toolchain-Version
Erzeugungszeitpunkt
Bewahren Sie für Geräteflotten die Zuordnung von Gerät oder Gerätekohorte zu Firmware-Artefakt und SBOM. Genau das erlaubt einem Security-Team die Antwort auf die Frage: „Welche Geräte im Feld enthalten die betroffene Komponente?"
Was ist mit Geräten, die 10 oder 20 Jahre im Feld bleiben?
Lange Produktlebensdauer macht SBOM-Management zu einer Release-Engineering-Disziplin – nicht zu einer einmaligen Compliance-Aufgabe.
Archivieren Sie die SBOM mit jedem ausgelieferten Artefakt, auch mit Hotfixes und Backports. Bewahren Sie Quellcode-Revision, Build-Konfiguration, Compiler- und Linker-Versionen, Lieferanten-SBOMs, manuelle Ergänzungen und die Hashes, die nötig sind, um das Inventar zu reproduzieren oder zu erklären.
Die SBOM muss auch dann noch verfügbar sein, wenn der ursprüngliche SDK-Download, das CI-Image, der Entwickler-Arbeitsplatz oder das Lieferantenportal längst verschwunden sind.
Verlangt der EU Cyber Resilience Act eine SBOM?
Der EU Cyber Resilience Act verpflichtet Hersteller, im Rahmen der Schwachstellenmanagement-Pflichten eine SBOM in einem gängigen, maschinenlesbaren Format zu erstellen, die mindestens die Top-Level-Abhängigkeiten des Produkts abdeckt. Die Verordnung gilt allgemein ab dem 11. Dezember 2027; die Meldepflichten der Hersteller nach Artikel 14 gelten bereits ab dem 11. September 2026. Der maßgebliche Text ist die Verordnung (EU) 2024/2847.
Zwei Nuancen sind wichtig.
Erstens: Der CRA verlangt nicht, dass jede SBOM automatisch an alle Nutzer veröffentlicht wird. Die Nutzerinformationen müssen angeben, wo die SBOM zugänglich ist, falls der Hersteller sie Nutzern bereitstellt; Behörden können relevante technische Dokumentation und SBOM-Informationen nach der Verordnung anfordern.
Zweitens: „Top-Level-Abhängigkeiten" sind ein rechtliches Minimum – nicht zwingend ein operativ ausreichendes Inventar. Wer auf eine kritische Schwachstelle reagiert, braucht oft deutlich tiefere Sichtbarkeit in Komponenten und transitive Abhängigkeiten, als das Minimum allein bietet.
Dieser Artikel ist Engineering-Leitfaden, keine Rechtsberatung. Produktumfang, Konformitätsbewertung, sektorspezifische Regeln und vertragliche Lieferpflichten sollten mit qualifizierten Juristen geprüft werden.
Wer ist verantwortlich, wenn Lieferanten keine SBOM liefern?
Der Hersteller des Endprodukts braucht trotzdem ein belastbares Inventar und einen Schwachstellenmanagement-Prozess für alles, was er integriert.
Lieferanten-SBOMs sind der bevorzugte Ausgangspunkt, weil Lieferanten ihre eigenen Komponenten am besten kennen. Einkaufs- und Entwicklungsverträge sollten einfordern:
CycloneDX oder SPDX in maschinenlesbarem Format
Eine SBOM pro geliefertem Artefakt oder Release
Stabile Versions- und Artefakt-Hashes
Lieferanten- und Herkunftsinformationen
Lizenzdaten
Security-Support-Zeitraum
Zusagen zu Schwachstellen-Offenlegung und Updates
VEX für bekannte Schwachstellen mit hoher Auswirkung, wo angemessen
Liefert ein Lieferant nur ein PDF oder eine Tabelle, bewahren Sie diese als Quellnachweis auf – normalisieren Sie die Komponentendaten aber in den Release-SBOM-Prozess. Machen Sie maschinenlesbare Lieferung zum Vertragsziel, statt das Format offenzulassen.
Sind manuell gepflegte SBOM-Daten akzeptabel?
Ja – wenn sie strukturiert, versionsverwaltet, geprüft und wiederholbar sind.
Manuelle Arbeit ist nicht der Feind. Unverfolgte manuelle Arbeit ist es.
Pflegen Sie manuelle Ergänzungen als separate YAML-, JSON- oder andere prüfbare Eingabe unter Versionskontrolle. Geben Sie jeder Komponente eine Mindestidentität, dokumentieren Sie, warum sie ergänzt wurde, und führen Sie sie in der Release-Pipeline mit den automatisch erkannten Komponenten zusammen.
Das ist angemessen für:
Proprietäre Archive und Blobs
Zugekaufte Protokoll-Stacks
SDKs mit fehlenden Metadaten
Gepatchte Komponenten
Geschlossene SPS- oder OT-Bibliotheken
Komponenten, die außerhalb des regulären Quell-Repositorys geliefert werden
Bevorzugtes Ergebnis ist eine einheitliche SBOM pro Release. Erfordern organisatorische Zwänge getrennte generierte und manuell kuratierte SBOMs, versionieren Sie sie gemeinsam und fügen Sie sie als ein Release-Set zusammen oder referenzieren Sie sie als solches.
Sind Conan, vcpkg, PlatformIO, Zephyr und Yocto einfacher?
Sie bieten mehr Struktur – aber das finale Artefakt bleibt entscheidend.
Conan und vcpkg verbessern Komponentenbenennung und Versionsauflösung für die von ihnen verwalteten Abhängigkeiten. Manuell kopierte Quellen, proprietäre Archive oder jede Toolchain-Laufzeit beschreiben sie nicht automatisch.
PlatformIO zentralisiert Framework- und Bibliotheksmetadaten; Teams sollten dennoch prüfen, ob die deklarierten Bibliotheken zur gewählten Umgebung und finalen Firmware passen.
Zephyr und west bieten manifestbasierte Quellrevisionskontrolle über Module hinweg. Das ist eine starke Grundlage für eine SBOM, besonders kombiniert mit konfiguriertem Build und Link-Ausgabe.
Yocto ist eines der reifsten Embedded-Linux-Ökosysteme für SBOM-Erzeugung. Die
create-spdx-Klasse kann SPDX-Informationen für Images und SDKs direkt aus dem Build-System generieren.
Die Grundregel bleibt: Paket- oder Manifest-Metadaten für Identität, Build-Metadaten für Auswahl, Artefakt-Nachweise für den ausgelieferten Umfang.
Was ist mit SPS- und geschlossenen OT-Engineering-Umgebungen?
Geschlossene OT-Umgebungen geben oft weniger Build-Details preis als MCU- oder Embedded-Linux-Workflows. Abhängigkeiten können in proprietären Projektcontainern, Herstellerbibliotheken, Funktionsbausteinen oder Engineering-Tool-Exporten verborgen sein.
Nutzen Sie die stärksten Nachweise, die die Plattform bietet:
Exportierte Bibliotheksinventare
Projekt- oder Automatisierungs-APIs
Vom Hersteller gelieferte SBOMs
Signierte Bibliothekspakete und Hashes
Release-Manifeste
Eine versionsverwaltete manuelle Komponentenliste
Behaupten Sie keine Präzision auf Artefaktebene, wenn die Engineering-Umgebung sie nicht liefern kann. Benennen Sie Nachweisquelle und Konfidenzniveau – und verbessern Sie den Prozess über Lieferantenanforderungen und unterstützte Export-Schnittstellen.
Wie sieht ein praxistauglicher SBOM-Workflow für Embedded-Firmware aus?
Arbeiten Sie in Schichten:
Bauen Sie die exakte Release-Konfiguration. Erzeugen Sie die finale SBOM nicht aus einem beliebigen Entwickler-Checkout.
Sammeln Sie Lieferanten-SBOMs und Release-Metadaten. Bewahren Sie die Originaldateien auf.
Lesen Sie Projekt- und Build-System-Metadaten. Einschließlich gewählter Targets, Konfigurationen, Quelldateien, Include-Pfade, Archive und Toolchain-Einstellungen.
Erzeugen Sie eine Linker-Map. Gleichen Sie deklarierte oder kompilierte Eingaben mit dem ab, was im Artefakt angekommen ist.
Identifizieren Sie einkopierte Quellen. Ordnen Sie kopierte Quellbäume und Submodule Upstream-Komponenten und -Versionen zu.
Ergänzen Sie intransparente Komponenten manuell. Erfassen Sie Hashes, Lieferanten, Versionen, Lizenzen und Lieferreferenzen.
Generieren Sie CycloneDX oder SPDX. Validieren Sie das Dokument gegen das jeweilige Schema.
Prüfen Sie Diagnosen und Unbekanntes. Werten Sie das bloße Erzeugen einer Datei nicht als Beleg für SBOM-Qualität.
Verknüpfen Sie die SBOM mit dem Artefakt. Speichern Sie Firmware-Hash, Build-ID, Quellrevision und Variante.
Archivieren, überwachen, aktualisieren. Nutzen Sie die SBOM für Schwachstellenanalysen und erstellen Sie VEX, wenn eine Schwachstelle nicht ausnutzbar ist.
Wie erzeugt lynkctl eine Embedded-C/C++-SBOM?
lynkctl liest die Build-Nachweise, die Embedded-Projekte ohnehin erzeugen. Es unterstützt GNU-Make-, CMake- und IAR-Embedded-Workbench-Projekte, einschließlich .ewp- und .eww-Dateien. Bei STM32CubeMX-Projekten liefern .ioc-Metadaten Paket- und Target-Kontext, während Build- und Link-Nachweise für den Komponentenumfang maßgeblich bleiben.
Es baut das Projekt nicht neu. Führen Sie es nach dem regulären Release-Build aus, sodass konfigurierter Build-Baum, Artefakte und Linker-Map verfügbar sind.
Für ein GNU-Make-Firmware-Projekt:
Für CMake:
Für IAR Embedded Workbench:
Wenn ein Drittanbieter-Quellbaum explizite Komponentengrenzen braucht:
Wenn maßgebliche Metadaten fehlen oder korrigiert werden müssen, nutzen Sie einen versionsverwalteten Override:
Abschluss des Abschnitts: Das Ergebnis ist nicht bloß eine Dateiliste. Es ist ein aus dem gewählten Build abgeleitetes Komponenteninventar, angereichert um Komponentenidentität und gestützt auf Nachweise, die standhalten, wenn ein Kunde, Auditor oder Security-Engineer fragt: „Warum steht diese Komponente in der SBOM?"
Wie sieht eine hochwertige Embedded-SBOM aus?
Eine hochwertige Embedded-SBOM ist:
Artefaktspezifisch: an die tatsächlich ausgelieferte Firmware gebunden
Konfigurationsspezifisch: an Board, Target und Feature-Set gebunden
Build-bewusst: aus realen Projekt- und Compiler-Eingaben abgeleitet
Link-bewusst: unterscheidet ausgelieferten Code von totem oder ungenutztem Code
Lieferanten-informiert: nutzt maßgebliche Upstream-Metadaten wieder
Ehrlich bei Unsicherheit: dokumentiert Nachweise, Konfidenz und Unbekanntes
Vollständig bei intransparenten Eingaben: umfasst proprietäre und vorkompilierte Komponenten
Reproduzierbar: kann neu erzeugt und sinnvoll verglichen werden
Operativ nutzbar: speist Schwachstellen-Monitoring, VEX, Kundenlieferung und Incident Response
Der schwierigste Teil der Embedded-SBOM-Erzeugung ist nicht, gültiges JSON zu produzieren. Er besteht darin, eine belastbare Aussage darüber zu treffen, was in einem bestimmten Firmware-Image steckt.
Deshalb kombiniert der richtige Embedded-SBOM-Prozess Automatisierung mit Engineering-Nachweisen. Automatisieren Sie, was die Toolchain beweisen kann. Bewahren Sie, was Lieferanten wissen. Ergänzen Sie intransparente Komponenten über kontrollierte manuelle Eingaben. Und wiederholen Sie den Prozess für jedes Release und jede auslieferbare Variante.
Letzte Frage: Wo sollte ein Team anfangen?
Beginnen Sie mit einem Produktions-Firmware-Target und einer Release-Konfiguration.
Aktivieren Sie eine Linker-Map. Sammeln Sie die relevanten SDK- und Lieferanten-Metadaten. Erzeugen Sie die erste SBOM aus dem fertigen Build. Gehen Sie jede unbekannte Komponente und jeden False Positive mit dem Firmware-Team durch. Stellen Sie die Korrekturen unter Versionskontrolle – und machen Sie denselben Workflow zum Teil der Release-Pipeline.
Sie brauchen am ersten Tag keine perfekte Automatisierung. Sie brauchen einen Prozess, der korrekt und prüfbar ist – und mit jedem Release besser wird.
Wenn Sie eine SBOM aus STM32CubeMX, MCUXpresso, einem nRF-Firmware-Projekt, GNU Make, CMake oder IAR Embedded Workbench erzeugen wollen: Interlynks Embedded-C/C++-SBOM-Tooling wurde genau für die Lücke zwischen dem SDK, das Sie erhalten haben, und der Firmware, die Sie tatsächlich ausliefern, gebaut.