CMake kan nu native SBOM's genereren: wat het vastlegt en wat het mist.
| Interlynk
CMake voegde in een release uit 2026 experimentele native SBOM-generatie toe (SPDX 3.0.1, DARPA-gefinancierd). Hoe je het inschakelt, wat het precies vastlegt, en waar je voor embedded firmware nog een build-bewuste laag nodig hebt.
Het nieuws: CMake levert nu een SBOM-generator mee
CMake heeft experimentele ondersteuning toegevoegd om een Software Bill of Materials rechtstreeks uit de build te genereren. Kitware kondigde de release aan op 21 september 2026. Het werk is samen met Riverside Research uitgevoerd onder DARPA-contract HR001124C0489, en de voorbeelden richten zich op CMake 4.3. Voor een build-systeem dat miljoenen C- en C++-projecten aandrijft, wordt het genereren van een basis-SBOM een native schakelaar binnen het bestaande build-proces, in plaats van een aparte scantool die je er achteraf op zet.
Deze post behandelt wat de functie vandaag doet, hoe je die inschakelt, wat ze goed vastlegt en waar ze nog ophoudt. Voor het bredere beeld van alle opties, zie onze vergelijking van de vier manieren om een SBOM uit een CMake-build te halen.
Wat het is en hoe je het inschakelt
De functie zit achter een experimentele vlag om onbedoelde activering te voorkomen. Je zet CMAKE_EXPERIMENTAL_GENERATE_SBOM op de UUID die bij jouw CMake-versie hoort. Het uitvoerformaat kies je met CMAKE_INSTALL_SBOM_FORMATS=SPDX, en vervolgens declareer je de generatie in je project met de nieuwe commando's install(SBOM) en export(SBOM). CMake bouwt het document op uit dezelfde afhankelijkheidsgraaf die het gebruikt om te compileren en te linken, en schrijft de uitvoer weg als SPDX 3.0.1 JSON-LD.
Omdat de functie experimenteel is, zijn de vlag, het commando-oppervlak en de ondersteunde CMake-versie nog in beweging. Raadpleeg de officiële CMake-documentatie voor de actuele UUID en syntaxis voordat je het in een pipeline opneemt.
Wat het goed vastlegt
Voor een project dat zijn targets via CMake installeert en exporteert, is de uitvoer echt nuttig. Het legt pakketnamen, versies, afhankelijkheidsrelaties, licentie-identifiers, checksums en de geïnstalleerde targets vast die aan je install- en export-sets zijn gekoppeld. Het proces is snel. Het leest CMakes eigen target-graaf en levert een schoon, standaardgebaseerd SPDX-document zonder extra tooling. Voor een applicatie die volledig via netjes gedeclareerde CMake-targets wordt gebouwd, dekt dat op dag één al veel.
Waar het nog ophoudt
Twee grenzen doen ertoe, en die helder benoemen is het doel van deze post.
Ten eerste beschrijft het hulpmiddel wat CMake kent. Het document wordt opgebouwd uit je install- en export-declaraties plus de graaf die CMake oplost, dus componenten die niet als CMake-targets zijn gemodelleerd, vallen erbuiten: handmatig meegeleverde broncode (vendored source) in de boom, voorgecompileerde statische archieven die in de build worden gehaald, en silicon-vendor-SDK's die als ondoorzichtige bibliotheken worden geleverd. In embedded firmware wonen daar vaak de interessante afhankelijkheden, precies de leemte die SBOM's voor C/C++ lastig maakt.
Ten tweede is de functie pril. Op de huidige experimentele release meldde een ontwikkelaar met CMake 4.3.2 op de CMake Discourse dat een statisch gelinkte afhankelijkheid, de via FetchContent binnengehaalde fmt-bibliotheek, in de SPDX-uitvoer verscheen als een shared-relatie in plaats van statisch gelinkt. Juist dat onderscheid tussen statisch en shared is waar kwetsbaarheidstriage en compliancebeoordeling op leunen, dus controleer de uitvoer tegen wat er werkelijk in je binary is gelinkt voordat je erop vertrouwt. Dit is een ruwe rand van een experimentele functie, die waarschijnlijk zal verbeteren, maar vandaag reëel is.
Eén ding is geen beperking maar een afbakening van de reikwijdte: de SBOM voert geen kwetsbaarheidsanalyse uit. Ze levert gestructureerde data die nagelegen tools evalueren, wat de juiste taakverdeling is.
Wanneer native CMake-SBOM genoeg is en wanneer niet
Voor een zuivere CMake-applicatie waarvan alle afhankelijkheden als geïnstalleerde of geëxporteerde targets zijn gedeclareerd, is native SBOM-generatie een snel, standaardgebaseerd startpunt, en je zou het moeten inschakelen. Embedded- en firmwarewerk heeft een partner nodig. De echte afhankelijkheden omvatten daar vaak vendored source, statische archieven en vendor-SDK's die nooit als schone CMake-targets verschijnen, en auditors hebben de onderscheiden statisch-vs-shared en geleverd-vs-aanwezig correct nodig. De build-graaf alleen ziet voor die gevallen niet genoeg, en daar verdient een build-bewuste generator zijn plek.
Hoe Interlynk hierin past
Interlynks generator lynkctl dekt dat tweede geval. Hij draait na je bestaande build, zonder opnieuw te bouwen, en leest de werkelijke compiler- en linker-aanroepen die je build voortbrengt. Zo legt hij de meegeleverde code, statische archieven en silicon-vendor-SDK's vast die een louter graafgebaseerde blik weglaat, en hij legt bewijs per component vast, tot aan het bronbestand, de compile-regel en een betrouwbaarheidsniveau. De twee aanpakken stapelen netjes: begin met native CMake-SBOM voor wat CMake declareert, en voeg build-bewuste generatie toe voor de firmwarelagen eronder. Bekijk de C/C++ SBOM-generator voor embedded software, en het volledige veld in onze gids over de beste SBOM-tools.
Veelgestelde vragen
Kan CMake nu zonder extra tools een SBOM genereren?
Ja. Via een in een release uit 2026 toegevoegde experimentele functie geeft CMake een SPDX-3.0.1-SBOM uit zijn eigen build-graaf uit zodra je de feature-gate inschakelt en de commando's install(SBOM) of export(SBOM) toevoegt. Bevestig de actuele vlaggen en de CMake-versie in de officiële documentatie, aangezien de functie experimenteel is.
Welk SBOM-formaat produceert CMake?
SPDX 3.0.1 in JSON-LD-vorm, opgebouwd uit de targets en afhankelijkheden die CMake tijdens configuratie en installatie oplost.
Legt native CMake-SBOM statisch gelinkte en meegeleverde afhankelijkheden vast?
Het legt vast wat je project modelleert als geïnstalleerde of geëxporteerde CMake-targets. Handmatig meegeleverde broncode, voorgecompileerde statische archieven en vendor-SDK's die niet als targets zijn gedeclareerd, kunnen erbuiten vallen, en op de huidige experimentele release is de statisch-vs-shared-labeling van een gelinkte afhankelijkheid als onbetrouwbaar gemeld. Controleer de uitvoer tegen wat er werkelijk in je binary is gelinkt.
Moet ik nog steeds een specifieke SBOM-generator gebruiken?
Voor een zuivere CMake-applicatie kan native generatie volstaan. Voor embedded of gereguleerde firmware combineer je die met een build-bewuste generator die de echte compiler- en linker-aanroepen leest, zodat vendored source, statische archieven en vendor-SDK's met bewijs worden vastgelegd. Zie de vier manieren om een SBOM uit een CMake-build te halen.
Verder lezen
Voor de volledige vergelijking van native CMake-SBOM, open-source-modules, binaire analyse en build-bewuste generatie, lees vier manieren om een SBOM uit een CMake-build te halen. Voor het bredere veld, zie onze gids over de beste SBOM-tools.