SBOM accuracy depends on build-time evidence in embedded C/C++

At a glance

What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Embedded C/C++ SBOM accuracy depends on build-time evidence because repository scans and binary heuristics cannot reliably prove what shipped.

Why it matters: Practitioners responsible for software supply chain assurance need artifact-grounded SBOMs to support vulnerability matching, customer attestation and incident response.

Context

An SBOM is only useful when it can be trusted as evidence of what was actually released, not just what a tool inferred from code or binaries. Embedded C/C++ makes that harder because static linkage, vendored code and conditional compilation all change the final artifact without leaving a simple manifest behind.

SBOM governance matters here because the control problem is evidence quality, not file generation volume. When the build itself is the only reliable source of truth, validation has to focus on whether the SBOM matches the shipped artifact, not whether the scan produced a long component list.

That makes embedded projects atypical compared with language ecosystems that preserve dependency metadata in lockfiles or package manifests. In this environment, SBOM quality depends on build observability and traceability more than on scanning breadth.

Key questions

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

A: Embedded teams should generate SBOMs from the build process, not from repository snapshots alone. Build-time evidence captures static linkage, conditional compilation and vendored code that source scanning can miss. The goal is a component record that matches the released artifact, so vulnerability triage and customer attestation rely on what actually shipped, not what could have shipped.

Q: Why do repository scans miss components in embedded software?

A: Repository scans miss components in embedded software because the source repository often does not contain every shipped binary, generated file, or vendor-supplied firmware image. Build scripts may pull in static libraries, precompiled objects, and cross-compiled dependencies during the build, so a scan of source alone can overlook code that ends up in the device. Software composition analysis needs build artefacts, firmware images, and manifest data to improve coverage.

Q: What makes static libraries hard to capture in an SBOM?

A: Static libraries are hard to capture in an SBOM because their code is compiled directly into the final binary, so the original library boundary disappears. A repository scan may see the source or package reference, but not the exact linked code path, build options, or transitive objects included at compile time. Build-system metadata, link maps, and binary analysis are often needed to identify them reliably.

Q: What should teams do first when their SBOMs are inconsistent across tools?

A: Start by standardising the fields that must appear in every SBOM, then enforce one generation method in the build pipeline. If teams cannot trust what the record means, they cannot compare releases, automate vulnerability checks or use the SBOM as evidence in audit and incident workflows.

Technical breakdown

Why repository scans miss embedded dependencies

Repository scanning looks at source files and infers dependencies that might be compiled, but embedded C/C++ builds are shaped by compiler flags, architecture targets and conditional blocks. Two builds from the same repository can produce different output, so a source-level inventory cannot guarantee the SBOM reflects the released firmware. The gap widens when vendored code sits inside the tree and appears indistinguishable from first-party code. The mechanism problem is that the scan sees potential composition, not actual composition. See the SBOM Guide.

Practical implication: Use build-aware collection for embedded releases instead of treating repository inventory as evidence of shipped software.

Why static linkage breaks component visibility

Static libraries are compiled into the final binary, so their boundaries disappear at link time and many tools lose the ability to enumerate them cleanly. Binary analysis can sometimes recover signatures, but it often relies on heuristics and may miss or misidentify components, especially when versions are not preserved in the artifact. For embedded software, that means the attack surface can be present in the release while absent from the SBOM, which undermines vulnerability correlation and release assurance.

Practical implication: Instrument the build so static libraries and vendored code are captured before they disappear into the final artifact.

Why artifact binding matters for SBOM trust

An SBOM becomes operationally useful only when it can be tied to a specific shipped artifact through a deterministic hash or equivalent release binding. Without that link, incident responders cannot tell whether a vulnerable component was present in the release they are investigating, and customers cannot verify the exact build they received. A snapshot tied to a branch or repository state is not enough when releases are rebuilt, patched or reconfigured after the fact. See the OWASP Top 10 A03 Guide.

Practical implication: Bind each SBOM to the released binary or firmware image so the same record can support response and attestation later.

Threat narrative

Attacker objective: Exploit gaps in software composition evidence so vulnerable components remain undiscovered, unpatched or unprovable in shipped embedded releases.

