# The C conundrum - generating SBOMs when there's no lockfile

> Exploring the challenge of generating SBOMs for C/C++ projects without native package managers, reviewing cmake-sbom, Conan, cve-bin-tool, and CISA working group efforts.

- **Author:** Chris Swan
- **Published:** 2024-11-18
- **Categories:** Guide
- **Tags:** Sbom, Cpp, Tutorial
- **Updated:** 2026-04-12

Generating an SBOM for something created in a modern language like Dart, Go,
Python or Rust is pretty easy. Dependencies are declared using the language's
package manager, the package manager creates a .lock file, and then an SBOM
can be generated from the .lock file. Under the hood sbomify uses
[Trivy](https://trivy.dev/) to do that, and other tools like
[Syft](https://github.com/anchore/syft) do the same. (Note: we [no longer consider Trivy safe](https://sbomify.com/2026/03/26/trivy-compromise-hardening-sbomify-action/) following its March 2026 compromise and have removed it from sbomify-action.)

There's no package manager for C though, at least not a universally used one.

That's a huge problem, because apps developed using modern languages where
it's easy to create SBOMs are the very tip of an iceberg where stuff developed
in C is both the rest of the visible iceberg and everything beneath the
surface - the apps we know are written in C, and the numerous libraries etc.
that they're built on top of.

How are people going to comply with Executive Order 14028 (in the US) and
the forthcoming Cyber Resilience Act (CRA) in the EU if they're dealing with
that iceberg of C?

Where there are package managers we can reasonably expect their maintainers
to start churning out SBOMs. [The Yocto Project](https://www.yoctoproject.org/),
which builds embedded Linux distributions, has taken an early lead with their
machinery for
[Creating a Software Bill of Materials](https://docs.yoctoproject.org/dev/dev-manual/sbom.html).
It's also reasonable to expect that major distributions like Debian and Red Hat
will follow suit. They do after all have all the metadata that's needed, and
they've already spent years on careful curation.

But what about all the apps that aren't in major distro package managers?
There are a few pieces to the puzzle out there, but not yet a complete
solution.

- [cmake-sbom](https://github.com/DEMCON/cmake-sbom) can add the SBOM creation
  process to CMake (a popular tool for building C projects), but a lot of the
  data entry (and subsequent maintenance) is manual. This perhaps provides the
  boilerplate for NTIA compliance, but doesn't really help with upstream
  dependencies.
- [Zephyr](https://www.zephyrproject.org/) has the ability to generate SPDX
  for the embedded systems it creates, based on earlier work in
[cmake-spdx](https://github.com/swinslow/cmake-spdx). But that hasn't
  yet been cycled back into a generic tool that could be used by other
  CMake based projects.
- [Conan](https://conan.io/) is a package manager for C/C++, with many popular
  dependencies already present there. That opens the door to generating SBOMs
  from `conan.lock` files, but right now the resulting files (at least those
  generated by Syft) are of very poor quality, with incomplete CFEs.
- [cve-bin-tool](https://github.com/intel/cve-bin-tool) can generate an SBOM
  from the libraries it finds in a binary, but:
  - Only a limited subset of libraries are discoverable to the tool.
  - When generating SBOMs from test binaries they were of poor quality.
  - cve-bin-tool flags binaries and the libraries they contain as being
    vulnerable even when they've been patched to fix the relevant CVE, implying
    a naive matching mechanism.
- [it-depends](https://github.com/trailofbits/it-depends) finds nothing
  (and it seems it's a
[known issue](https://github.com/trailofbits/it-depends/issues/66)
  despite the README saying it supports CMake projects).

Thankfully efforts are underway to resolve these problems. C (and C++) is
lined up for
[Phase 3](https://github.com/CISA-SBOM-Community/SBOM-Generation?tab=readme-ov-file#phase-3)
of the SBOM Generation Reference Implementations within the CISA SBOM
Community; and the working group had a call in the past week to look at
what's already working and where effort can most effectively be applied
to provide tools for a broader range of projects.

This is a guest post from [Chris Swan](https://cpswan.net), an Engineer at
[Atsign](https://atsign.com) who are an early adopter of sbomify.

---

From sbomify: https://sbomify.com/2024/11/18/c-conundrum/