CMake can now generate SBOMs. What does that mean for medical device manufacturers?

Kitware has added experimental SBOM generation to CMake. If you build embedded medical device software in C or C++, the build system you probably already use can now describe what goes into your firmware, in SPDX format.

What's changed

In recent CMake releases (Kitware's examples target CMake 4.3), you turn on an experimental flag and two new commands, `install(SBOM)` and `export(SBOM)`, become available. They produce an SPDX 3.0.1 JSON-LD document listing packages, versions, dependency relationships, licence identifiers and checksums. The data comes from what CMake already knows, such as `find_package()` results and linked targets.

Why it matters

In the US, under Section 524B of the FD&C Act, a premarket submission for a cyber device must include an SBOM. C and C++ firmware has always been the awkward case. There's no package manager, libraries get copied into the source tree, and RTOSes and vendor SDKs come in through the build. Most SBOM tools were designed for npm, Maven or pip, so they see very little of this.

The build system is the right place to generate an SBOM because it knows what actually ends up in the shipped image, not just what's in the repository.

Embedded ecosystems got there first

Zephyr RTOS added SBOM support through its `west` meta-tool some time ago. `west spdx` uses CMake's file-based API to produce separate SPDX documents for the application, the Zephyr sources, the build outputs and module dependencies. It defaults to SPDX 2.3 and also supports 3.0. Nordic Semiconductor's nRF Connect SDK is built on Zephyr, so it uses the same `west` workflow and adds its own `ncs-sbom` command for licence reporting.

Native CMake support implies teams that aren't on Zephyr can get similar capability without building their own tooling.

What to watch

• It's experimental. The flag needed to enable it changes between CMake releases, so don't build a release process around it yet.
• It only outputs SPDX 3.0.1. Check that your downstream SBOM tools can read it.
• It only knows what CMake knows. Code copied into the source tree without proper targets, prebuilt binaries and toolchain runtime libraries may be missing, or appear without versions or supplier details.
• Some areas are still in progress. Kitware lists transitive dependencies and licence reporting as work in progress. Transitive dependencies are an important limitation to note as they are required by the FDA.

An SBOM is the start, not the submission

Kitware says it plainly: SBOMs don't perform vulnerability analysis themselves. FDA expects more than a list of components. It wants to know each component's support level and end-of-support date, how you've assessed known vulnerabilities, and how you'll keep monitoring them after the device is on the market.

That's where Threat Detective comes in. Bring your SBOMs from CMake, Zephyr, or any other tool, and we'll help you turn them into the evidence regulators expect.