SBOMs (software bill of materials) have taken on critical importance in enabling compliance with regulatory requirements, supporting software supply chain security activities, fulfilling customer requests, and more.
However, while the SBOM tooling ecosystem has evolved significantly over the past few years, significant challenges remain with unmanaged languages like C/C++.
That’s because C/C++ lacks centralized registries and consistent manifests; this is in contrast to ecosystems like npm or PyPI. In C/C++, dependencies get vendored into source trees, code gets copy-pasted between projects, and there's no single package manager (Conan, vcpkg, CMake FetchContent, Yocto, or just a checked-in tarball).
As a result, a C/C++ SBOM built from manifest-parsing alone will likely be very incomplete and/or inaccurate, which will create significant problems regardless of your particular SBOM use case.
However, there are strategies and tools that can help bridge this gap. In this blog, we’ll take a close look at generating and managing SBOMs across the C/C++ ecosystem, starting with vendored components.
SBOMs for Vendored C/C++ Dependencies
Vendoring (copying a dependency's source directly into your repo) is common in C/C++, but vendored code has no manifest file. Since most SBOM tools rely on manifest files to surface a dependency inventory (and can’t detect vulnerabilities in ecosystems without them), this creates the risk of incomplete and/or inaccurate output.
Strategies for Including Vendored C/C++ in SBOMs
There is a mix of process- and tooling-based approaches to ensuring your SBOMs include vendored components.
- Tools: Although many of today’s commonly used SBOM tools struggle with C/C++, there are several strong options with support for vendored components. This includes FOSSA, which recently added dedicated coverage for vendored dependencies.
- Process: If you don’t have a tool that can support vendored component detection, you may need to rely on manual tracking for SBOM creation. In this scenario, require documentation when new code is vendored, and audit the existing backlog once. Also consider flagging likely vendored code via paths (
third_party/,vendor/), README files, or version strings.
Ingesting SBOMs with Vendored Components
If you receive a supplier's SBOM, a "clean" manifest-only file may still be missing exactly the vendored components most likely to carry vulnerabilities. Ask suppliers how vendored code was accounted for, or run your own scan as a cross-check.
SBOMs for C/C++ Code Snippets
The first question to consider when discussing C/C++ code snippets in the SBOM context is whether snippets should even be included in your SBOM in the first place.
The answer will vary depending on your organization’s SBOM use case (and any regulatory requirements that influence it), but one approach is as follows:
- SBOMs for license compliance: Include snippets since copying even a small block under a copyleft license can create real obligations.
- SBOMs for vulnerability management: It depends on materiality (a copied crypto or parsing routine matters more than a generic algorithm), but, generally speaking, snippets don’t present the same level of security risk as full files/dependencies.
- Customer-facing SBOM: Use snippet detection internally to catch risk, remediate, and represent confirmed origins at the component level.
Should you decide to include C/C++ snippets in some or all of your SBOMs, it’s worth exploring a solution (like FOSSA) that combines both a snippet scanning tool and SBOM management workflows.
Additionally, note that while SPDX does have dedicated, highly structured support for code snippets, CycloneDX does not. (Although, it is possible to include snippets in CycloneDX SBOMs. This can be doing with a combination of the file component plus evidence or pedigree fields. Some organizations may prefer to simply include the snippet as the file component type, which is possible in both CycloneDX and SPDX.)
Note: Although both vendored components and snippets follow a similar copy-and-paste workflow, we draw a distinction between full files (vendored components) and small parts of files (snippets).
SBOMs for Conan
Although C/C++ doesn’t have a centralized package manager, Conan is comparatively SBOM-friendly since it has an actual dependency graph. There are also a number of tools available to produce SBOMs with Conan-managed dependencies. Here’s how to use Conan’s out-of-the-box functionality to create your SBOM.
- Conan has a built-in tool for generating SBOMs in CycloneDX. It can be found in the
conan.tools.sbommodule. - To use this feature, you’ll need to implement a hook in your client. (See Conan’s documentation for more information on hooks.)
- From there, the next step is determined by when you want to produce your SBOM (e.g. when you create your app or when Conan dependencies are installed). We recommend viewing Conan’s full SBOM documentation for step-by-step instructions.
It’s important to remember that Conan's graph only covers Conan-managed dependencies, so you’ll want to combine it with vendoring and snippet detection for full coverage if necessary.
SBOMs for Yocto
Yocto builds entire embedded Linux distributions, often from hundreds of recipes. This makes SBOMs both harder and, in some cases, even more important than in other parts of the C/C++ ecosystem. (Many embedded/IoT devices are squarely in Cyber Resilience Act scope.)
Here’s how you can generate an SBOM that represents a Yocto image with the Yocto Project’s native functionality.
Once licenses are identified (and vulnerabilities are fixed), Yocto can generate an SBOM for your Yocto project via the OpenEmbedded build system. The SBOM, which is output in the SPDX format, will be available as an IMAGE-MACHINE.spdx.json file in the Build Directory
Users also have the option to customize Yocto-produced SBOMs by enabling the create-spdx class. This provides the ability to include VEX information, PURLs, and more.
How FOSSA Helps with C/C++ SBOMs
Although there are numerous tools that can support SBOM generation and management for specific parts of the C/C++ ecosystem, only a few can handle everything.
FOSSA has made significant investments in improving our C/C++ support across security, licensing, and SBOMs over the past year to support our many customers that rely on the ecosystem. Today, FOSSA customers can generate SBOMs that represent code snippets, vendored dependencies, Conan packages, and even binaries.
Additionally, full support for Yocto and Buildroot is coming soon.
Together, these give organizations one place to generate a genuinely complete C/C++ SBOM, and to evaluate incoming supplier SBOMs with the same rigor.
For more information on how FOSSA can help your organization with security, compliance, and SBOM management for C/C++, reach out to our team.