Firmware-SBOM-Genauigkeit: Source vs Binary und wie Sie nachweisen, was ausgeliefert wird
| Interlynk
Warum Firmware-SBOMs sich widersprechen: Quellcode-Scans sehen, was vorhanden ist, die Binäranalyse sieht das Image, leitet die Identität aber ab, und die build-bewusste Generierung liest den realen Build. Wie Sie erkennen, welche SBOM stimmt, und nachweisen, was wirklich ausgeliefert wurde.
Im Repository vorhanden ist nicht dasselbe wie im Binary ausgeliefert
Lassen Sie drei SBOM-Werkzeuge über dasselbe Firmware-Projekt laufen, und Sie erhalten womöglich drei verschiedene Antworten. Das bedeutet nicht zwangsläufig, dass eines davon fehlerhaft ist. Jeder Ansatz betrachtet einen anderen Abschnitt des Wegs vom Quellcode zum ausgelieferten Image.
Ein Quellcode-Scan meldet, was er im Repository und in den Projekt-Metadaten erkennen kann. Eine Binäranalyse meldet, was sie im Firmware-Image erkennen kann. Ein build-bewusster Generator meldet, welche Eingaben der Build ausgewählt hat und, abgeglichen mit der linker map, welche davon im fertigen Image verblieben sind.
Bei eingebetteter Software liegt die Schwierigkeit der SBOM-Genauigkeit genau in der Lücke zwischen "vorhanden" und "ausgeliefert". Diese Lücke entscheidet auch darüber, ob eine Schwachstellenmeldung eine echte Gefährdung ist oder eine Komponente, die Ihr Team nun auf Anwendbarkeit prüfen muss.
Dieser Leitfaden erklärt, wie sich die drei Ansätze unterscheiden, wo jeder am besten funktioniert und wie Sie einen Nachweispfad für das erstellen, was tatsächlich ausgeliefert wurde.
Die kurze Antwort
Ein Quellcode-Scan ist nützlich, um zu verstehen, was ein Projekt enthält, kann aber Komponenten melden, die nie in ein bestimmtes Image gelangen. Die Binär- und Firmware-Analyse setzt beim ausgelieferten Artefakt an und kann Code erkennen, der wirklich vorhanden ist, wobei Identität und Version der Komponenten oft aus dem Binary abgeleitet werden. Die build-bewusste Generierung liest die Eingaben und die Konfiguration des Builds, um festzustellen, welche Komponenten im Umfang liegen und warum, und gleicht sie dann mit der linker map für das konkrete Image ab. Wenn Sie den Build kontrollieren, ergibt die Kombination aus Build-Nachweisen und image-spezifischen Nachweisen, zusammen mit dem Festhalten dessen, was unbekannt bleibt, die belastbarste Grundlage für eine verteidigungsfähige Firmware-SBOM.
Die richtige Methode hängt von der Frage ab, die Sie beantworten müssen.
Vier Schichten zwischen Ihrem Quellbaum und Ihrer Firmware
Viele Genauigkeitsprobleme entstehen, wenn mehrere verschiedene Fragen als eine behandelt werden. Ein typischer eingebetteter Build hat mindestens vier technische Schichten, dazu eine fünfte Frage zur Zuordnung:
Im Repository vorhanden. Dazu gehören Vendor-SDKs, RTOS-Ports, HAL-Treiber, Krypto- und Netzwerkbibliotheken, Test-Utilities, Beispiel-Apps und alter Kompatibilitätscode.
Von der Build-Konfiguration ausgewählt. Das sind die Targets und Dateien, die die konkrete CMake-, Make- oder IAR-Konfiguration einbezieht.
Kompiliert oder als Build-Eingabe bereitgestellt. Dazu zählen der für den Build kompilierte Quellcode, vorgefertigte statische Archive und andere Artefakte, die in den Link eingehen.
Im fertigen Firmware-Image erhalten. Das sind die Teile, die Linking und Dead-Code-Elimination überstehen und tatsächlich ausgeliefert werden.
Einer Komponente mit Provenienz zuordenbar. Der verbleibende Code muss mit Nachweisen, die Ihr Team verteidigen kann, einer bekannten Komponente und Version zugeordnet werden.
Eine verwundbare Komponente in einem gemeinsam genutzten third_party-Verzeichnis kann auf der ersten Schicht liegen und das fertige Image nie erreichen. Das gesamte Verzeichnis als ausgeliefert zu melden, kann eine große Menge an Schwachstellenmeldungen erzeugen, die für dieses Image gar nicht gelten.
Der umgekehrte Fall ist ebenfalls häufig. Ein statisches Archiv oder eine Toolchain-Runtime kann auf Schicht drei oder vier in den Build eintreten, ohne in einem Paket-Manifest aufzutauchen. Ein reiner Manifest-Scan kann Code übersehen, der wirklich ausgeliefert wird.
Quellcode-SBOMs sind stark bei der Projektinventur
Der Quellbaum-Scan ist ein nützlicher Ausgangspunkt. Das Werkzeug durchläuft das Repository, liest Paket-Manifeste, Lockfiles und eingebundene Quellen (vendored source) und erzeugt ein CycloneDX- oder SPDX-Dokument. Er ist schnell und braucht keinen Build.
Das macht ihn nützlich für eine grundlegende Frage: Was enthält dieses Projekt?
Angenommen, das Repository enthält third_party/mbedtls. Ein Quellcode-Scan kann feststellen, dass das Projekt mbedTLS enthält. Er kann nicht feststellen, dass mbedTLS für ein bestimmtes Board kompiliert, in ein bestimmtes Image gelinkt oder nach der Dead-Code-Elimination erhalten wurde.
Bei serverseitigen Anwendungen, bei denen der Großteil des Repositorys ausgeliefert wird, können Projektinventur und ausgelieferte Software recht nah beieinander liegen. Firmware ist anders. Ein großer Quellbaum kann sich auf ein kleines, target-spezifisches Image reduzieren. Dadurch kann ein Quellcode-Scan weit mehr mögliche Komponenten melden, als in einem einzelnen Image vorhanden sind.
Binär- und Firmware-Analyse beginnt beim Artefakt
Die Binäranalyse arbeitet vom anderen Ende des Prozesses her. Sie untersucht ein kompiliertes Binary oder Firmware-Image und identifiziert die Komponenten, die sie erkennen kann. Das ist der richtige Ansatz, wenn Ihnen nur das ausgelieferte Artefakt vorliegt, etwa Firmware von Dritten oder Altbestände, die Ihr Team nicht gebaut hat. Anbieter wie ONEKEY und Binarly sind auf diesen Anwendungsfall ausgelegt.
Die Binäranalyse kann sehr wirksam sein, wenn das Image starke Hinweise behält, darunter Symbole, eingebettete Metadaten oder erkennbare Versionsangaben. In diesen Fällen kann sie aus dem Artefakt selbst Ergebnisse mit hoher Konfidenz liefern.
Die schwierigere Frage ist die Provenienz. Identität und Version werden oft aus Signaturen, Strings und Heuristiken abgeleitet. Die Konfidenz kann bei gestrippten oder statisch gelinkten Builds deutlich sinken. Eine Binäranalyse kann zeigen, dass eine bestimmte Implementierung wahrscheinlich vorhanden ist, ohne genug Information zu haben, um die genaue Upstream-Quelle, den Fork oder die Version zu bestimmen.
Das macht die Binäranalyse besonders wertvoll, wenn Ihnen nur das Image vorliegt. Wenn Sie den Build kontrollieren, können Build-Aufzeichnungen zusätzliche Nachweise dazu liefern, woher der Code stammt und warum er zu einem bestimmten Target gehört.
Build-bewusste Generierung nutzt die Nachweise aus dem Build
Die build-bewusste Generierung liest den Build selbst. Sie läuft nach Ihrem bestehenden Build, ohne erneuten Build, und liest die Compiler- und Linker-Aufrufe, die der Build erzeugt. Das legt Details offen, die ein reiner Repository-Scan nicht sehen kann, darunter die gewählte Konfiguration, Quelldateien, Compile-Optionen, Include-Pfade, Archiv-Eingaben und Linker-Eingaben.
Sie liefert zwei verwandte Arten von Nachweisen:
Build-Nachweise zeigen, warum eine Eingabe zum gebauten Target gehört.
Linker-map-Nachweise zeigen, ob und wie diese Eingabe im fertigen Image erhalten wurde.
Zusammen ergeben diese Aufzeichnungen ein genaueres Bild, als anzunehmen, dass alles im Repository ausgeliefert wurde. Sie vermeiden es auch, eine Binär-Signatur als Beweis für eine genaue Upstream-Version zu behandeln.
Build-Nachweise begründen Umfang und Provenienz. Identität und Version der Komponente hängen weiterhin von Quell- oder Lieferantenmetadaten ab. Wenn sich diese Angaben nicht bestätigen lassen, sollte die SBOM das kenntlich machen, statt die Felder mit einer Vermutung zu füllen.
Das ist der Ansatz, der einen Großteil der Lücke zwischen dem, was vorhanden ist, und dem, was bei Firmware ausgeliefert wird, schließt. Genau dafür ist Interlynks lynkctl gebaut.
Source vs Binary vs Build-bewusst auf einen Blick
Frage | Quellorientierter Scan | Binär- oder Firmware-Analyse | Build-bewusste Generierung |
|---|---|---|---|
Sieht, was im Projekt vorhanden ist | Ja | Nein | Ja |
Sieht, was das Image erhalten hat | Begrenzt | Ja | Ja, abgeglichen mit der linker map |
Weiß, welche Konfiguration es ausgewählt hat | Manchmal | Nein | Ja |
Identität und Version der Komponente | Aus Manifesten und Quellen, sofern vorhanden | Aus dem Artefakt abgeleitet, mit schwankender Konfidenz | Aus Build-Nachweisen plus Quell- oder Lieferantenmetadaten |
Behandelt statische Archive und eingebundenen Code | Teilweise | Kann beigetragenen Code erkennen, Identität kann aber undurchsichtig sein | Als Build- und Link-Eingaben sichtbar, Provenienz kann weitere Nachweise erfordern |
Braucht Quellen und Build | Nur Quellen | Weder noch | Läuft nach dem Build, ohne erneuten Build |
Am besten geeignet für | Projektinhalte verstehen | Ein Artefakt analysieren, wenn der Build nicht verfügbar ist | Firmware bauen und image-spezifische Provenienz brauchen |
So weisen Sie nach, was tatsächlich ausgeliefert wurde
SBOM-Genauigkeit bedeutet nicht, die größtmögliche Komponentenliste zu erstellen. Es geht darum, den Umfang jeder Komponente klar zu machen und die Nachweise dahinter zu bewahren.
Diese Praktiken helfen, eine SBOM zu erzeugen, die Engineering-, Security- und Compliance-Teams nutzen können:
Gleichen Sie die SBOM mit der linker map des Images ab. Die map-Datei ist image-spezifisch. Ein Bootloader, ein sicheres Firmware-Image und ein Anwendungs-Image sind eigene SBOM-Gegenstände, wenn sie getrennt ausgeliefert oder aktualisiert werden. Erzeugen und gleichen Sie eine SBOM pro Image ab.
Trennen Sie Erkennung von Provenienz. Wurde eine Komponente über eine Binär-Signatur gefunden, halten Sie das als Erkennungsnachweis fest. Ist ihre Quellrevision aus dem Build oder einer Lieferantenangabe bekannt, halten Sie das als Provenienz fest. Das sind verwandte Aussagen, aber nicht dieselbe.
Behandeln Sie Versionen als abgeleitet, bis sie bestätigt sind. Stammt die Identität aus Binär-Heuristiken, kennzeichnen Sie sie so. Bestätigen Sie sie anhand von Build- oder Quellnachweisen, bevor Sie darauf Remediation-Entscheidungen stützen.
Halten Sie fest, was unbekannt bleibt. Lässt sich Lieferant oder Version eines vorgefertigten Archivs nicht ermitteln, sagen Sie das. Eine transparente SBOM ist nützlicher als eine, die jedes Feld mit einem unbelegten Wert füllt.
Trennen Sie Build-Werkzeuge von ausgelieferten Komponenten. Compiler, Linker und Build-System gehören zur Build-Umgebung. Ein Runtime-Archiv, das tatsächlich in das Image gelinkt wird, etwa
libgcc.a, ist etwas anderes und sollte als ausgelieferte Software behandelt werden.
Ein durchgerechnetes Beispiel finden Sie in Trusted Firmware-M auf einem STM32H5. Mehr Hintergrund zur zugrunde liegenden Herausforderung lesen Sie in warum SBOMs für C/C++ schwierig sind.
Wie Interlynk hier passt
Interlynks Generator lynkctl ist die build-bewusste Option. Er läuft nach einem bestehenden Make-, CMake-, IAR- oder TI-Code-Composer-Build, ohne erneuten Build. Er liest die Compiler- und Linker-Aufrufe und gleicht sie mit der linker map ab, sodass die SBOM widerspiegelt, was das Image erhalten hat, statt nur, was im Repository vorhanden ist.
Jede Komponente trägt einen Nachweis mit Angaben wie Quelldatei, Compile-Zeile und Konfidenzstufe. So können Engineering- und Security-Teams sehen, warum eine Komponente erscheint, und gesicherte Nachweise von verbleibender Unsicherheit unterscheiden.
lynkctl kann in einer air-gapped Umgebung laufen und gibt CycloneDX 1.6+ und SPDX 3+ aus.
Für regulierte Produkte kann dieser Nachweis die technische Dokumentation hinter einer SBOM stärken. Es ist eine Umsetzungsentscheidung, kein regulatorisches Format. FDA 524B legt SBOM-Pflichten für Cyber-Devices in ihrem Geltungsbereich fest, und der EU Cyber Resilience Act verlangt eine maschinenlesbare SBOM, die mindestens die Top-Level-Abhängigkeiten abdeckt. Welche Nachweise hinter dieser SBOM erfasst werden, hängt von Ihrem Workflow und Ihren Werkzeugen ab.
Erfahren Sie mehr über den C/C++ SBOM-Generator für eingebettete Software, lesen Sie den umfassenderen Leitfaden zu SBOMs für eingebettete und IoT-Systeme oder vergleichen Sie die Optionen in den vier Wegen zu einem SBOM aus einem CMake-Build.
Häufige Fragen
Warum liefern zwei SBOM-Werkzeuge für dieselbe Firmware unterschiedliche Ergebnisse?
Sie nutzen unterschiedliche Nachweise. Ein Quellcode-Scan meldet, was er im Projekt erkennen kann. Eine Binäranalyse meldet, was sie im ausgelieferten Image erkennt. Ein build-bewusster Generator meldet, welche Eingaben der Target-Build ausgewählt hat und, abgeglichen mit der linker map, welche davon das Image erhalten hat. Am größten sind die Unterschiede bei Firmware, wo sich ein großer Quellbaum auf ein kleines, target-spezifisches Image reduzieren kann.
Ist eine Quellcode-SBOM oder eine Binär-SBOM für Firmware genauer?
Keine ist grundsätzlich genauer. Sie beantworten verschiedene Fragen. Eine Quellcode-SBOM ist nützlich, um Projektinhalte und mögliche Abhängigkeiten zu verstehen. Die Binäranalyse ist nützlich, um Code in einem ausgelieferten Artefakt zu identifizieren. Wenn Sie den Build kontrollieren, können Build-Nachweise eine stärkere Provenienz für das Target liefern, besonders abgeglichen mit image-spezifischen Nachweisen.
Woher weiß ich, was tatsächlich in meinem Firmware-Image ausgeliefert wurde?
Beginnen Sie mit der genauen Release-Konfiguration. Erfassen Sie die Build-Eingaben und erzeugen Sie die zugehörige linker map. Gleichen Sie diese Aufzeichnungen mit dem fertigen Image ab und erzeugen Sie dann eine SBOM pro eigenständig ausgeliefertem Image, statt Bootloader und Anwendung zu einem Gegenstand zusammenzuführen. Bewahren Sie Nachweise je Komponente, damit sich jeder Eintrag auf die Information zurückführen lässt, die ihn stützt.
Erfasst die Binäranalyse statische Bibliotheken korrekt?
Sie kann Code aus einer statischen Bibliothek erkennen, wenn dieser Code erkennbare Hinweise im Image hinterlässt. Der schwierigere Teil ist die Zuordnung. Das Binary enthält möglicherweise nicht genug Information, um die genaue Bibliothek, Version oder den Fork zu bestimmen. Wenn Sie den Build kontrollieren, können Build-Nachweise die Identität und Rolle des Archivs begründen. Die linker map kann dann zeigen, ob es zum Image beigetragen hat.
Welchen Ansatz sollte ich für eine FDA- oder CRA-Einreichung nutzen?
Die Vorschriften schreiben keine einzelne SBOM-Generierungsmethode vor. Wählen Sie einen Workflow, der eine vollständige, maschinenlesbare SBOM für das betreffende Produkt erzeugt und die Nachweise vorhält, die Ihre Qualitäts-, Security- und Regulierungsprozesse verlangen. Für einen Build, den Sie kontrollieren, kann die build-bewusste Generierung nützliche, image-spezifische Provenienz liefern. Für Firmware von Dritten oder Altbestände, bei denen Ihnen nur das Image vorliegt, kann die Binäranalyse nötig sein. Manche Teams nutzen beide Ansätze. Siehe FDA 524B für weitere Informationen.
Wie es weitergeht
Vergleichen Sie die Generierungsmethoden in den vier Wegen zu einem SBOM aus einem CMake-Build, sehen Sie das durchgerechnete Beispiel in Trusted Firmware-M auf einem STM32H5 und entdecken Sie die Kategorie in unserem Leitfaden zu den besten SBOM-Tools.