CMake SBOM-Generierung: Native, manuelle und build-bewusste Ansätze
| Interlynk
Wie Sie 2026 ein SBOM aus einem CMake-Build erzeugen - CMakes neue native SBOM-Unterstützung, Open-Source-Module, Binäranalyse und build-bewusste Generierung im Vergleich, mit dem, was jeder Ansatz erfasst und übersieht.
Vier Wege zu einem SBOM aus einem CMake-Build
Es gibt vier Wege, aus einem CMake-Projekt eine Software Bill of Materials (SBOM) zu gewinnen, und jeder liest einen anderen Teil Ihres Builds. CMake bietet inzwischen eine native, experimentelle SBOM-Generierung direkt aus seinem Build-Graphen. Sie können außerdem Open-Source-Module ergänzen, eine Binäranalyse des fertigen Images durchführen oder eine build-bewusste Generierung nutzen, die nach dem Build die tatsächlichen Compiler- und Linker-Aufrufe liest, die Ihr Build erzeugt.
Dieser Leitfaden zeigt, was jeder Ansatz sieht und wo er endet. Bei eingebetteten Systemen und Firmware liegen kritische Komponenten häufig im toten Winkel der üblichen Build-Graph-Werkzeuge.
Die kurze Antwort
CMake kann eine SBOM nativ aus seinem Build-Graphen erzeugen, was der schnellste Einstieg für Projekte ist, die vollständig in CMake gebaut werden. Der Build-Graph übersieht jedoch eingebundene Quelldateien (vendored source), vorkompilierte statische Bibliotheken und Vendor-SDKs. Open-Source-Module teilen diese Grenzen. Die Binäranalyse prüft das fertige Ergebnis, stützt sich aber auf abgeleitete Identitäten. Die build-bewusste Generierung liest nach dem Build die Compiler- und Linker-Aufrufe des realen Builds, ohne erneuten Build, und bewahrt Nachweise je Komponente. Wählen Sie den Ansatz, der jede Schicht Ihres ausgelieferten Binaries abdeckt.
Was CMakes native SBOM leistet
CMake enthält eine experimentelle SBOM-Generierung, die Dokumente direkt aus seinem Abhängigkeitsgraphen für Kompilierung und Linking erstellt. Wird sie zur Konfigurationszeit aktiviert, gibt sie SPDX-Dokumente für die von CMake aufgelösten Targets aus. Da sie interne Target-Strukturen liest, statt Rohdateien zu scannen, läuft sie schnell und ordnet First-Party-Targets sauber neben den von CMake aufgelösten Abhängigkeiten ein.
Die native SBOM-Unterstützung von CMake ist experimentell und entwickelt sich weiter. Prüfen Sie die offizielle CMake-Dokumentation, um aktuelle Flag-Namen und die Versionskompatibilität vor dem Produktiveinsatz zu bestätigen.
Einen genaueren Blick auf die Funktion selbst gibt CMakes native SBOM-Funktion.
Die vier Ansätze im Vergleich
Hier sehen Sie, was jede Methode untersucht, wo sie stark ist und wo sie an Grenzen stößt.
Ansatz | Was er liest | Erfasst gut | Übersieht | Am besten, wenn |
|---|---|---|---|---|
Native CMake SBOM (experimentell) | CMake-Build-Graph | First-Party-Targets und von CMake aufgelöste Abhängigkeiten. Schnell, ohne externe Werkzeuge | Eingebundene Quelldateien ohne Target, vorkompilierte statische Bibliotheken, Vendor-SDKs | Ihr Projekt wird vollständig über CMake-Targets gebaut und braucht einen schnellen, standardkonformen Einstieg |
Open-Source-CMake-Module (z. B. Community- | CMake-Projektdateien über ergänzte Skripte | Anpassbare Ausgabeformate, zugeschnitten auf bestehende CMake-Workflows | Dieselben Build-Graph-Grenzen; erfordert manuelle Pflege | Sie brauchen volle Skriptkontrolle und möchten die Integration selbst betreuen |
Binär-/Firmware-Analyse | Kompilierte Binaries und Firmware-Images | Komponenten, die physisch im ausgelieferten Binary vorhanden sind | Genaue Komponentenversionen und Quell-Provenienz; die Identität wird abgeleitet und ist bei gestrippten Builds unzuverlässig | Sie haben nur Zugriff auf kompilierte Binaries oder müssen fertige Images verifizieren |
Build-bewusste Generierung ( | Die Compiler- und Linker-Aufrufe, die Ihr Build erzeugt, sowie das Artefakt (nach dem Build, ohne erneuten Build) | Eingebundene Quellen, statische Archive und Vendor-SDKs mit Nachweisen auf Quellcode-Ebene | Erfordert kommerzielles Werkzeug (kostenlose Stufe verfügbar) | Sie liefern regulierte oder eingebettete Firmware und brauchen prüffähige Nachweise |
Diese Methoden ergänzen einander. Engineering-Teams beginnen oft mit der nativen CMake-Ausgabe und ergänzen die build-bewusste Generierung, sobald Drittanbieter-SDKs und statische Bibliotheken ins Spiel kommen.
Wo jeder Ansatz endet
Eingebettete Builds bestehen aus mehreren Schichten, und tiefere Schichten liegen oft außerhalb des CMake-Build-Graphen:
Paketmanager-Manifeste (Conan, vcpkg): Für alle vier Ansätze sichtbar.
CMake-Build-Targets: Native CMake und Open-Source-CMake-Module reichen bis hierher.
Eingebundener Quellcode (vendored source): Die build-bewusste Generierung erfasst diese Schicht; graphbasierte Methoden übersehen sie.
Vorkompilierte statische Archive (
.a/.lib): Build-bewusste Werkzeuge erfassen diese direkt; die Binäranalyse leitet ihre Identität ab.Silicon-Vendor-SDKs (ST, NXP, TI, Renesas): Build-bewusste Werkzeuge verfolgen modifizierte SDK-Quellen; andere Methoden übersehen sie.
Fertiges Firmware-Image: Die Binäranalyse liest die kompilierten Bytes; build-bewusste Werkzeuge führen diese Bytes auf den Quellcode zurück.
Je tiefer eine Schicht liegt, desto weniger ist sie für den CMake-Graphen sichtbar. Lesen Sie unsere Analyse dazu, warum SBOMs für C/C++ schwierig sind, um diese Sichtbarkeitslücken im Detail zu verstehen.
Ein durchgerechnetes Beispiel
Wir haben einen realen Trusted-Firmware-M-Build auf einem STM32H5-MCU über CMake bis zur SBOM verarbeitet und dokumentiert, was jede Schicht zutage förderte. Lesen Sie die Schritt-für-Schritt-Beschreibung in Trusted Firmware-M auf einem STM32H5.
Wann welcher Ansatz
Reine CMake-Anwendungen: Nutzen Sie die native CMake-SBOM-Generierung. Sie deckt ab, was Sie kompilieren, und erfordert minimale Einrichtung.
Firmware mit Vendor-SDKs oder statischen Bibliotheken: Nutzen Sie die build-bewusste Generierung. Die Verfolgung von Schwachstellen setzt Sicht auf Komponenten unterhalb des CMake-Target-Graphen voraus.
Ausgelieferte Binaries ohne Build-Zugriff: Nutzen Sie die Binäranalyse, um Komponenten im kompilierten Image zu finden, und behandeln Sie Versionsnummern als abgeleitet, bis Sie einen build-bewussten Durchlauf ausführen.
Wie Interlynk hier passt
Interlynks Generator lynkctl arbeitet build-bewusst. Er läuft nach Ihrem bestehenden Make-, CMake-, IAR- oder TI-Code-Composer-Build, ohne erneuten Build, und liest die tatsächlichen Compiler- und Linker-Aufrufe. So erfasst er den eingebundenen Code, statische Archive und Silicon-SDKs, die rein graphbasierte Werkzeuge übersehen. Er erfasst Nachweise auf Komponentenebene, bis hin zur Quelldatei, der Compile-Zeile und einer Konfidenzstufe, damit Sicherheitsprüfer nachvollziehen können, warum jeder Eintrag im Manifest steht. Er läuft in air-gapped Umgebungen und gibt die Formate CycloneDX 1.6+ und SPDX 3.0+ aus. Sehen Sie sich den C/C++ SBOM-Generator für eingebettete Software an. Für Teams, die in regulierte Märkte liefern, bildet lynkctl FDA 524B und den EU Cyber Resilience Act direkt ab.
Häufige Fragen
Kann CMake selbst eine SBOM erzeugen?
Ja. Über kürzlich eingeführte experimentelle Funktionen gibt CMake SPDX-SBOMs direkt aus seinem Build-Graphen während Konfiguration und Installation aus. Es deckt interne Targets und von CMake aufgelöste Abhängigkeiten ab; prüfen Sie daher, ob es Ihren eingebundenen Code und Ihre statischen Bibliotheken erfasst, bevor Sie es für Compliance einsetzen.
Was übersieht CMakes native SBOM?
Es übersieht Komponenten außerhalb des Target-Build-Graphen, darunter direkt in den Baum kopierten Quellcode, vorkompilierte statische Bibliotheken und Silicon-Vendor-SDKs. Da eingebettete Firmware stark auf diese Bestandteile angewiesen ist, kombinieren Teams CMake regelmäßig mit build-bewussten Werkzeugen.
CycloneDX oder SPDX für ein CMake-Projekt?
Beide Formate funktionieren in diesen Workflows. CMake erzeugt SPDX nativ, während lynkctl sowohl CycloneDX 1.6+ als auch SPDX 3.0+ ausgibt. Wählen Sie das Format, das Ihre nachgelagerten Scanner oder Aufsichtsbehörden verlangen.
Wie erzeuge ich eine SBOM für Firmware, die mit IAR- oder TI-Toolchains gebaut wurde?
Ein build-bewusster Generator liest die Compiler- und Linker-Aufrufe von IAR-Embedded-Workbench- und TI-Code-Composer-Builds nach deren Ausführung, ohne CMake vorauszusetzen. Erfahren Sie mehr über den C/C++ SBOM-Generator für eingebettete Software.
Gibt es kostenlose Optionen?
Die native CMake-SBOM-Funktion und Community-CMake-Module sind kostenlos nutzbar. Interlynk bietet zudem eine kostenlose Stufe. Beginnen Sie mit dem kostenlosen Ansatz, der zu Ihrer Build-Umgebung passt, und ergänzen Sie die build-bewusste Generierung, wenn Sie Drittanbieter-SDKs und statische Bibliotheken prüfen müssen.
Wie es weitergeht
Einen Überblick über das breitere Ökosystem gibt unser Leitfaden zu den besten SBOM-Tools.