C/C++ SBOM completeness depends on vendored code and snippets

At a glance

What this is: This article explains why C/C++ SBOMs are difficult to complete accurately and shows that vendored dependencies, code snippets and mixed build systems can leave material blind spots.

Why it matters: For IAM, NHI and broader security programmes, the lesson is that inventory governance fails when source-of-truth assumptions are too narrow, especially where software supply chain evidence is used to assess third-party risk.

Context

C/C++ SBOM quality is limited less by the idea of a bill of materials than by how source artefacts are assembled. When dependencies are vendored into repositories, copied between projects, or built through several different package flows, manifest-only approaches miss material component provenance.

That matters because incomplete component inventories weaken compliance evidence, vulnerability triage and supplier assurance. The governance problem is not unique to C/C++, but the ecosystem’s lack of a single registry makes it especially easy for component ownership and provenance to drift out of view.

Key questions

Q: How should security teams handle SBOMs when code is vendored into repositories?

A: They should treat vendored code as first-class inventory, not as an implicit part of the repository. That means requiring origin records, version context and ownership for every copied dependency, then validating those records against repository scans and supplier evidence. A manifest-only SBOM is not enough when source code has been embedded by hand.

Q: Why do C/C++ SBOMs go incomplete so easily?

A: Because C/C++ ecosystems do not rely on one standard package manager or one central registry. Dependencies can arrive through tarballs, vendoring, build recipes, code copy-paste or multiple package tools, so the SBOM must reconcile more than one evidence source. If teams trust only manifests, they will miss real software inputs.

Q: When should snippets be included in an SBOM?

A: Include snippets when they create legal or provenance obligations, especially for licence compliance or when the copied fragment contains security-sensitive logic such as cryptography or parsing. For vulnerability management, apply materiality and avoid treating every small fragment like a full dependency. The policy should reflect use case, not convenience.

Q: What should teams do when a supplier SBOM looks clean but feels incomplete?

A: Cross-check it against the supplier’s build inputs, source tree and vendoring process. A clean manifest does not prove the absence of embedded code, and the missing material is often the part most likely to carry licence or vulnerability risk. Ask how vendored components were detected before accepting the SBOM as final.

Technical breakdown

Why manifest parsing misses C/C++ dependencies

C/C++ does not behave like npm or PyPI, where package registries and lockfiles create a relatively centralised dependency view. In this ecosystem, dependencies can arrive through Conan, vcpkg, CMake FetchContent, Yocto, checked-in tarballs or direct source copy. A tool that reads only manifests will therefore miss vendored code and other inherited material, which means the resulting SBOM may look complete while still omitting vulnerable or licensed code paths.

Practical implication: Use component discovery methods that inspect repository content and build inputs, not just declared manifests.

How vendored code and snippets change SBOM accuracy

Vendored code is a full dependency copied into the repository, while a snippet is only a fragment of source embedded inside another file. They create different governance problems. Vendored components often lack their own manifest, so they disappear from dependency-centric scans. Snippets may be less security significant than full dependencies, but they can still create licence obligations and provenance questions, especially when a small copied routine contains cryptography or parsing logic. See the Open Source Security Guide.

Practical implication: Classify vendored code and snippets separately so licence, vulnerability and provenance handling reflect their different risk profiles.

Why build-system graphs help but do not solve the problem

Conan improves visibility because it has an actual dependency graph, and Yocto can generate SPDX output from the build system itself. That helps recover structure that manifest-only tooling cannot see. But neither approach automatically covers the whole C/C++ estate, because Conan graphs only show Conan-managed dependencies and Yocto images still need careful handling of recipes, metadata and build outputs. Coverage is strongest when build-system data is combined with vendoring checks and snippet detection.

Practical implication: Treat build-system output as one input to SBOM generation, not as proof of full software provenance.

NHI Mgmt Group analysis

