TL;DR: Embedded C/C++ SBOM evaluations often fail when tools rely on source scanning or binary heuristics instead of build-time evidence, according to RunSafe Security, because static linkage, vendored code and conditional compilation break generic assumptions. Build provenance, artifact specificity and deterministic generation are the controls that turn SBOMs into operational evidence.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Embedded C/C++ SBOM tooling needs build-time instrumentation because source scans and binary heuristics miss static linkage, vendored code and conditional compilation.
Why it matters: Practitioners need SBOMs that map to the released artifact, because inaccurate component inventories weaken vulnerability triage, compliance evidence and customer attestation.
Context
Embedded C and C++ environments create an inventory problem, not just a tooling problem. Package-manager assumptions break down when dependencies are statically linked, copied into the repository, or selected through conditional compilation, so a codebase scan can look complete while still missing what actually shipped.
An SBOM only becomes operational evidence when it describes a specific build artifact and not a broad repository snapshot. That distinction matters for vulnerability management, customer assurance and incident response, especially where the same source tree can produce different binaries across targets.
For embedded programmes, the governance gap is between declared dependency data and compiled reality. That gap is why software supply chain failures are often discovered only after a release is already in the field.
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 source scans miss dependencies in embedded software?
A: Source scans miss dependencies in embedded software because code may be compiled, generated, or pulled in at build time rather than appearing as readable source imports. Static analysis also struggles with vendored libraries, conditional compilation, and firmware blobs, so the resulting inventory can omit runtime-linked components, native libraries, and transitive dependencies. Binary analysis and build system metadata usually fill those gaps.
Q: Why does static linking make SBOM generation harder?
A: Static linking makes SBOM generation harder because library code is copied into the final binary, so package managers and runtime scanners may no longer see the original component boundaries. A useful SBOM process needs build-time provenance, compiler and linker metadata, and source-to-binary mapping to identify embedded C/C++ dependencies, licences and vulnerable code accurately.
Q: What should teams check before trusting an SBOM for vulnerability management?
A: Teams should check the SBOM format, component completeness, version precision, licence and supplier metadata, and whether it covers direct and transitive dependencies, build-time and runtime components, and generated code. They should also compare it with build manifests, package locks, and binary inspection results, because an SBOM without provenance or a clear generation method may miss embedded or statically linked software.
Technical breakdown
Why source scanning breaks on embedded C/C++
Source scanning reads manifests, repository contents and build metadata to infer dependencies, but embedded C/C++ projects often lack the package-manager structure those tools expect. When code is vendored, statically linked or conditionally compiled, the repository view no longer matches the binary view. The result is a plausible dependency list that still omits compiled-in libraries, alternate build paths and target-specific code. That mismatch is not a minor accuracy issue. It changes whether the SBOM can support release-level vulnerability analysis. See the SBOM Guide.
Practical implication: Use source scanning only as a partial input, not as proof of what shipped.
Why binary analysis struggles with static linkage
Binary analysis works backwards from compiled artifacts, which is useful when source access is limited, but it has to infer component identity from signatures, symbols and heuristics. In statically linked C and C++, libraries are folded into the executable, so the original package boundaries disappear. That makes version precision harder and can create both false negatives and ambiguous matches. Binary-only methods also struggle when compiler optimisations strip metadata or when multiple copies of a library exist in one image.
Practical implication: Treat binary analysis as a fallback for opaque builds, not the primary source of truth.
How build-time instrumentation preserves artifact truth
Build-time instrumentation observes the compilation process as it happens, capturing the dependency graph that produced the final artifact. That makes it better suited to embedded C/C++, where conditional flags, vendored sources and multi-target builds change what actually enters the binary. The key advantage is provenance: the SBOM is tied to the build event, not just the code repository. That does not make it perfect, but it gives practitioners a verifiable link between the declared components and the shipped image. See the OWASP Top 10 A03 Guide.
Practical implication: Anchor SBOM generation to the build pipeline so every release has a reproducible component record.
NHI Mgmt Group analysis
Build provenance is the decisive control for embedded SBOM quality: when the same source tree can produce different binaries, the governance question is not what exists in the repository but what entered the artifact. That is why repository-level dependency views are insufficient for embedded C/C++ release assurance. Practitioners should treat artifact-bound SBOMs as the minimum standard for trustworthy vulnerability and compliance decisions.
Static linkage creates a visibility gap, not just a parsing challenge: once libraries are compiled into the final binary, the original package boundary disappears and version certainty becomes harder to prove. That means the control problem is identity of the shipped component, not simple detection of a file. Teams should evaluate whether their inventory method can survive stripped metadata, vendored code and conditional compilation.
Deterministic SBOM generation matters because inconsistency is a governance defect: if repeated builds of the same inputs do not produce stable outputs, the resulting SBOM cannot serve as reliable evidence. That instability undermines customer attestation and incident response alike. The practical conclusion is to measure repeatability as part of tool qualification, not as an afterthought.
Artifact-specific inventory is now a software supply chain requirement, not a luxury: the article points to the same failure mode that broader supply chain guidance tries to close, where declared components and shipped components diverge. The right mental model is not just SBOM coverage, but release integrity across build variants. Practitioners should align tool choice to the build reality they actually run, including embedded and multi-target paths.
What this signals
Artifact-bound inventory becomes the control point for embedded release governance: when build variants, static linking and vendored code change the shipped binary, the SBOM has to follow the artifact rather than the repository. That shifts assurance from code awareness to release evidence, which is the level auditors and vulnerability managers actually need.
A credible SBOM programme for embedded systems will increasingly be judged by repeatability, version precision and the ability to explain misses. Teams that cannot prove those three properties will keep absorbing false confidence into vulnerability workflows and customer-facing attestations.
For practitioners
- Map your build paths before evaluating tools List every build system, target variant, conditional flag and vendored dependency that can change the final binary, then test coverage against that matrix.
- Demand artifact-bound SBOM output Require the SBOM to tie directly to a released build artifact rather than a repository snapshot, branch state or generic project scan.
- Verify static and vendored components explicitly Create a controlled build that includes static libraries, copied third-party code and architecture-specific branches, then confirm each appears in the output.
- Check version precision before you trust vulnerability matching Review how the tool distinguishes close library versions and whether it returns confirmed identifiers rather than UNKNOWN or approximate labels.
- Compare repeated runs for deterministic output Run the same build more than once and compare the resulting SBOMs to confirm that identical inputs produce identical component records.
Key takeaways
- Embedded C/C++ SBOMs fail most often when tools treat repository data as a proxy for the released binary.
- Static linkage, vendored code and conditional compilation make generic SBOM methods unreliable in real embedded builds.
- Build-time instrumentation is the strongest path to an SBOM that can support vulnerability triage, attestation and incident response.
Related NHI Mgmt Group resources: OWASP Top 10 A03 Guide · SBOM Guide · Software Supply Chain Security Buyer's Guide · Open Source Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Vendored third-party code and embedded libraries create hidden supply-chain dependency exposure. |
| NHI-09 — NHI Reuse | Repeated builds and reused codebases can hide stale component assumptions across artifacts. | |
| Recommendation — Inventory embedded third-party components and verify they are captured before release. Check whether the same component record is reused across different build variants. | ||
| SLSA | L3 — Build provenance | Artifact-bound SBOMs depend on build provenance and reproducible release evidence. |
| Recommendation — Tie SBOM generation to a provenance-backed build pipeline before treating it as release evidence. | ||
| MITRE ATT&CK | TA0007 — Discovery | Incomplete component discovery is the core failure mode in embedded SBOM generation. |
| Recommendation — Map missing component discovery to discovery gaps and test against known embedded dependencies. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | SBOMs are software inventory controls for released embedded binaries and their dependencies. |
| Recommendation — Maintain an accurate software asset inventory for each released embedded artifact. | ||
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 practice of adding measurement or inspection logic during the build process. It captures information from compilation, packaging, or image creation so tools can record components, provenance, or dependency data that may not be visible in source code alone.
- 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
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps security and identity practitioners connect build integrity to the wider governance controls their programmes depend on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org