CMake SBOM Generation: Native, Manual, and Build-Aware Approaches
| Interlynk
How to generate an SBOM from a CMake build in 2026 - CMake's new native SBOM support, open-source modules, binary analysis, and build-aware generation compared, with what each one captures and misses.
Four ways to get an SBOM from a CMake build
There are four ways to get a Software Bill of Materials (SBOM) out of a CMake project, and each reads a different part of your build. CMake now offers native experimental SBOM generation directly from its build graph. You can also bolt on open-source modules, run binary analysis on the final image, or use build-aware generation that reads the actual compiler and linker invocations your build emits, after it runs.
This guide outlines what each approach sees and where it stops. For embedded systems and firmware, critical components often sit inside the blind spots of standard build-graph tools.
In short: CMake can generate an SBOM natively from its build graph, making it the fastest start for projects built entirely inside CMake. However, the build graph misses vendored source files, prebuilt static libraries, and vendor SDKs. Open-source modules share those limits. Binary analysis inspects the final output but relies on inferred identities. Build-aware generation reads the real build's compiler and linker calls after it runs, with no rebuild, and keeps per-component evidence. Choose the approach that covers every layer of your shipped binary.
What CMake's native SBOM does
CMake includes experimental SBOM generation that builds documents directly from its compilation and linking dependency graph. Enabling it at configure time outputs SPDX documents for targets resolved by CMake. Because it reads internal target structures rather than scanning raw files, it runs quickly and categorizes first-party targets alongside CMake-resolved dependencies cleanly.
Native CMake SBOM support is experimental and evolving. Check the official CMake documentation to confirm active flag names and version compatibility before production use.
For a closer look at the feature itself, see CMake's native SBOM feature.
The four approaches, compared
Here is what each method inspects, where it succeeds, and where it falls short.
Approach | What it reads | Captures well | Misses | Best when |
|---|---|---|---|---|
Native CMake SBOM (experimental) | CMake build graph | First-party targets and CMake-resolved dependencies. Fast, zero external tools | Vendored source files without targets, prebuilt static libraries, vendor SDKs | Your project builds entirely through CMake targets and needs a quick, standard start |
Open-source CMake modules (e.g., community | CMake project files via added scripts | Custom output formats tailored to existing CMake workflows | Same build-graph boundaries; requires manual maintenance | You need full script control and want to manage the integration yourself |
Binary / firmware analysis | Compiled binaries and firmware images | Components physically present inside shipped binaries | Exact component versions and source provenance; identity is inferred and noisy on stripped builds | You only have access to compiled binaries, or need to verify final images |
Build-aware generation ( | The compiler and linker invocations your build emits, plus the artifact (post-build, no rebuild) | Vendored source, static archives, and vendor SDKs with source-level evidence | Requires commercial tooling (free tier available) | You ship regulated or embedded firmware needing audit-ready evidence |
These methods complement one another. Engineering teams often start with native CMake output and add build-aware generation when third-party SDKs and static libraries enter the picture.
Where each approach stops
Embedded builds consist of multiple layers, and deeper layers often sit outside CMake's build graph:
Package manager manifests (Conan, vcpkg): Visible to all four approaches.
CMake build targets: Native CMake and open-source CMake modules reach here.
Vendored source code: Build-aware generation captures this layer; graph-based methods miss it.
Prebuilt static archives (
.a/.lib): Build-aware tools record these directly; binary analysis infers their identity.Silicon vendor SDKs (ST, NXP, TI, Renesas): Build-aware tools track modified SDK sources; other methods miss them.
Final firmware image: Binary analysis reads the compiled bytes; build-aware tools map those bytes back to source code.
The deeper a layer sits, the less visible it is to the CMake graph. Read our breakdown of why C/C++ SBOMs are hard to explore these visibility gaps in detail.
A worked example
We processed a real Trusted Firmware-M build on an STM32H5 MCU through CMake to generate an SBOM, documenting what each layer surfaced. Read the step-by-step walk-through in Trusted Firmware-M on an STM32H5.
When to use which
Pure CMake applications: Use native CMake SBOM generation. It covers what you compile and requires minimal setup.
Firmware with vendored SDKs or static libraries: Use build-aware generation. Vulnerability tracking requires visibility into components living below the CMake target graph.
Shipped binaries without build access: Use binary analysis to discover components inside the compiled image, treating version numbers as inferred until you run a build-aware pass.
How Interlynk fits
Interlynk's generator, lynkctl, uses build-aware generation. It runs after your existing Make, CMake, IAR, or TI Code Composer build, with no rebuild, and reads the actual compiler and linker invocations, so it catches the vendored code, static archives, and silicon SDKs that graph-only tools miss. It records component-level evidence, down to the source file, the compile line, and a confidence tier, so security reviewers can verify why each entry appears in the manifest. It runs in air-gapped environments and outputs CycloneDX 1.6+ and SPDX 3.0+ formats. Explore the C/C++ SBOM generator for embedded software. For teams exporting to regulated markets, lynkctl maps directly to FDA 524B and the EU Cyber Resilience Act.
Frequently asked questions
Can CMake generate an SBOM by itself?
Yes. Using recent experimental features, CMake emits SPDX SBOMs directly from its build graph during configuration and installation. It covers internal targets and CMake-resolved dependencies, so verify that it records your vendored code and static libraries before using it for compliance.
What does CMake's native SBOM miss?
It misses components outside the target build graph, including source code copied straight into the tree, prebuilt static libraries, and silicon vendor SDKs. Because embedded firmware relies heavily on these assets, teams regularly pair CMake with build-aware tools.
Should I choose CycloneDX or SPDX for a CMake project?
Both formats work across these workflows. CMake generates SPDX natively, while lynkctl outputs both CycloneDX 1.6+ and SPDX 3.0+. Select the format required by your downstream scanners or regulatory authorities.
How do I generate an SBOM for firmware built with IAR or TI toolchains?
A build-aware generator reads the compiler and linker invocations from IAR Embedded Workbench and TI Code Composer builds after they run, without requiring CMake. Learn more about the C/C++ SBOM generator for embedded software.
Are there free options available?
Native CMake SBOM features and community CMake modules are free to use. Interlynk also provides a free tier. Start with the free approach that fits your build environment, then add build-aware generation when you need to audit third-party SDKs and static libraries.
Where to go next
For an overview of the broader ecosystem, read our guide to the best SBOM tools.