So bewerten Sie einen SBOM-Generator für Embedded-Firmware
| Ritesh Noronha
Ein SBOM-Generator kann bei einem Beispielprojekt mit Lockfile und klar deklarierten Abhängigkeiten wirkungsvoll aussehen. Die eigentliche Bewertung beginnt, wenn Sie ihn gegen Ihre eigene Firmware laufen lassen: ein Make- oder IAR-Projekt mit einem Vendor-SDK und einem third_party-Ordner. Erkennt er die Komponenten, die Ihre Firmware verwendet, übersieht er die meisten davon, oder meldet er alles im SDK?
In mehr als 50 Proofs of Concept mit unserem Tool lynkctl für die Embedded-C/C++-SBOM-Erzeugung und in Gesprächen mit über 100 Ingenieuren hat sich ein gemeinsames Muster gezeigt: Eine Bewertung ist nur dann nützlich, wenn Ingenieure ihre eigene Firmware verwenden und wissen, was sie vom Tool erwarten. Diese Leitlinien beruhen auf dieser Erfahrung und helfen Ingenieuren, kommerzielle und Open-Source-SBOM-Generatoren zu bewerten, einschließlich unseres eigenen. Nutzen Sie sie, um eine Bewertung um Ihren Build, Ihre Abhängigkeiten und die Anforderungen Ihres Teams herum aufzubauen.
Bevor Sie beginnen
Repräsentative Projekte
Als Ingenieure sind wir darauf trainiert, zu messen, bevor wir etwas ändern. Die Bewertung eines SBOM-Generators verlangt dieselbe Disziplin. Beginnen Sie mit der Auswahl eines Projekts, das Ihre Umgebung repräsentiert. Embedded-C/C++-Projekte haben oft ihre eigene Mischung aus Build-Systemen, Toolchains und Praktiken zur Abhängigkeitsverwaltung, nehmen Sie sich also Zeit für diese Auswahl. Ein Projekt kann genügen, oder Sie brauchen mehrere, um die Arten abzudecken, wie Ihr Team Firmware baut.
Erfassen Sie, wie Open-Source-Software in diese Projekte gelangt: vendored Bibliotheken, kopierte Quelldateien, git-Submodule, CMake FetchContent oder Downloads über curl und andere Skripte. Dokumentieren Sie die SDKs und Toolchains, die Sie verwenden, einschließlich ihrer Runtime-Bibliotheken. Das gibt Ihnen eine Grundlage, um zu prüfen, was der Generator entdeckt und was er übersieht.
SBOM-Erwartungen
Bevor Sie die Tools ausführen, definieren Sie, was Sie im SBOM erwarten. Diese Erwartungen können sich aus geltenden Vorschriften, aus den Security- und Compliance-Teams Ihrer Organisation oder daraus ergeben, wie Sie die Ausgabe nutzen wollen. Zu klärende Fragen sind:
Soll er alle Open-Source-Komponenten auflisten, die in der Firmware verwendet werden?
Soll er alle statisch gelinkten Bibliotheken identifizieren?
Soll er alle dynamisch gelinkten Bibliotheken identifizieren, sofern zutreffend?
Soll er die verwendeten SDKs und SDK-Komponenten identifizieren?
Soll er die Provenienz der Build-Tools enthalten, etwa Compiler-, Linker- und Toolchain-Versionen?
Soll er Code weglassen, der nicht in die ausgelieferte Firmware gelinkt ist?
Dokumentieren Sie die erwarteten Komponenten und alle bekannten Versionen als Referenz für die Bewertung. Nutzen Sie diese Anforderungen, um zu beurteilen, ob die Ausgabe den Bedürfnissen Ihres Teams entspricht. Wenn Sie eine detaillierte Checkliste benötigen, wenden Sie sich an uns unter support@interlynk.io. Wir helfen Ihnen, eine für Ihre Umgebung zusammenzustellen.
SBOM-Anzahl abschätzen
Zählen Sie die SBOMs, die Sie erzeugen müssen, bevor Sie mit einem Anbieter sprechen. Die Zahl ist fast immer höher, als Teams erwarten. Selbst wenn Sie ein einziges Firmware-Image ausliefern, besteht es meist aus mehreren separat gebauten Teilen: einem Bootloader, der Anwendung, einem Funk- oder Coprozessor-Image sowie gemeinsam genutzten Bibliotheken oder Plattformcode, der über Produkte hinweg wiederverwendet wird. Idealerweise erhält jedes davon sein eigenes SBOM, auf das das Top-Level-SBOM der Firmware dann verweist, sodass eine gemeinsam genutzte Komponente einmal beschrieben wird und ein Fix darin überall auftaucht, wo sie verwendet wird.
Dann multiplizieren Sie. Zählen Sie Ihre Produktvarianten (dieselbe Codebasis, für verschiedene Boards, Regionen oder Funktionssätze gebaut, ergibt unterschiedliche Binaries mit unterschiedlichen Inhalten) und zählen Sie die im Feld unterstützten Releases, da jedes ein SBOM benötigt, das so lange überwacht wird, wie Geräte es ausführen. Ein Unternehmen mit fünf Produkten, je vier Komponenten, drei Varianten und zwei unterstützten Releases verwaltet 120 SBOMs, nicht fünf.
Diese Zahl ist für die Bewertung in zweierlei Hinsicht wichtig. Sie sagt Ihnen, ob ein Tool praktikabel ist, das pro Projekt manuelle Einrichtung erfordert, und sie sagt Ihnen, was eine Preisgestaltung pro SBOM oder pro Projekt wirklich kostet.
Den SBOM-Generator bewerten
Findet er Code ohne Manifest?
Die meisten Firmware-Abhängigkeiten wurden von einer Person in den Baum kopiert. Es gibt keine package.json, kein Lockfile, oft keine Versionsdatei. Tools, die durch Lesen von Manifesten arbeiten, wozu Syft und Trivy in ihren Standardmodi gehören, liefern für diese Projekte wenig oder nichts. Das ist kein Fehler dieser Tools; sie wurden genau dafür entworfen.
Achten Sie auf die Identifikation vendored Bibliotheken wie FreeRTOS, lwIP, Mbed TLS oder FatFs aus dem Quellcode selbst. Prüfen Sie, wie viel das Tool über das hinaus entdecken kann, was ein Paketmanager deklariert hat.
Ermittelt er die richtige Version?
Ein Komponentenname ohne Version ist für das Vulnerability-Matching nutzlos. Vendored Code macht Versionen schwierig: Die Version kann in einem Header-Makro, einem Changelog oder nirgends stehen. Silizium-Anbieter liefern zudem modifizierte Forks aus, sodass „FreeRTOS 10.4.3" in einem ST- oder NXP-SDK möglicherweise nicht Byte-identisch mit Upstream ist.
Vergleichen Sie gemeldete Versionen mit Ihrer Ground Truth. Fragen Sie, wie das Tool mit fehlenden Versionsinformationen, Unsicherheit und modifiziertem Code umgeht, und prüfen Sie, ob seine Belege die gemeldete Version stützen.
Meldet er, was ausgeliefert wird, oder was im Repository liegt?
Ein Vendor-SDK kann Hunderte von Komponenten enthalten. Ihr Build kompiliert vielleicht ein Dutzend, und der Linker verwirft ungenutzte Teile davon. Ein SBOM des Repositorys überberichtet, was bedeutet, dass Ihr Team Schwachstellen in Code triagiert, der nie ein Gerät erreicht. Ein SBOM allein des Binaries unterberichtet, weil kompiliertes C sehr wenig identifizierende Information behält.
Fragen Sie, ob das Tool zwischen Code im Baum, kompiliertem Code und in das Image gelinktem Code unterscheidet. Prüfen Sie die gemeldeten Komponenten gegen Ihren Build, um zu verstehen, ob das SBOM das Repository oder die ausgelieferte Firmware beschreibt.
Kommt er mit statischem Linken und Toolchain-Bibliotheken zurecht?
Firmware ist statisch gelinkt. Sobald der Linker alles zu einem Image zusammenführt, sind die Komponentengrenzen weg, und Binary-Scanner tun sich schwer. Es gibt außerdem Code in Ihrem Image, der nie in Ihrem Quellbaum auftaucht: die C-Runtime (newlib oder die IAR-Runtime-Bibliothek), libgcc und Startup-Code aus der Toolchain. Diese haben Versionen, Lizenzen und gelegentlich Schwachstellen.
Prüfen Sie, ob statisch gelinkte Bibliotheken und Runtime-Komponenten der Toolchain im SBOM erscheinen. Fragen Sie, welche Build- oder Linker-Informationen das Tool braucht, um Code zu identifizieren, der von außerhalb Ihres Quellbaums kommt.
Funktioniert er mit Ihrem tatsächlichen Build?
Fragen Sie, was das Tool von Ihnen braucht. Manche erfordern ein bestimmtes Build-System (Zephyrs west spdx und Yoctos create-spdx sind gut und funktionieren nur innerhalb dieser Ökosysteme). Manche erfordern einen Rebuild mit einem Wrapper um den Compiler. Manche brauchen einen Cloud-Upload von Quellcode oder Binaries, was sie für Verteidigungs- und viele Medizinteams ausschließt.
Bewerten Sie das Tool mit Ihrem tatsächlichen IAR-, Keil-, Make- oder CMake-Build. Verstehen Sie den Integrationsaufwand, alle erforderlichen Build-Änderungen und ob es offline laufen kann, falls Ihr Team das braucht. Prüfen Sie Anforderungen an Quell- und Binary-Uploads früh gegen Ihre Rahmenbedingungen.
Können Sie sehen, warum er jede Identifikation getroffen hat?
Jedes Tool in diesem Bereich nutzt Heuristiken, und Heuristiken machen Fehler. Entscheidend ist, ob Sie sie überprüfen können. Für jede Komponente sollten Sie die Belege sehen können: welche Dateien, welche Compile-Zeile, welcher Hash oder String übereingestimmt hat und wie sicher das Tool ist. Ein Prüfer wird Ihnen dieselbe Frage stellen.
Inspizieren Sie die Belege für einzelne Komponenten, einschließlich unsicherer Identifikationen. Fragen Sie, wie Konfidenz kommuniziert wird und ob Ihr Team die Ergebnisse überprüfen und korrigieren kann.
Passen die Identifikatoren zu Schwachstellendatenbanken?
Ein SBOM ist nur so nützlich wie seine Identifikatoren. Embedded-Komponenten sind schlecht abgedeckt: Viele haben keine CPE in der NVD, PURLs sind für Code, der nicht in einem Paketregister liegt, uneinheitlich, und Vendor-Forks lassen sich nicht sauber auf Upstream-Einträge abbilden. Lassen Sie das SBOM durch einen Vulnerability-Scanner laufen und schauen Sie in beide Richtungen: bekannte CVEs, die übersehen wurden, und Falschtreffer.
Überprüfen Sie die CPE- und PURL-Zuordnungen gegen bekannte Komponenten und Schwachstellen. Fragen Sie, wie das Tool mit Komponenten ohne etablierte Zuordnung umgeht und ob Korrekturen über nachfolgende Läufe hinweg bestehen bleiben.
Erfasst er genug, damit das SBOM konform gemacht werden kann?
Regulierungsbehörden erwarten, dass jede Komponente bestimmte Daten trägt. Die NTIA Minimum Elements von 2021 verlangten Lieferant, Name, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehungen, SBOM-Autor und Zeitstempel. Die CISA-Aktualisierung von 2026 ergänzt Komponenten-Hashes, Lizenzen, den Namen des erzeugenden Tools und den Erzeugungskontext, und die Anforderungen von FDA, EU CRA und BSI TR-03183 gehen weiter. Erwarten Sie nicht, dass ein Generator all das zur Scan-Zeit ausfüllt. Vollständige Anreicherung während des Code-Scans ist schwierig, und für Embedded-Code oft unmöglich: Eine vendored Datei trägt keinen Lieferantennachweis, und eine in Ihren Baum kopierte Bibliothek hat keinen Registry-Eintrag zum Nachschlagen. Lieferantennamen, normalisierte Lizenzen und End-of-Life-Daten kommen von außerhalb des Codes und werden besser nachträglich durch eine SBOM-Management-Plattform ergänzt.
Was der Generator leisten muss, ist alles zu erfassen, was nur der Quellcode und der Build liefern können, weil kein nachgelagertes Tool es später wiederherstellen kann: Hashes, den tatsächlich im Quellcode gefundenen Lizenz- und Copyright-Text, genaue Namen und Versionen, PURL- und CPE-Identifikatoren, wo sie bestimmbar sind, Abhängigkeitsbeziehungen sowie den Tool-Namen und den Erzeugungskontext. Testen Sie beide Hälften. Prüfen Sie, was der Generator erfasst hat, laden Sie das SBOM dann in die Management-Plattform, die Sie einsetzen wollen, lassen Sie deren Anreicherung laufen und bewerten Sie das Ergebnis mit einem Tool wie sbomqs.
Ist die Ausgabe reproduzierbar und standardkonform?
Bauen Sie denselben Commit zweimal und vergleichen Sie die SBOMs. Sie sollten bis auf Zeitstempel identisch sein. Validieren Sie die Ausgabe dann gegen das CycloneDX- oder SPDX-Schema und bewerten Sie sie mit einem Open-Source-Qualitätstool wie sbomqs. Wenn Sie unter FDA 524B, der EU CRA oder BSI TR-03183 ausliefern, prüfen Sie die erforderlichen Felder jetzt, nicht in der Woche vor der Einreichung.
Prüfen Sie auf konsistente Komponentendaten über Läufe hinweg, valide Ausgabe und die von Ihrem Team benötigten Felder. Vergewissern Sie sich, dass das SBOM von den anderen Tools in Ihrem Workflow konsumiert werden kann.
Wie ist die Preisgestaltung strukturiert?
Führen Sie das Preisgespräch von vornherein. Kommerzielle Generatoren berechnen möglicherweise pro SBOM, pro Repository oder pro Scan-Lauf. Fragen Sie, was als abrechenbare Einheit gilt, und schätzen Sie die Kosten anhand Ihrer erwarteten Anzahl von Projekten, Build-Varianten und CI-Läufen. Ein Preis, der während eines Proof of Concept vernünftig aussieht, kann anders aussehen, wenn das Tool bei jedem Build läuft.
Open-Source-Generatoren sind in der Regel kostenlos nutzbar, auch wenn Einrichtung und Wartung dennoch Engineering-Zeit kosten. Wenn ein Open-Source-Tool Ihre Anforderungen erfüllt und in Ihrer Umgebung gut funktioniert, nutzen Sie es.
Wie sieht der Bewertungszeitplan aus?
Legen Sie den Zeitplan fest, bevor Sie beginnen, und halten Sie jedes Tool daran. Ein vernünftiger Plan sind ein bis drei Wochen insgesamt: ein erstes SBOM innerhalb von ein bis zwei Tagen nach der Installation, eine Woche, um die obigen Tests gegen Ihre Ground Truth durchzuführen, und eine Woche, um ein zweites Projekt mit einer anderen Toolchain oder einem anderen Target zu versuchen, da ein Tool, das für das erste Projekt von den Ingenieuren des Anbieters getunt wurde, beim zweiten oft strauchelt. Halten Sie fest, wer die Arbeit gemacht hat. Eine Bewertung, die nur mit dem Anbieter am Steuer gelingt, ist ein Dienstleistungsprojekt, kein Tool.
Die Ergebnisse einordnen
Zählen Sie für jedes Tool drei Zahlen gegen Ihre Ground Truth: korrekt gefundene Komponenten, übersehene Komponenten und gemeldete Komponenten, die nicht vorhanden sind. Übersehene Komponenten sind die teuren, denn eine Schwachstelle, von der Sie nichts wissen, lässt sich nicht beheben. Falschmeldungen kosten bei jedem Release Engineering-Zeit. Ein Tool, das 90 % mit klaren Belegen findet, schlägt eines, das 100 % behauptet und seine Arbeit nicht belegen kann.
Verschiedene Ansätze bieten unterschiedliche Abdeckung. Manifest-Reader sind hervorragend, wo Manifeste existieren. Binäranalyse ist die einzige Option, wenn ein Lieferant Ihnen Firmware ohne Quellcode gibt. Build-Zeit-Analyse sieht am meisten für Code, den Sie selbst bauen, weshalb wir bei lynkctl, Interlynks Embedded-SBOM-Generator, diesen Ansatz gewählt haben. Die meisten Teams kombinieren am Ende zwei. Warum, führe ich in The State of SBOM Generation for C/C++ aus.
Wenn Sie diese Leitlinien nutzen, um ein Tool an Ihrer eigenen Firmware zu bewerten, würde ich gern hören, was Sie herausfinden, auch wo unser Tool zu kurz kommt.
FAQ: Weitere Fragen, die wir gehört haben
In welcher Phase der Build-Pipeline muss der SBOM-Generator laufen?
Funktioniert der Generator mit meinem bestehenden Build-System, oder erfordert er die Umstellung des Projekts auf ein anderes System wie CMake?
Nutzt das Tool Informationen aus vorhandenen Paketmanagern wie vcpkg, wenn diese vorhanden sind?
Wenn Claude oder Codex ein SBOM erzeugen können, das korrekt aussieht, warum brauche ich einen dedizierten SBOM-Generator?
Scannt das Tool einfach Verzeichnisse, oder versteht es meine Toolchain und wie die Firmware gebaut wird?
Wie geht es mit gemeinsam genutztem Code um?
Wie führen wir SBOMs zusammen?