--- title: "Generating and Managing C and C++ SBOMs" description: "Learn tips for generating and managing SBOMs in the C and C++ ecosystems." canonical_url: "https://fossa.com/blog/generating-managing-c-cpp-sboms/" markdown_url: "https://fossa.com/blog/generating-managing-c-cpp-sboms.md" content_type: "blog" language: "en" date_published: "2026-09-29" date_modified: "2026-09-29" author: "Andy Drukarev" organization: "FOSSA" --- # Generating and Managing C and C++ SBOMs > Learn tips for generating and managing SBOMs in the C and C++ ecosystems. [SBOMs (software bill of materials)](https://fossa.com/learn/sboms.md) have taken on critical importance in enabling compliance with [regulatory requirements](https://fossa.com/learn/sbom-compliance-requirements.md), 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](https://fossa.com/blog/snippet-scanning-explained.md) 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. 1. Conan has a built-in tool for generating SBOMs in CycloneDX. It can be found in the ```conan.tools.sbom``` module. 2. To use this feature, you’ll need to implement a hook in your client. (See Conan’s [documentation](https://docs.conan.io/2/reference/extensions/hooks.html#reference-extensions-hooks) for more information on hooks.) 3. 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](https://docs.conan.io/2/security/sboms.html) 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](https://fossa.com/learn/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](https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-create-spdx). This provides the ability to include VEX information, [PURLs](https://fossa.com/blog/understanding-purl-specification-package-url.md), 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](https://fossa.com/request-demo/). ## Related resources - [EU CRA Compliance Timeline: Key Dates and Deadlines](https://fossa.com/blog/cra-compliance-timeline.md): The EU Cyber Resilience Act compliance timeline explained: entry into force in December 2024, the September 11, 2026 vulnerability reporting deadline, and full conformity with CE marking by December 11, 2027, plus what to prioritize at each stage. - [CISA Releases the 2026 SBOM Minimum Elements](https://fossa.com/blog/cisa-releases-2026-minimum-sbom-elements.md): CISA, the U.S. government's Cybersecurity and Infrastructure Security Agency, released an update to its Minimum Elements for a Software Bill of Materials publication. - [Allan Friedman: Practical Guidance for Managing VEX Workflows](https://fossa.com/blog/allan-friedman-practical-guidance-managing-vex-workflows.md): Leading software supply chain security expert Allan Friedman shares concrete strategies for software producers and consumers to get value from VEX. - [A Roadmap for Automating the SBOM Management Lifecycle](https://fossa.com/blog/roadmap-automating-sbom-management-lifecycle.md): Get practical guidance for navigating each step of the SBOM management lifecycle. - [Allan Friedman on SBOM Regulations](https://fossa.com/blog/allan-friedman-sbom-regulations.md): Leading SBOM and software supply chain expert Allan Friedman analyzes several major SBOM regulations, including PCI DSS and the CRA. ## Source Canonical page: https://fossa.com/blog/generating-managing-c-cpp-sboms/