Der Stand der SBOM-Generierung für C/C++: Ausgabe 2026
| Ritesh Noronha
Wenn Sie der Meinung sind, dass die SBOM-Generierung ein gelu00f6stes Problem ist, arbeiten Sie wahrscheinlich nicht mit C/C++.
Ein guter SBOM-Generator sollte drei Dinge gut beherrschen: pru00e4zise sein, reproduzierbar sein und das darstellen, was sich tatsu00e4chlich in der Binu00e4rdatei oder Firmware befindet, die Sie ausliefern. Fu00fcr u00d6kosysteme mit ausgereiften Paketmanagern und maschinenlesbaren Abhu00e4ngigkeits-Metadaten ist dies erheblich einfacher. JavaScript hat package-lock.json, Python hat oft poetry.lock, Rust hat Cargo.lock und Go hat go.sum. Diese Dateien machen die SBOM-Generierung zwar nicht trivial, bieten aber in der Regel einen viel klareren Ausgangspunkt als dies bei C/C++ der Fall ist.
Fu00fcr C/C++ haben wir diesen Luxus nicht. Und in der Embedded-Welt, in der C/C++ dominiert, ist die Lu00fccke zwischen dem, was SBOM-Tools erzeugen, und dem, was sich tatsu00e4chlich in Ihrer Firmware befindet, riesig.
Ich habe viel Zeit mit der Entwicklung von SBOM-Tools fu00fcr Embedded C/C++-Projekte verbracht und mu00f6chte eine ehrliche Einschu00e4tzung des heutigen Stands der Dinge teilen u2013 was funktioniert, was nicht und warum ein kombinierter Ansatz der einzige realistische Weg zu einer einigermau00dfen genauen SBOM ist.
Die Managed Dependency Story: Besser, aber nicht das ganze Bild
Werkzeuge wie CMake, Conan, vcpkg und Meson haben eine gewisse Struktur in das C/C++-Abhängigkeitsmanagement gebracht. Wenn Ihr Projekt Conan verwendet, können Sie eine conan.lock-Datei erhalten. Wenn Sie vcpkg im Manifest-Modus verwenden, haben Sie zumindest ein vcpkg.json-Manifest und Versionsbeschränkungen. Die FetchContent-Deklarationen von CMake dokumentieren ebenfalls, was zum Konfigurationszeitpunkt herangezogen wird.
Einige SBOM-Tools können diese Metadaten nutzen und einen brauchbaren Ausgangspunkt für zumindest einen Teil des Abhängigkeitsgraphen erstellen. Für den Teil der C/C++-Welt, der modernes Abhängigkeitsmanagement konsequent eingeführt hat, ist die SBOM-Situation besser als früher, auch wenn sie immer noch unvollständig ist.
Dieser Teil ist klein, insbesondere im Embedded-Bereich. Die meisten Embedded-C/C++-Projekte, auf die ich stoße, werden nicht mit Conan oder vcpkg erstellt. Sie werden mit einfachen Makefiles erstellt – manchmal handgeschrieben, manchmal von einer IDE wie IAR Embedded Workbench oder STM32CubeIDE generiert. Die Verbreitung von CMake wächst im Embedded-Bereich, ist aber weitem nicht universell. Und selbst Projekte, die CMake verwenden, haben oft eine Mischung aus FetchContent, Systembibliotheken, Git-Submodulen und herstellerspezifischem Quellcode (Vendored Source), die kein einzelnes Tool vollständig erfasst.
Der fu00fcr `-l` Flag Ansatz: Nu00fctzlich, aber unzureichend
Eine gängige Technik zur Identifizierung von C/C++-Abhängigkeiten ist die Überprüfung von Linker-Eingaben – insbesondere von -l-Flags und Linker-Suchpfaden. Wenn Ihr Build mit -lssl -lcrypto -lz verlinkt, kann ein Tool möglicherweise auf OpenSSL und zlib schließen und dies mit Paketmanager-Metadaten anreichern, wenn diese Bibliotheken vom Betriebssystem oder einer bekannten Paketquelle stammen. Dies kann sowohl dynamische Bibliotheken (.so / .dylib) als auch statische Archive (.a) abdecken, wenn der Build sie explizit benennt.
Bei Desktop- und Server-Builds kann dieser Ansatz Sie reasonably weit bringen. Die -l-Flags, kombiniert mit Linker-Suchpfaden (-L), verraten Ihnen oft, welche Bibliotheken herangezogen werden. Statische .a-Archive, die auf diese Weise verlinkt sind, sind zudem sichtbarer als direkt in das Ziel kompilierter Quellcode (Vendored Source).
Doch selbst wenn dieser Ansatz bei der Identifizierung einer Komponente erfolgreich ist, gibt es ein tiefer liegendes Problem: Er liefert Ihnen oft nur einen Bibliotheksnamen und manchmal eine Version, aber nicht viel mehr. Die Mindestelemente der NTIA umfassen den Namen des Anbieters, den Namen der Komponente, die Version, eindeutige Identifikatoren, Abhängigkeitsbeziehungen, den Ersteller der SBOM-Daten und den Zeitstempel. Ein -l-Flag verrät Ihnen vielleicht einen Bibliotheksnamen. Eine .a-Datei liefert Ihnen möglicherweise nur einen Dateinamen wie libfoo.a, mit wenig oder gar keiner maschinenlesbaren Herkunft darüber, wer sie erstellt hat, woher sie stammt oder welche Upstream-Version sie darstellt. Wenn die Bibliothek nicht aus einer Paketquelle mit Metadaten stammt, müssen die verbleibenden NTIA-Felder meist auf andere Weise ermittelt werden – und für die meisten C/C++-Projekte gibt es keinen automatisierten „anderen Weg“.
Im Bereich eingebetteter Systeme (Embedded World) ist die Situation erheblich schlechter. Builds für eingebettete Firmware nutzen oft überhaupt keine -l-Flags, die auf systemweit installierte Pakete verweisen. Stattdessen kompilieren sie das RTOS, den HAL, den Netzwerk-Stack, die Krypto-Bibliothek und die Middleware direkt aus den Quellen – oder sie verlinken gegen projektlokale .a-Dateien, die zuvor aus Fremdcode (Vendored Code) mit wenigen angehängten Metadaten erstellt wurden. Die resultierende Binärdatei ist häufig monolithisch. Es gibt unter Umständen keine Laufzeitabhängigkeits-Informationen im Stile von ldd zu inspizieren, keine DT_NEEDED-Einträge in ELF-Headern, und entfernte Symbole (Stripped Symbols) reduzieren das, was eine Binäranalyse wiederherstellen kann. Eine statische .a-Datei, die im Order lib/ eines Projekts liegt und Monate zuvor aus einer unbekannten Upstream-Version erstellt wurde, ist für SBOM-Zwecke fast wie eine Blackbox – und eine Compliance-Lücke für jede Regulierung, die mehr als nur einen Komponentennamen verlangt.
Fremdcode: Die wahre Herausforderung
Hier wird es wirklich schwierig, und hier unterscheidet sich das C/C++-SBOM-Problem meiner Meinung nach am stärksten von Ökosystemen mit starken Paketmanager-Konventionen.
Einbindung von Fremdcode (Vendored Code) ist in C/C++ allgegenwärtig. Entwickler kopieren Quelldateien — manchmal ein einziges .c- und .h-Paar, manchmal ganze Bibliotheksbäume — direkt in ihr Projekt. Bibliotheken wie nlohmann/json, mongoose, stb_image, miniz und lwIP werden routinemäßig auf diese Weise integriert. In ihrer eigenen Dokumentation wird Ihnen oft genau das empfohlen: „Kopieren Sie diese beiden Dateien in Ihr Projekt“. Einmal kopiert, ist der Code nicht mehr von eigenem Quellcode zu unterscheiden.
Fingerprinting ist eine der Haupttechniken zur Erkennung von Fremdcode und funktioniert in den einfachen Fällen gut. Wenn ein Entwickler eine unveränderte Kopie einer eigenständigen Bibliothek eingebunden hat, können Sie die Dateien hashen, mit einer Sammlung bekannter Releases abgleichen und erhalten oft eine treffsichere Übereinstimmung. Bei kleinen, in sich geschlossenen Bibliotheken kann dies sehr zuverlässig sein.
Die Fremdcode-Einbindung bringt jedoch Komplikationen mit sich, die das Fingerprinting eher zu einem heuristischen als zu einem deterministischen Spiel machen.
Modifikationen sind an der Tagesordnung. Entwickler binden Code ein und modifizieren ihn anschließend — sie beheben Fehler, passen APIs an oder entfernen ungenutzte Funktionen. Sobald eine Datei geändert wird, schlägt der exakte Hash-Abgleich fehl. Man bewegt sich im Bereich des Fuzzy-Matchings: Abgleich gegen bekannte Versionen, Nutzung von Techniken wie MinHash oder Winnowing für Code-Ähnlichkeiten oder strukturelle Vergleiche auf AST-Ebene. Diese Ansätze können funktionieren, bringen aber Unsicherheit mit sich. Handelt es sich um eine modifizierte Kopie von FreeRTOS 10.4.3 oder um FreeRTOS 10.5.1 mit anderen Modifikationen? Die Antwort ist wichtig für die CVE-Korrelation, und die Tools können sie Ihnen oft nicht mit Sicherheit liefern.
Hersteller-SDKs sorgen für Rauschen. Halbleiterhersteller wie ST, NXP, TI und Renesas liefern SDKs aus, die Open-Source-Komponenten — FreeRTOS, lwIP, mbedTLS, FatFS — zusammen mit proprietärem HAL-Code enthalten. Diese Pakete fügen oft herstellerspezifische Copyright-Header hinzu, ändern Verzeichnisstrukturen, benennen Dateien um und forken manchmal den Upstream-Code erheblich. STM32CubeF4 enthält eine Version von FreeRTOS, die den Anpassungsprozess von ST durchlaufen hat. Das Renesas FSP bündelt ein ThreadX-Derivat. Ein Fingerprinting dieser Versionen gegen Upstream-Releases ist ohne herstellerspezifische Erkennungslogik unzuverlässig.
Embedding-Modelle und ML-basierte Code-Ähnlichkeit können helfen, und es gibt interessante wissenschaftliche Arbeiten zur Nutzung erlernter Code-Repräsentationen zur Identifizierung von Softwarekomponenten. Aber heute sind diese Ansätze in der Regel operativ zu aufwendig für eine routinemäßige SBOM-Generierung in der CI im großen Stil. Sie mögen bei einmaligen Audits oder Untersuchungen mit hohem Sicherheitsbedarf eine Rolle spielen, sind aber noch kein einfacher Ersatz für simplere Techniken.
Das Problem mit dem gemeinsamen Vendor-Ordner
Es gibt eine praktische Hürde, die meiner Meinung nach in SBOM-Diskussionen nicht oft genug besprochen wird. Die meisten C/C++-Entwickler bewahren ihren externen Code (Vendored Code) in separaten Ordnern auf – vendor/, 3rdparty/, external/, lib/ –, was die Verwaltung vereinfacht. Das ist eine gute Praxis und hilft SBOM-Tools dabei, die Grenze zwischen eigenem Code (First-Party) und Drittanbieter-Code (Third-Party) zu erkennen.
Doch in der Praxis, insbesondere in der Embedded-Entwicklung, wird ein solcher Vendor-Ordner oft von mehreren Projekten oder Build-Zielen gemeinsam genutzt. Ein vendor/-Verzeichnis enthält möglicherweise FreeRTOS, lwIP, mbedTLS, FatFS und ein Dutzend andere Bibliotheken. Projekt A verwendet FreeRTOS und lwIP. Projekt B verwendet FreeRTOS und mbedTLS. Projekt C verwendet alle davon.
Ein SBOM-Generator, der einfach den gesamten Vendor-Ordner inventarisiert, erstellt eine SBOM, die alle diese Komponenten auflistet – aber diese SBOM ist für jedes einzelne Build-Artefakt fehlerhaft. Sie übertreibt, was tatsächlich im Binärcode enthalten ist. Wenn Projekt A mbedTLS nicht verwendet, führt die Auflistung in der SBOM von Projekt A zu Fehlalarmen bei Schwachstellenscans und stellt die tatsächliche Angriffsfläche falsch dar.
Selbst wenn der gesamte Code in einem Vendor-Ordner kompiliert und gelinkt wird, sorgt das Linker-Flag --gc-sections dafür, dass alle Abschnitte, die vom Einstiegspunkt aus nicht erreichbar sind, per Garbage Collection entfernt werden. Sie kompiliert vielleicht 30 gemeinsame Bibliotheken in Ihren Build, aber wenn deren Funktionen nie aufgerufen werden, tragen sie null Bytes zur finalen Binärdatei bei. Sie alle als Komponenten in Ihrer SBOM aufzuführen, würde zu ungenauen, falsch-positiven Ergebnissen führen.
In vielen Embedded-Projekten besteht der zuverlässigste Weg, dies richtig zu machen, darin, zu verstehen, was das Build-System tatsächlich für ein bestimmtes Ziel kompiliert und linkt. Was uns wieder zum Build-System als wichtigster Quelle der Wahrheit zurückführt und erklärt, warum eine Analyse zur Build-Zeit für Embedded C/C++ meist unerlässlich ist.
Die reale Welt ist unordentlich: Ein kombinierter Ansatz
Keine einzelne Technik löst das C/C++-SBOM-Problem. Nach der Auseinandersetzung mit den verschiedenen Ansätzen – Manifest-Parsing, Untersuchung von Linker-Flags, Datei-Fingerprinting, Binäranalyse, Build-System-Instrumentierung – bin ich zu der Überzeugung gelangt, dass ein kombinierter Ansatz der einzige Weg zu einer einigermaßen genauen SBOM ist. Konkret müssen Sie vier Signale zusammenführen:
Was gebaut wird. Das Build-System – ob Make, CMake, Meson, IAR oder etwas anderes – weiß, welche Quelldateien kompiliert und welche Bibliotheken für ein bestimmtes Ziel verlinkt werden. Die Instrumentierung des Build-Prozesses liefert Ihnen die absolute Wahrheit darüber, was in die Binärdatei einfließt. Das ist das Fundament.
Was eingekauft/mitgeliefert wird (Vendoring). Verzeichnis-Fingerprinting, Datei-Hashing und die Extraktion von Versionszeichenfolgen können bekannte Open-Source-Komponenten in Vendor-Verzeichnissen identifizieren. Der Schlüssel liegt darin, dies mit dem abzugleichen, was das Build-System tatsächlich verwendet – nicht nur mit dem, was auf der Festplatte vorhanden ist. Eine Komponente in vendor/, die niemals für Ihr Ziel kompiliert wird, sollte nicht in Ihrer SBOM erscheinen.
Für welche Plattform oder welchen Mikrocontroller gebaut wird. Die Zielplattform schränkt ein, welche SDKs und HAL-Bibliotheken des Herstellers im Spiel sind. Wenn Sie für einen STM32F4 bauen, wissen Sie, dass STM32CubeF4 HAL-Komponenten wahrscheinlich vorhanden sind. Wenn Sie auf einen Renesas RA6M4 abzielen, haben Sie es mit Renesas FSP zu tun. Das Plattformbewusstsein ermöglicht es Ihnen, den Suchraum einzugrenzen und herstellerspezifische Erkennungsheuristiken anzuwenden. Es hilft auch beim CPE/PURL-Mapping, da die Benennung von eingebetteten Komponenten stark herstellerspezifisch ist.
Statisches Abhängigkeitsmanagement. Das Verständnis darüber, wie statische Bibliotheken (.a, .lib) verlinkt sind, welche Objektdateien sie enthalten und woher sie stammen, vervollständigt das Bild. Map-Dateien (.map), Linker-Skripte und Archivinhalte liefern alle Hinweise. Für IAR-Projekte listen .map-Dateien jede Objektdatei auf, die in das endgültige Image verlinkt wurde. Bei GCC-basierten Builds enthüllt ar -t auf statischen Archiven deren Inhalt.
Jedes dieser Signale für sich allein ist unvollständig. Zusammen können sie Ihnen zu einer genaueren SBOM verhelfen, was in der Regel das ist, worauf es bei Schwachstellenmanagement, Beschaffung und regulatorischer Berichterstattung ankommt.
Dies ist das Design, auf dem lynkctl, der kommerzielle SBOM-Generator für eingebettetes C/C++ von Interlynk, aufbaut – Toolchain-bewusste Extraktion aus GNU Make, CMake und IAR, gepaart mit einem kuratierten Index für eingebettete Open-Source-Software für die Vendor-Ebene.
Der Kontext für Entwickler ist nach wie vor wichtig
Automatisierte Erkennung ist wichtig, aber für C/C++-Projekte, insbesondere im Embedded-Bereich, spielt der vom Entwickler bereitgestellte Kontext immer noch eine große Rolle. Das Entwicklungsteam weiß oft am besten, welche Vendor-Bibliothek einkopiert wurde, woher sie stammt, welche Patches angewendet wurden und welche Komponenten zu welcher Build-Variante gehören. Dieser Kontext ist genau die Art von Information, die automatisierte Scanner nur schwer zuverlässig aus Quellcode-Verzeichnissen, Archiven und gestrippten Binärdateien rekonstruieren können.
Das bedeutet nicht, dass manuelle oder von Entwicklern gepflegte Manifeste ein Allheilmittel sind. Sie können veralten, Abhängigkeiten übersehen oder von der Realität abweichen, wenn sie nicht eng in den Build-Prozess eingebunden sind. In der Praxis können sie jedoch eine nützliche Ergänzung zur automatisierten Analyse sein, insbesondere für Metadaten zu Herkunft, Lieferant, Lizenzierung und Build-Varianten, die sich im Nachhinein nur schwer ableiten lassen.
Strukturierte Komponenten-Metadaten sind die fehlende Ebene in SBOMs – und Interlynk hilft dabei, diese zu definieren. Mit der neuen Generate-SBOM-Funktionalität von sbomasm ermöglichen wir es Teams, den Entwickler-Kontext genau dort zu erfassen, wo er entsteht, was automatisches Scannen und Build-Zeit-Analysen erheblich zuverlässiger macht.
Wie geht es von hier aus weiter?
Das C/C++-SBOM-Problem wird nicht durch ein einzelnes Werkzeug oder eine einzige Technik gelöst werden. Es erfordert einen mehrschichtigen Ansatz, der Build-System-Intelligenz, die Erkennung von Drittanbieter-Code, plattformbewusste Heuristiken und gemeinschaftlich gepflegte Verzeichnisse bekannter eingebetteter Bibliotheken und deren Fingerabdrücke kombiniert.
Die Embedded-C/C++-Community muss zudem in eine bessere Dependency-Hygiene investieren: die Einführung von Paketmanagern, wo dies machbar ist, die Pflege expliziter Manifeste für Drittanbieter-Code und die Behandlung der SBOM-Erstellung als erstklassiges Build-Artefakt statt als Nebensache.
Für diejenigen unter uns, die Werkzeuge in diesem Bereich entwickeln, ist die Chance klar: Wer auch immer die Kluft zwischen der Unordnung realer C/C++-Projekte und den strukturierten, präzisen SBOMs, die Vorschriften fordern, zuverlässig überbrücken kann, wird eines der am schwersten zu lösenden Probleme in der Sicherheit der Software-Lieferkette lösen.
Und das wird ein SBOM sein, dem Sie vertrauen und das Sie überprüfen können.
Erfahren Sie mehr über den Ansatz von Interlynk für Embedded
Zitate
CMake, "FetchContent," offizielle Dokumentation: https://cmake.org/cmake/help/latest/module/FetchContent.html
NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)," Juli 2021: https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf
Europäische Kommission, "Cyber Resilience Act - Implementation," aufgerufen am 9. April 2026: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
FDA, "Medical Device Software Guidance Navigator," einschließlich "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions": https://www.fda.gov/medical-devices/regulatory-accelerator/medical-device-software-guidance-navigator
The White House, "Executive Order on Improving the Nation's Cybersecurity" (Executive Order 14028), 12. Mai 2021: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
sbomasm, "Ihr SBOM-Assembler" : https://github.com/interlynk-io/sbomasm
Häufig gestellte Fragen
Wie erstelle ich eine SBOM für eine C/C++-Codebasis?
Erzeugen Sie zur Build-Zeit eine CycloneDX- oder SPDX-SBOM und kombinieren Sie mehrere Signale, denn für C/C++ reicht keine einzelne Technik aus. Nutzen Sie vorhandene Paketmanager-Metadaten (eine conan.lock von Conan, ein vcpkg.json-Manifest oder CMake-FetchContent-Deklarationen), werten Sie Linker-Eingaben aus (-l-Flags und -L-Suchpfade), um System- und statische Bibliotheken zu identifizieren, und gleichen Sie eingebetteten (vendored) Quellcode per Fingerprinting mit bekannten Releases ab. Ein kombinierter Ansatz ist der einzige realistische Weg zu einer einigermaßen genauen SBOM.
Warum ist die SBOM-Erzeugung für C/C++ schwieriger als für andere Sprachen?
Ökosysteme wie JavaScript (package-lock.json), Python (poetry.lock), Rust (Cargo.lock) und Go (go.sum) liefern Tools einen maschinenlesbaren Abhängigkeitsgraphen als Ausgangspunkt. Für C/C++ gibt es kein Äquivalent. Code wird häufig vendored (direkt in das Projekt kopiert), aus dem Quellcode kompiliert oder als projektlokale .a-Archive ohne Provenienzdaten eingebunden – daher übersehen die meisten Tools große Teile dessen, was tatsächlich in der Binärdatei oder Firmware ausgeliefert wird.
Können CMake, Conan oder vcpkg eine SBOM erzeugen?
Sie helfen, lösen das Problem aber nicht vollständig. Conan kann eine conan.lock erzeugen, der Manifest-Modus von vcpkg liefert eine vcpkg.json mit Versionsbeschränkungen, und CMake-FetchContent dokumentiert, was zur Konfigurationszeit eingebunden wird – ein SBOM-Tool kann daraus einen Teil des Abhängigkeitsgraphen aufbauen. Doch die Verbreitung ist gering, besonders im Embedded-Bereich, wo einfache Makefiles, IAR- oder STM32CubeIDE-Projekte, Git-Submodule und vendored Quellcode üblich sind und kein einzelnes Tool alles erfasst.
Wie erfasse ich vendored bzw. kopierten C/C++-Code in einer SBOM?
Vendored Code – etwa nlohmann/json, mongoose, stb_image oder lwIP, der in das Projekt kopiert wurde – ist nicht mehr von eigenem Quellcode zu unterscheiden. Fingerprinting (Dateien hashen und mit einem Korpus bekannter Releases abgleichen) funktioniert bei unveränderten Kopien, doch sobald Code angepasst wurde, ist Fuzzy-Matching wie MinHash, Winnowing oder ein Vergleich auf AST-Ebene nötig, was Unsicherheit mit sich bringt. SDKs von Chip-Herstellern wie ST, NXP, TI und Renesas, die Upstream-Komponenten forken und umbenennen, erzeugen zusätzliches Rauschen.
Funktioniert das Auswerten der Linker-Flags (-l) bei Embedded-C/C++-Builds?
Das Auswerten von -l-Flags und -L-Suchpfaden kann bei Desktop- und Server-Builds Bibliotheken wie OpenSSL oder zlib identifizieren, besonders wenn sie aus einer Paketquelle stammen. Es liefert jedoch meist nur einen Namen und manchmal eine Version – nicht die vollständigen NTIA-Mindestelemente (Lieferant, eindeutige Bezeichner, Abhängigkeitsbeziehungen). Embedded-Firmware kompiliert RTOS, HAL und Krypto oft aus dem Quellcode oder bindet projektlokale .a-Dateien ohne Metadaten ein, sodass die reine Linker-Auswertung erhebliche Lücken lässt.
Welches SBOM-Format sollte ein C/C++-Projekt verwenden?
Verwenden Sie CycloneDX oder SPDX. Beide sind offene, maschinenlesbare Standards und die erwarteten Formate für Compliance-Vorgaben wie die FDA-Premarket-Leitlinie und den EU Cyber Resilience Act. Ein guter C/C++-SBOM-Generator sollte genaue, reproduzierbare Ausgaben erzeugen, die abbilden, was tatsächlich in der ausgelieferten Binärdatei oder Firmware enthalten ist.