C/C++ SBOM failure is a provenance problem, not a formatting problem. The article shows that the central gap is not whether teams can produce an SBOM file, but whether that file actually represents the software they ship. When vendored code, tarballs and copied snippets are normal development practices, manifest-based inventories become structurally incomplete. Practitioners should treat source provenance as the governing issue, not output format choice.

Vendor-managed dependency graphs only solve the slice they can see. Conan and Yocto improve SBOM generation because they expose more of the build path than manifest parsing alone, but each still covers only part of the environment. That means governance has to reconcile multiple evidence sources instead of assuming one tool can certify completeness. Teams should align SBOM policy to the real dependency model, not to the most convenient one.

Snippets create a distinct compliance and security category that many teams under-handle. A copied code fragment may not carry the same vulnerability exposure as a full library, yet it can still create licence obligations and provenance uncertainty. The useful control is not simply to scan harder, but to classify snippets by materiality and use case so legal, security and customer-facing SBOMs do not demand the same treatment from every fragment.

Software supply chain security must now include repository archaeology as well as build integrity. In C/C++, the evidence you need may live in source trees, build recipes, version strings and vendor folders rather than in dependency manifests. That expands the governance surface for software supply chain security beyond conventional package control. Practitioners should assume that missing provenance is itself a risk signal, not just a tooling gap.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Software Supply Chain Security Guide

What this signals

Provenance coverage is becoming the real SBOM maturity test. Teams that can only inventory declared packages will continue to underestimate risk in ecosystems that mix vendored code, snippets and generated build artefacts. The next control question is whether the organisation can explain every component’s origin well enough to defend it during audit, incident review or supplier challenge.

C/C++ also shows why SBOM programmes must be designed around the software’s actual construction method. If the repository, the build system and the supplier each describe a different dependency set, the governance task is reconciliation, not documentation. That shifts attention from producing SBOM files to maintaining evidence continuity across the supply chain.

For practitioners

• Establish vendored-code inventory rules Require developers to document every new vendored dependency, including source origin, version and rationale, then audit legacy repositories for unlabeled copies.
• Cross-check supplier SBOMs against source trees Ask suppliers how vendored code was accounted for and run an independent scan to find code that a manifest-only SBOM may have missed. See the SBOM Guide.
• Separate snippet policy from full-dependency policy Define when snippets must be included for licence compliance, when they are material for vulnerability management, and when they can be represented only at component level.
• Use build-system evidence to enrich SBOMs Combine Conan, Yocto and other build outputs with repository checks so the SBOM reflects actual build inputs rather than only declared package metadata.
• Flag likely vendored paths during review Search for indicators such as third_party/, vendor/, README references and embedded version strings when reviewing repositories for missing provenance.

Key takeaways

• C/C++ SBOMs can look complete while still missing vendored source, snippets and other embedded dependencies that matter for compliance and supply chain assurance.
• The main weakness is provenance blindness, especially when teams rely on manifest-only tooling across ecosystems without a single package registry.
• Practitioners should combine repository checks, build-system evidence and supplier validation so SBOMs reflect the software actually shipped.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · CI/CD Pipeline Identity Security Guide · Open Source Security Guide

Key terms

• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Vendored Dependency: A vendored dependency is third-party code copied directly into a repository rather than fetched through a package manager. It can improve build stability, but it also removes the dependency from normal manifest-based discovery, which makes ownership, version tracking and vulnerability correlation harder.
• Code Snippet: A code snippet is a small copied fragment of source embedded within another file or project. Snippets may be too small to behave like full dependencies, but they can still carry licence obligations, provenance questions and, in some cases, security relevance when the copied logic is sensitive.
• Software Supply Chain Provenance: Software supply chain provenance is the record of where software came from, how it was built, and what changed along the way. It traces source code, dependencies, build steps, signing, and distribution artifacts so teams can verify origin, integrity, and accountability across development, release, and deployment.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity control design to broader supply chain and access decisions.