CMake kann jetzt SBOMs nativ erzeugen: Was es erfasst und was nicht
| Interlynk
CMake hat in einem 2026-Release experimentelle native SBOM-Generierung ergänzt (SPDX 3.0.1, DARPA-finanziert). So aktivieren Sie sie, was sie genau erfasst und wo für Embedded-Firmware weiterhin eine build-bewusste Ebene nötig ist.
Die Neuigkeit: CMake bringt jetzt einen SBOM-Generator mit
CMake hat experimentelle Unterstützung ergänzt, um eine Software Bill of Materials direkt aus dem Build zu erzeugen. Kitware kündigte das Release am 21. September 2026 an. Die Arbeit wurde gemeinsam mit Riverside Research unter dem DARPA-Vertrag HR001124C0489 durchgeführt, und die Beispiele beziehen sich auf CMake 4.3. Für ein Build-System, das Millionen von C- und C++-Projekten antreibt, wird das Erzeugen einer einfachen SBOM zu einem nativen Schalter im bestehenden Build-Prozess, statt zu einem separaten Scan-Werkzeug, das man nachträglich anbindet.
Dieser Beitrag zeigt, was die Funktion heute leistet, wie Sie sie aktivieren, was sie gut erfasst und wo sie noch endet. Den umfassenden Überblick über alle Optionen gibt unser Vergleich der vier Wege, ein SBOM aus einem CMake-Build zu erzeugen.
Was es ist und wie Sie es aktivieren
Die Funktion ist hinter einem experimentellen Flag abgesichert, um eine versehentliche Aktivierung zu verhindern. Sie setzen CMAKE_EXPERIMENTAL_GENERATE_SBOM auf die UUID, die zu Ihrer CMake-Version passt. Das Ausgabeformat wählen Sie mit CMAKE_INSTALL_SBOM_FORMATS=SPDX, und anschließend deklarieren Sie die Generierung in Ihrem Projekt mit den neuen Befehlen install(SBOM) und export(SBOM). CMake erstellt das Dokument aus demselben Abhängigkeitsgraphen, den es zum Kompilieren und Linken verwendet, und schreibt die Ausgabe als SPDX 3.0.1 JSON-LD.
Da die Funktion experimentell ist, sind das Flag, der Befehlsumfang und die unterstützte CMake-Version noch in Bewegung. Prüfen Sie die offizielle CMake-Dokumentation auf die aktuelle UUID und Syntax, bevor Sie sie in eine Pipeline einbauen.
Was es gut erfasst
Für ein Projekt, das seine Targets über CMake installiert und exportiert, ist die Ausgabe wirklich nützlich. Sie erfasst Paketnamen, Versionen, Abhängigkeitsbeziehungen, Lizenzkennungen, Prüfsummen und die installierten Targets, die an Ihre install- und export-Sets gebunden sind. Der Vorgang ist schnell. Er liest CMakes eigenen Target-Graphen und erzeugt ein sauberes, standardbasiertes SPDX-Dokument ohne zusätzliches Werkzeug. Für eine Anwendung, die vollständig über sauber deklarierte CMake-Targets gebaut wird, deckt das schon am ersten Tag viel ab.
Wo es noch endet
Zwei Grenzen sind wichtig, und diese klar zu benennen ist der Sinn dieses Beitrags.
Erstens beschreibt das Werkzeug, was CMake kennt. Das Dokument entsteht aus Ihren install- und export-Deklarationen sowie dem Graphen, den CMake auflöst. Komponenten, die nicht als CMake-Targets modelliert sind, fallen daher heraus: von Hand eingebundener Quellcode (vendored source) im Baum, vorkompilierte statische Archive, die in den Build geholt werden, und Silicon-Vendor-SDKs, die als undurchsichtige Bibliotheken ausgeliefert werden. In Embedded-Firmware leben dort oft die interessanten Abhängigkeiten, dieselbe Lücke, die SBOMs für C/C++ so schwierig macht.
Zweitens ist die Funktion früh dran. Auf dem aktuellen experimentellen Release berichtete ein Entwickler mit CMake 4.3.2 im CMake-Discourse, dass eine statisch gelinkte Abhängigkeit, die über FetchContent eingebundene Bibliothek fmt, in der SPDX-Ausgabe als shared-Beziehung statt als statisch gelinkt auftauchte. Genau diese Unterscheidung zwischen statisch und shared ist es, worauf sich Schwachstellen-Triage und Compliance-Prüfung stützen. Prüfen Sie die Ausgabe daher gegen das, was tatsächlich in Ihr Binary gelinkt wurde, bevor Sie sich darauf verlassen. Das ist eine raue Kante einer experimentellen Funktion, die sich wahrscheinlich verbessern wird, heute aber real ist.
Eines ist keine Einschränkung, sondern nur eine Abgrenzung des Umfangs: Die SBOM führt keine Schwachstellenanalyse durch. Sie liefert strukturierte Daten, die nachgelagerte Werkzeuge auswerten, was die korrekte Arbeitsteilung ist.
Wann die native CMake-SBOM genügt und wann nicht
Für eine reine CMake-Anwendung, deren Abhängigkeiten alle als installierte oder exportierte Targets deklariert sind, ist die native SBOM-Generierung ein schneller, standardbasierter Ausgangspunkt, und Sie sollten sie aktivieren. Embedded- und Firmware-Arbeit braucht einen Partner. Die realen Abhängigkeiten umfassen dort oft vendored source, statische Archive und Vendor-SDKs, die nie als saubere CMake-Targets auftauchen, und Prüfer brauchen die Unterscheidungen statisch-vs-shared und ausgeliefert-vs-vorhanden korrekt. Der Build-Graph allein sieht für diese Fälle nicht genug, und genau dort verdient sich ein build-bewusster Generator seinen Platz.
Wie Interlynk hier passt
Interlynks Generator lynkctl deckt diesen zweiten Fall ab. Er läuft nach Ihrem bestehenden Build, ohne erneuten Build, und liest die tatsächlichen Compiler- und Linker-Aufrufe, die Ihr Build erzeugt. So erfasst er den eingebundenen Code, statische Archive und Silicon-Vendor-SDKs, die eine rein graphbasierte Sicht auslässt, und er hält Nachweise je Komponente fest, bis hin zur Quelldatei, der Compile-Zeile und einer Konfidenzstufe. Die beiden Ansätze lassen sich sauber schichten: Beginnen Sie mit der nativen CMake-SBOM für das, was CMake deklariert, und ergänzen Sie die build-bewusste Generierung für die darunterliegenden Firmware-Schichten. Sehen Sie sich den C/C++ SBOM-Generator für eingebettete Software an, und das ganze Feld in unserem Leitfaden zu den besten SBOM-Tools.
Häufige Fragen
Kann CMake jetzt ohne zusätzliche Werkzeuge eine SBOM erzeugen?
Ja. Über eine in einem 2026-Release ergänzte experimentelle Funktion gibt CMake eine SPDX-3.0.1-SBOM aus seinem eigenen Build-Graphen aus, sobald Sie das Feature-Gate aktivieren und die Befehle install(SBOM) oder export(SBOM) hinzufügen. Bestätigen Sie die aktuellen Flags und die CMake-Version in der offiziellen Dokumentation, da die Funktion experimentell ist.
Welches SBOM-Format erzeugt CMake?
SPDX 3.0.1 in JSON-LD-Form, erstellt aus den Targets und Abhängigkeiten, die CMake während Konfiguration und Installation auflöst.
Erfasst die native CMake-SBOM statisch gelinkte und eingebundene Abhängigkeiten?
Sie erfasst das, was Ihr Projekt als installierte oder exportierte CMake-Targets modelliert. Von Hand eingebundener Quellcode, vorkompilierte statische Archive und Vendor-SDKs, die nicht als Targets deklariert sind, können herausfallen, und auf dem aktuellen experimentellen Release wurde die statisch-vs-shared-Kennzeichnung einer gelinkten Abhängigkeit als unzuverlässig gemeldet. Prüfen Sie die Ausgabe gegen das, was tatsächlich in Ihr Binary gelinkt wurde.
Sollte ich weiterhin einen dedizierten SBOM-Generator einsetzen?
Für eine reine CMake-Anwendung kann die native Generierung genügen. Für Embedded- oder regulierte Firmware kombinieren Sie sie mit einem build-bewussten Generator, der die echten Compiler- und Linker-Aufrufe liest, damit vendored source, statische Archive und Vendor-SDKs mit Nachweisen erfasst werden. Siehe die vier Wege, ein SBOM aus einem CMake-Build zu erzeugen.
Wie es weitergeht
Den vollständigen Vergleich von nativer CMake-SBOM, Open-Source-Modulen, Binäranalyse und build-bewusster Generierung finden Sie unter vier Wege, ein SBOM aus einem CMake-Build zu erzeugen. Zum breiteren Feld siehe unseren Leitfaden zu den besten SBOM-Tools.