Generating and Managing C and C++ SBOMs

What it is

A FOSSA practitioner guide to the three distinct C/C++ SBOM gaps — vendored code, code snippets, and tool-specific generation for Conan and Yocto — with a decision framework for when snippets actually belong in an SBOM.

How it works

For vendored components (full copy-pasted files with no manifest), the page recommends flagging by path convention (third_party/, vendor/), README inspection, and version-string matching, plus requiring documentation whenever new code is vendored and doing a one-time backlog audit. For snippets (partial file copies), it gives a use-case-driven inclusion rule rather than a blanket policy:

• License compliance SBOMs: include snippets, since even a small copyleft-licensed block can create obligations.
• Vulnerability management SBOMs: inclusion depends on materiality — a copied crypto or parsing routine matters, a generic algorithm snippet generally doesn't.
• Customer-facing SBOMs: use snippet detection internally to catch/remediate risk, but only represent confirmed origins at the component level externally.

It also notes a format-level constraint: SPDX has structured, dedicated snippet support; CycloneDX does not natively, though snippets can be represented there via the file component type combined with evidence/pedigree fields, or simply as a file component (supported in both formats).

For supplier-received SBOMs, the page flags that a "clean" manifest-only SBOM is likely to omit exactly the vendored components most likely to carry vulnerabilities — so the recommended check is to ask suppliers how vendored code was accounted for, or run an independent scan as a cross-check.

Preconditions / Affected

Conan's built-in SBOM path only covers Conan-managed dependencies — vendored code and snippets outside Conan's graph still need separate detection. Yocto's SBOM output is scoped to the image/recipe graph via OpenEmbedded.

What to do

• For vendored risk: grep/flag paths like third_party/ and vendor/, check README and version strings, and mandate documentation for newly vendored code.
• When ingesting a supplier SBOM, explicitly ask how vendored code was handled, or re-scan independently rather than trusting a manifest-only SBOM.
• Pick snippet-inclusion policy per use case (license vs. vulnerability vs. customer-facing) rather than a single global rule.
• If snippets must go in a CycloneDX SBOM, use the file component type plus evidence/pedigree fields, or just the file component type alone.

Caveats

The page states FOSSA's own Yocto/Buildroot support is "coming soon" (not yet complete) at time of writing, and its vendored-component detection is framed as a recent addition — so FOSSA's "handles everything" claim is partially forward-looking rather than fully current.