Wie unterscheiden sich die vier Wege?
| Quellcode | Binary | Lieferanten-SBOM | Von Hand | |
|---|---|---|---|---|
| Liest | Projektordner, Bibliotheken, Build-Skripte | Das Image, wie es ausgeliefert wird | CycloneDX- oder SPDX-Datei | Map-Datei, Release Notes, Stücklisten |
| Stark bei | Eigener Entwicklung | Zugekaufter Firmware, alten Ständen | Teilen ohne Quellcode | Einzelfragen |
| Endet bei | Code, den der Linker entfernt | Versionen ohne Beleg im Binary | Der Aussage des Zulieferers | Dem Aufwand je Firmware-Stand |
| Braucht | Quellcode, auch der Zulieferer | Die Datei | Die Datei vom Zulieferer | Zeit und jemanden, der den Build kennt |
Was liefert die Analyse des Quellcodes?
- Was gelesen wird
- Der Projektordner, die eingebundenen Bibliotheken und, wo es sie gibt, Paketmanager und Build-Skripte.
- Stark bei
- Eigener Entwicklung mit vollem Zugriff. Die Abhängigkeiten sind sichtbar, bevor ein Build existiert, und eine Lücke lässt sich direkt an der Quelle beheben.
- Wo es endet
- Im Projektordner steht auch Code, den der Linker nie ins Image übernimmt. Die CISA nennt genau das als Grenze dieses SBOM-Typs. In einem öffentlichen Keil-Projekt steht
vTaskEndSchedulerin tasks.c, im AXF fehlt die Funktion. In C-Projekten ohne Paketmanager fehlt außerdem die Datei, aus der ein Werkzeug die Liste sonst liest. - Was Sie brauchen
- Den Quellcode, auch den der Zulieferer.
- Variante beim Bauen
- Die SBOM entsteht beim Bauen selbst. Laut CISA erhöht das die Sicherheit, dass sie das gebaute Artefakt richtig beschreibt. Dafür muss unter Umständen der Build-Prozess angepasst werden.
Was liefert die Analyse des ausgelieferten Binarys?
- Was gelesen wird
- Das Image, so wie es ausgeliefert wird. Bei Embedded Linux das Dateisystem mit seinen Paketdaten und Programmen, bei Mikrocontrollern das ELF oder AXF aus Keil, IAR oder GCC, zur Not das BIN.
- Stark bei
- Zugekaufter Firmware, alten Ständen und allen Fällen ohne Entwicklungsumgebung. Die CISA nennt alte Firmware als Beispiel. Ein Zugriff auf den Build ist nicht nötig, und das Ergebnis eignet sich, um SBOMs aus anderen Quellen gegenzuprüfen. Gezählt wird, was im Gerät steckt.
- Wo es endet
- Erkennt die Analyse eine Komponente nicht, fehlt sie in der Liste; die CISA nennt Auslassungen als Grenze dieses Typs. Eine Version steht nicht immer im Binary. Im Keil- und im GCC-Beispiel stand die FreeRTOS-Version nur in den Debug-Informationen, das BIN nannte sie nicht. Der Ambiq-HAL im Keil-Beispiel und TouchGFX im GCC-Beispiel kamen als fertiges Archiv: Funktionsnamen im Binary, keine Version. Ein ehrliches Ergebnis lässt diese Version leer. Verschlüsselte Images sind ohne Schlüssel nicht lesbar; der Hersteller selbst kann das unverschlüsselte Build-Ergebnis prüfen lassen.
- Was Sie brauchen
- Die Datei. Je mehr Debug-Informationen sie trägt, desto mehr Versionen sind belegt: Das ELF oder AXF liefert mehr als das BIN.
Was taugt die SBOM des Zulieferers?
- Was gelesen wird
- Eine CycloneDX- oder SPDX-Datei, die der Zulieferer zu seinem Modul, Stack oder Betriebssystem liefert. Beide Formate nennt die Technische Richtlinie TR-03183-2 des BSI.
- Stark bei
- Teilen, die Sie nie im Quellcode sehen. Der Zulieferer kennt sein Produkt am besten, und die Datei lässt sich direkt in die eigene Stückliste übernehmen.
- Wo es endet
- Die SBOM ist eine Aussage des Zulieferers über einen bestimmten Stand. Ob sie zur ausgelieferten Firmware passt, zeigt erst der Abgleich mit dem Binary. Fehlen Versionen oder eindeutige Kennungen, lässt sich die Komponente schwer mit Schwachstellendaten verbinden.
- Was Sie brauchen
- Die Datei vom Zulieferer, passend zur verbauten Version.
Wann lohnt sich die Prüfung von Hand?
- Was gelesen wird
- Map-Datei, Linker-Ausgabe, Release Notes, Lizenzdateien, Stücklisten aus dem Einkauf.
- Stark bei
- Einzelfragen, bei denen ein Mensch den Zusammenhang kennen muss, etwa ob eine Funktion auf diesem Gerät überhaupt erreichbar ist.
- Wo es endet
- Der Aufwand fällt mit jedem Firmware-Stand neu an.
- Was Sie brauchen
- Zeit und jemanden, der den Build kennt.
Welcher Weg passt in welcher Lage?
Die Wege schließen sich nicht aus. Eine SBOM darf Angaben aus mehreren Quellen zusammenführen.
| Ihre Lage | Was passt |
|---|---|
| Eigene Entwicklung, voller Quellcode | Quellcode oder Build, dazu das Binary als Gegenprobe |
| Zugekauftes Modul, nur das Image | Binary, dazu die SBOM des Zulieferers, wenn es eine gibt |
| Zulieferer liefert eine SBOM | SBOM übernehmen und gegen das Binary abgleichen |
| Alter Firmware-Stand im Feld | Binary |
| Eine konkrete Lücke, eine konkrete Frage | Von Hand, auf Basis der SBOM |
Wie wird aus der SBOM eine CVE-Prüfung?
Bekannte Schwachstellen hängen an Komponente und Version. Die Prüfung ist nur so gut wie diese beiden Angaben, egal aus welchem Weg sie kommen. Fehlt die Version, kann niemand sagen, ob eine Lücke zutrifft; dann bleibt das Feld leer und ist als offene Frage markiert.
Eine einzelne Datenbank reicht dafür nicht mehr. Seit dem 15.04.2026 ergänzt die NVD Schweregrad und betroffene Produkte vorrangig bei ausgewählten CVEs, etwa aus dem KEV-Katalog der CISA. Noch nicht bearbeitete CVEs, die vor dem 01.03.2026 veröffentlicht wurden, stehen dort auf „Not Scheduled“. Hinweise der Hersteller und die Datensätze der CVE-Vergabestellen schließen diese Lücke zum Teil.
Was verlangt der CRA?
Anhang I Teil II Nr. 1 verlangt, dass Hersteller die Komponenten ihres Produkts ermitteln und dokumentieren, unter anderem mit einer SBOM in einem gängigen, maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten erfasst. Welcher Weg dahin führt, schreibt der CRA nicht vor. Die Pflicht gilt ab dem 11.12.2027 (Art. 71 Abs. 2).
Wo setzt LegacyMind an?
LegacyMind arbeitet mit dem zweiten und dem dritten Weg: Es liest das ausgelieferte Image, Linux wie Mikrocontroller (ELF, AXF und OUT aus Keil, IAR oder GCC, dazu BIN und HEX), und SBOMs von Zulieferern in CycloneDX oder SPDX. Eine Version, die das Binary nicht belegt, bleibt leer. Danach ordnet LegacyMind neu veröffentlichte CVEs laufend denselben Firmware-Ständen zu.
Häufige Fragen
Kann man eine SBOM ohne Quellcode erstellen?
Ja. Aus dem ausgelieferten Binary lassen sich Komponenten und oft Versionen lesen, aus einem ELF oder AXF mehr als aus einem BIN.
Reicht die SBOM meines Zulieferers?
Sie ist die Aussage des Zulieferers über einen Stand. Der Abgleich mit dem Binary zeigt, ob sie zur ausgelieferten Firmware passt.
Warum kann die Quellcode-Analyse Komponenten zeigen, die nicht im Gerät stecken?
Weil im Projekt auch Code liegt, den der Linker entfernt. Die CISA nennt das als Grenze von Source-SBOMs.
Was passiert, wenn eine Version nicht im Binary steht?
Dann bleibt sie leer und ist eine offene Frage, etwa an den Zulieferer. Eine geratene Version führt zu falschen CVE-Treffern in beide Richtungen.
Welches Format braucht der CRA?
Ein gängiges, maschinenlesbares Format. Die TR-03183-2 des BSI nennt CycloneDX und SPDX.