How should embedded teams generate SBOMs for C/C++ builds?

Why build-time SBOMs matter for embedded C/C++ releases

For embedded C/C++, the SBOM should describe the artifact that was actually built, because the build can include conditional compilation, static linkage, generated code and vendored libraries that a repository scan may not reveal. A build-time SBOM is therefore a release record, not just a source inventory, and it is the right basis for downstream vulnerability triage and customer attestation.

That distinction matters most when the build system resolves dependencies, compiler flags or platform-specific code paths that change what ships. If the SBOM is assembled from source alone, teams can miss components that are present in the final binary, or list components that never made it into the release.

For teams building and consuming open-source components, the practical baseline is to align SBOM generation with the software composition and release process described in the Open Source Security Guide, rather than treating SBOM creation as an afterthought.

What the build process should capture in an embedded SBOM

A useful embedded SBOM needs to capture the resolved component set, version or commit provenance where available, and the relationship between the shipped product and the libraries, toolchain outputs and vendored sources that contributed to it. In practice, that means taking the manifest from the build pipeline, not from a static directory listing.

Build-time generation is especially important when the compiler or linker can pull in archive members selectively, when feature flags change code inclusion, or when third-party source is embedded directly into the tree. Those cases create a gap between source visibility and release visibility, and the SBOM should close that gap.

The most useful reference point is an SBOM that can support release governance, not just document formats. The SBOM Guide covers SPDX and CycloneDX, generation methods, and quality expectations that help teams produce an artifact-level component record.

How teams should operationalise SBOM generation for C/C++ builds

Embedded teams should integrate SBOM creation into the build and release workflow so it runs after dependency resolution and before signing or packaging. That gives the SBOM a direct tie to the exact binaries, libraries and source bundles that were produced, which is what customers and vulnerability teams need later.

The key operational decision is whether the build system can emit trustworthy evidence from the same environment that creates the release. If not, the SBOM process should be adjusted so it records the resolved inputs, build flags and produced artifacts, then validates the output against the release bundle before publication.

Where supply-chain controls are already part of the delivery process, the same release evidence should support both SBOM quality and component governance. The OWASP Top 10 A03 Guide is a useful companion for teams that need to connect SBOMs with build integrity, signing and evidence practices.

Risk and Threat Considerations

If an embedded SBOM is produced from repository contents alone, the main failure is mismatch: the record can omit statically linked code, optional modules, vendored dependencies or generated files that were present in the shipped binary. That creates blind spots in vulnerability response and can leave customers with an inaccurate view of what they actually received.

Failure mechanism: Build-time selection, static linking and conditional compilation change the effective bill of materials after source review, so a source-only SBOM under-describes the released artifact.

Impact: Security teams may miss exposure, vendors may provide misleading attestations, and downstream triage can focus on the wrong components or fail to identify the true remediation path.

Practitioner Guidance

What to verify: Confirm that SBOM generation consumes the resolved build inputs and the final packaged artifact, not just a repository tree. If the SBOM cannot be regenerated from the same build context, treat it as a process gap rather than a documentation problem.

Implementation sequence: Generate the SBOM after dependency resolution, capture the build metadata that explains why components were included, and compare the result against the release artifact before publishing it. For C/C++ builds, the check should cover static libraries, vendored code and generated sources because those are the most common sources of drift.

Practitioner takeaway: For embedded software, the SBOM is only trustworthy when it is anchored to the build output that shipped, because release truth matters more than source-intent documentation.

Related resources from NHI Mgmt Group

• Guide: AI Supply Chain Security and AI-BOM Guide
• How should teams choose between source-based and binary-based embedded Linux builds?
• Why do embedded builds create longer vulnerability windows than server software?
• What breaks when organisations generate SBOMs but do not consume them?
• How should teams generate SBOMs without slowing CI pipelines?