How do you generate an SBOM for a C or C++ project?

C and C++ have no universal package manager, so an SBOM is only as good as your dependency records. If you use Conan, a CycloneDX generator can read the dependency graph. If you vendor sources or use system libraries, you need manual or build-level records for each component.

Why is C and C++ harder?

A Node or Java build resolves packages from a registry with names and versions. A C or C++ build may pull a library from the operating system, copy source into a third_party folder, fetch it with a script, or use a package manager such as Conan. Only the last gives a machine-readable graph. Everything else depends on discipline.

What does Conan give you?

The CycloneDX project maintained a Conan tool that creates CycloneDX SBOMs for C and C++ projects. The repository is now archived. Its README says support for Conan 2 and later is available as an official Conan 2 extension, through the SBOM commands in the conan-extensions project, and the archived tool covers Conan v1. According to the README, the BOM contains an aggregate of the current project's dependencies, including a full dependency graph. The older tool installs from PyPI, takes a path to a conanfile, and has options to write to a file or to standard output, to exclude development dependencies, and to pass the profile, settings and options that match your real build.

That last point matters. The dependency graph in Conan depends on profile and settings, so generate the SBOM with the same ones as your release build. An SBOM made from a default profile may describe a different set of libraries than the one you ship.

What if you do not use Conan?

You have three realistic options.

1. Declare dependencies in the build. CMake, Meson or Bazel files that fetch dependencies by pinned version or hash can be the source of truth. Export that list to a CycloneDX or SPDX file in a script.
2. Record vendored code by hand. For each copied library, note its name, version, upstream URL, license and the commit or tarball hash. Keep it in a file under version control next to the code.
3. Scan the binary or source tree. Tools that identify components from file contents can find some libraries, but treat the output as a lead to confirm, not a final list.

Constructed example: a firmware project vendors zlib and a TLS library as source folders, and links a system libc. The Conan graph shows two packages, but the SBOM must also list the TLS library's exact commit and the libc version from the build image. If either is missing, a vulnerability notice about that TLS library cannot be matched to your product.

What does the SBOM not capture?

Compiler and linker versions, static linking details, patches applied locally to a vendored library and optional features compiled out. Add a note or properties for locally patched code, because a patched copy of version 1.2.3 may not match the upstream advisory.

How to check or apply this

1. Decide how each dependency enters the build: package manager, vendored source, or system library.
2. If you use Conan 2, run the SBOM command from the Conan extensions with the same profile as your release.
3. For vendored code, keep a manifest with version, source and hash, and generate the SBOM from it.
4. Add system libraries and the toolchain from the build image record.
5. Review the output against the final binary's linked libraries.
6. Attach the SBOM to each release and regenerate when dependencies change.
7. Scan it for known vulnerabilities and track reachable ones first.

Safeguard can scan SBOMs and dependencies and report which vulnerable components are reachable. The CLI also generates SBOMs for many package managers. See /demos/sca-dependency-inventory.

Quick check

Sources

• CycloneDX cyclonedx-conan repository README

Last reviewed: 18 October 2026.