1. Entry occurs through a weak SBOM generation path that infers composition from repository state instead of observing the actual embedded build.
2. Credentialed or shipped components remain hidden when static libraries, vendored code and conditional compilation are not captured in the output.
3. Escalation happens operationally when a missing component defeats vulnerability matching and release traceability during review or incident response.
4. Impact is false assurance: teams believe they can attest to what shipped, but they cannot prove the contents of a specific firmware release.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Artifact truth, not scan volume, is the real SBOM control: Embedded C/C++ forces practitioners to judge whether the record matches the shipped output, not whether a scanner produced a long inventory. Build-time evidence is the only reliable basis for that judgement when conditional compilation and static linkage change the software that actually runs. The practical conclusion is that SBOM governance should be evaluated on release fidelity, not component count.

Build observability is a supply chain control, not a reporting convenience: When the build process is opaque, the SBOM becomes an approximation that cannot support reliable vulnerability correlation. That creates a governance gap similar to inventory drift in other identity and asset domains, where the record exists but cannot be trusted as current or complete. Product security teams should treat build observability as part of software assurance, not an optional enhancement.

Static-linkage opacity creates a named failure mode: hidden component composition: In embedded releases, libraries can vanish into the final binary while still remaining security-relevant. That makes the absence of a component from the SBOM an unreliable signal unless the generation method observed the link step itself. The practical implication is that evidence collection has to move upstream into the build pipeline.

Manual SBOM maintenance is evidence debt, not a workaround: Spreadsheet-based inventories cannot keep pace with embedded builds, rebuilds and vendor updates, so they routinely lag the release they are meant to describe. That leaves teams with a document that is easy to produce and hard to trust. Practitioners should treat manual upkeep as a temporary stopgap, not a defensible operating model.

What this signals

SBOM fidelity becomes a release-management problem: The deeper lesson is that composition records only become useful when they can survive rebuilds, cross-compilation and product variations. That pushes SBOM governance toward deterministic builds and artifact-level assurance, not just more scanning.

Embedded assurance needs provenance, not assumptions: Once a product includes vendored code and link-time composition, the security question changes from what is present in the repository to what can be proven in the released binary. That is where supply chain controls and release evidence become inseparable.

For practitioners

• Validate the SBOM generation method Confirm whether the tool observes the build, infers from source, or reconstructs from binaries, and reject outputs that cannot explain how the component list was produced.
• Test against a known build Use a controlled embedded project with static libraries, vendored code and conditional compilation, then check whether every expected component appears with precise version data.
• Bind SBOMs to release artifacts Require a cryptographic link between the SBOM and the exact firmware or binary that shipped so later investigations can verify the released build.
• Compare multiple tool outputs Run more than one SBOM tool on the same embedded build and investigate any differences as evidence of incomplete or incorrect composition analysis.
• Cover every shipped output Include firmware images, bootloaders, shared libraries and auxiliary binaries in the release process so a partial SBOM cannot masquerade as complete.

Key takeaways

• Embedded C/C++ SBOMs fail when they describe source repositories instead of released artifacts.
• Build-time instrumentation is the decisive control because it captures static linkage and conditional compilation.
• Artifact binding and deterministic output turn an SBOM into evidence that can support response and attestation.

Related NHI Mgmt Group resources: OWASP Top 10 A03 Guide · SBOM 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.
• Build-Time Instrumentation: Build-Time Instrumentation is the insertion of logging, tracing, or analysis hooks during software compilation or packaging. It captures dependency, provenance, or policy data from the build process itself, rather than inferring it later from source or binaries, which can improve software supply chain visibility and SBOM accuracy.
• Static Linking: Static linking is the build-time process of copying library code into an application so it runs without loading those libraries separately. In software security, this reduces runtime dependency exposure and version drift, but it also fixes the included code into the binary, which can complicate patching, vulnerability management, and forensic tracing.
• Vendored Code: Vendored code is third-party source copied directly into a repository instead of being consumed through a package manager. That practice can obscure version, licence, and modification status, so teams need explicit provenance records and file-level licence metadata.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management in practical terms. It gives security practitioners a shared foundation for governing identities and credentials across modern software delivery.