CMake Can Generate SBOMs Natively Now: What It Captures and What It Misses
| Interlynk
CMake added experimental native SBOM generation in a 2026 release (SPDX 3.0.1, DARPA-funded). Here is how to turn it on, exactly what it records, and where it still needs a build-aware layer for embedded firmware.
The news: CMake now ships an SBOM generator
CMake added experimental support for generating a Software Bill of Materials directly from the build. Kitware announced the release on 21 September 2026. The work was performed with Riverside Research under DARPA Contract HR001124C0489, and the examples target CMake 4.3. For a build system running millions of C and C++ projects, producing a basic SBOM is becoming a native switch inside the existing build process, instead of a separate scanning tool bolted on afterward.
This post covers what the feature does today, how to enable it, what it records well, and where it still stops. For the wider picture of every option, see our comparison of the four ways to generate an SBOM from a CMake build.
What it is and how to turn it on
The feature is gated behind an experimental flag to prevent accidental activation. You set CMAKE_EXPERIMENTAL_GENERATE_SBOM to the specific UUID that matches your CMake version. You select the output format with CMAKE_INSTALL_SBOM_FORMATS=SPDX, and then declare generation in your project with the new install(SBOM) and export(SBOM) commands. CMake builds the document from the same dependency graph it uses to compile and link, and writes the output as SPDX 3.0.1 JSON-LD.
Because the feature is experimental, the flag, the command surface, and the supported CMake version remain in motion. Check the official CMake documentation for the current UUID and syntax before wiring it into a pipeline.
What it captures well
For a project that installs and exports its targets through CMake, the output is genuinely useful. It records package names, versions, dependency relationships, license identifiers, checksums, and the installed targets tied to your install and export sets. The process is fast. It reads CMake's own target graph and produces a clean, standards-based SPDX document with no extra tooling in the loop. For an application built entirely through well-declared CMake targets, that covers a lot of ground on day one.
Where it still stops
Two limits matter, and being clear about them is the point of this post.
The tool describes what CMake knows about. The document is built from your install and export declarations alongside the graph CMake resolves, so components that are not modeled as CMake targets fall outside it: hand-vendored source in the tree, prebuilt static archives fetched into the build, and silicon-vendor SDKs that ship as opaque libraries. In embedded firmware, that is often where the interesting dependencies live, which is the same gap that makes C/C++ SBOMs hard in the first place.
The feature is early. On the current experimental release, a developer testing CMake 4.3.2 reported on the CMake Discourse that a statically linked dependency, the
fmtlibrary pulled in throughFetchContent, showed up in the SPDX output marked as a shared relationship rather than statically linked. That static-versus-shared distinction is exactly what a vulnerability triage or a compliance reviewer leans on, so verify the output against what actually linked into your binary before relying on it. This is a rough edge of an experimental feature, and it will likely improve, but it is real today.
One thing that is not a limitation, just a scope boundary: the SBOM does not perform vulnerability analysis. It produces structured data for downstream tools to evaluate, which is the correct division of labor.
When native CMake SBOM is enough, and when it falls short
For a pure CMake application whose dependencies are all declared as installed or exported targets, native SBOM generation is a fast, standards-based starting point, and you should turn it on. Embedded and firmware work needs a partner. Real dependencies there often include vendored source, static archives, and vendor SDKs that never appear as clean CMake targets, and auditors need the static-versus-shared and shipped-versus-present distinctions to be right. The build graph alone does not see enough for those cases, and that is where a build-aware generator earns its place.
How Interlynk fits
Interlynk's generator, lynkctl, handles that second case. It runs after your existing build with no rebuild, and reads the actual compiler and linker invocations your build emits, so it captures the vendored code, static archives, and silicon-vendor SDKs that a graph-only view leaves out, and it records per-component evidence, down to the source file, the compile line, and a confidence tier. The two approaches layer cleanly: start with native CMake SBOM for what CMake declares, and add build-aware generation for the firmware layers underneath. See the C/C++ SBOM generator for embedded software, and the full field in our guide to the best SBOM tools.
Frequently asked questions
Can CMake generate an SBOM without extra tools now?
Yes. Through an experimental feature added in a 2026 release of CMake, it emits an SPDX 3.0.1 SBOM from its own build graph once you enable the feature gate and add the install(SBOM) or export(SBOM) commands. Confirm the current flags and CMake version in the official documentation, since the feature is experimental.
What SBOM format does CMake produce?
SPDX 3.0.1 in JSON-LD form, built from the targets and dependencies CMake resolves during configure and install.
Does native CMake SBOM capture statically linked and vendored dependencies?
It captures what your project models as installed or exported CMake targets. Hand-vendored source, prebuilt static archives, and vendor SDKs that are not declared as targets can fall outside it, and on the current experimental release the static-versus-shared labeling of a linked dependency has been reported as unreliable. Verify the output against what actually linked into your binary.
Should I still use a dedicated SBOM generator?
For a pure CMake application, native generation may be enough. For embedded or regulated firmware, pair it with a build-aware generator that reads the real compiler and linker invocations, so vendored code, static archives, and vendor SDKs are captured with evidence. See the four ways to generate an SBOM from a CMake build.
Where to go next
For the full comparison of native CMake SBOM, open-source modules, binary analysis, and build-aware generation, read four ways to generate an SBOM from a CMake build. For the wider category, see our guide to the best SBOM tools.