TL;DR: Source code and binary SBOMs can both miss or misstate what ships in embedded software, according to RunSafe Security, because build configuration, static linking and runtime dependencies distort the component picture. Build-time generation becomes the practical control when teams need vulnerability visibility that matches the compiled product.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Build-time SBOM generation gives the most accurate view of what actually ships, while source code and binary methods can miss or misstate dependencies.
Why it matters: This matters because vulnerability management, software supply chain assurance and compliance reporting all depend on an inventory that reflects the compiled product, not just the declared or scanned one.
Context
SBOM accuracy is a governance problem before it is a tooling problem. If the inventory does not reflect the compiled artifact, teams end up triaging the wrong components, missing statically linked code and overestimating what the final software contains. Where build pipelines and source trees diverge, the inventory becomes a documentation layer rather than a control.
For embedded software, the gap matters because build options, optimisation and vendored code can change the shipped package after source review is complete. That makes software supply chain failures an appropriate lens for the issue, even when the code base itself looks clean on inspection.
A source tree can look complete while the executable tells a different story, which is why source-only SBOMs are common but often incomplete in practice. Build-time generation is atypical only when teams can prove the source tree, build configuration and final artifact always remain in lockstep.
Key questions
Q: How should organisations use SBOMs to improve software supply chain governance?
A: Treat SBOMs as a live control input. Connect them to vulnerability management, licence review, build approvals, and supplier assurance so they drive action across the product lifecycle. That approach turns inventory into governance and exposes where third-party dependencies create unacceptable risk.
Q: Why do source code SBOMs miss dependencies that ship in the binary?
A: Source code SBOMs can miss dependencies because they only reflect what is declared or reachable in the source tree, not what the compiler, build tool or linker actually includes in the final artefact. Generated code, transitive libraries, build-time plugins and conditional compilation can all introduce components that never appear in the source manifest.
Q: What is the difference between source code and binary SBOMs?
A: A source code SBOM lists components visible from the repository, such as declared packages, imports and build files. A binary SBOM lists components detected in the compiled artefact, including statically linked libraries, bundled runtime pieces and other dependencies that only exist after build and linking.
Q: When should organisations prefer build-time SBOM generation?
A: Prefer build-time generation when you need the most reliable view of what was assembled into the release artefact. It usually captures dependency resolution more accurately than post-build inspection and gives security and engineering teams a stronger basis for release and audit decisions.
Technical breakdown
Why source code SBOMs overstate or understate shipping risk
Source code SBOMs are built from manifests and repository contents, so they describe declared dependencies rather than the exact artifact produced by the compiler. That makes them useful for early review, licensing and broad inventory work, but weak where conditional compilation, vendored code or generated assets change what ends up in the binary. They also cannot reliably capture runtime-only components that appear after deployment. In practice, that means a source SBOM can be clean while the final build still contains undeclared libraries or compiled-out packages that never should have been assumed absent. See the SBOM Guide.
Practical implication: Treat source SBOMs as upstream inventory, not as proof of what ships.
How binary SBOMs lose provenance and component boundaries
Binary SBOMs inspect compiled executables or firmware images after the build completes. They are valuable when source code is unavailable, but the post-build view obscures static linking, strips away some provenance metadata and forces version inference through heuristics. That combination increases both false positives and false negatives because the scanner has to reconstruct component identity from the artifact alone. For teams depending on the result for vulnerability tracking, the binary view can be operationally useful while still leaving important uncertainty about how a component entered the product. See the Source Code Leak Response Playbook.
Practical implication: Use binary analysis to inspect delivered artifacts, but do not treat it as a full provenance record.
Why build-time SBOMs are closest to the shipped artifact
Build-time SBOMs are generated during compilation, when the exact libraries, subcomponents and linked resources are present in the build pipeline. That gives them the best chance of matching the final output, including static links and build-only inclusions that other methods miss. Because the SBOM is created in the same workflow that produces the artifact, the inventory is tied to the software that will actually be released rather than to a separate source snapshot or reverse-engineered binary view. This is the point at which dependency truth and release truth are most aligned.
Practical implication: Generate SBOMs in CI/CD so the inventory is tied to the released artifact.
Threat narrative
Attacker objective: The attacker objective is to exploit a shipped dependency that teams never accurately inventoried, leaving a vulnerable component available in production.
- Entry occurs when source-only or binary-only inventory misses a dependency that is actually compiled into the release artifact.
- Escalation follows when hidden static libraries or build-time inclusions evade vulnerability review and remain untracked in the shipped product.
- Impact is incomplete vulnerability identification and weaker software supply chain assurance because teams are defending the wrong component set.
Breaches seen in the wild
- Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
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
Build-time SBOM accuracy is a provenance control, not a reporting preference. Once a release artifact diverges from the source tree, the inventory question changes from 'what was declared' to 'what was actually compiled'. That distinction determines whether vulnerability triage maps to the real attack surface or to a theoretical one. Practitioners should treat build-time generation as the point where supply chain evidence becomes operationally trustworthy.
Source-only SBOMs create a false sense of completeness in embedded environments. Conditional compilation, generated code and vendored libraries can leave a source tree looking orderly while the shipped binary contains a different dependency set. That is why the governance assumption at risk is component transparency, not developer intent. Teams need controls that follow the artifact, not the repository.
Binary analysis is useful for inspection but weak for lifecycle assurance. It can confirm what is present in a compiled image, yet it cannot reliably recover the full build story or the origin of static libraries. Software supply chain failures become harder to govern when provenance is reconstructed after release instead of captured during build. Practitioners should use binary SBOMs as a verification layer, not the primary record.
Embedded software teams need an artifact-centred trust model. The problem is not simply more data, but better alignment between inventory, build workflow and release gates. That alignment is what lets vulnerability identification and compliance evidence point to the same thing. Practitioners should make the compiled artifact the unit of SBOM truth.
Static linking is the named concept that most often turns inventory into guesswork. When library code is compiled directly into the executable, the boundary between product code and dependency code becomes opaque. That is why methods that rely on manifests or post-build signatures struggle to represent reality. Practitioners should assume static linking increases the need for build-time evidence rather than replacing it.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Source Code Leak Response Playbook
What this signals
Build-time truth is becoming the default trust boundary for software inventories. As release pipelines absorb more generated code, vendored dependencies and optimisation steps, inventory methods that look only at source trees will increasingly lag the shipped artifact. Practitioners should expect SBOM governance to shift from documentation to release gating, with the compiled build as the control point.
Source-only inventory creates a visibility gap that can survive into vulnerability operations. Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026. That same false confidence can appear in SBOM work when teams assume the repository tells the whole story; practitioners should align inventory, build evidence and release approval before they rely on the result.
For practitioners
- Shift SBOM generation into the build pipeline Generate the SBOM during compilation so the inventory reflects the exact artifact that will be released, not a separate source snapshot. See the SBOM Guide.
- Validate static linking and vendored code paths Check whether libraries are compiled directly into the executable or bundled during build, because those components are the ones source-only inventories miss most often.
- Use binary SBOMs as release verification Reserve post-build scanning for confirming the delivered firmware or executable, especially when source code is unavailable or third-party code is involved.
- Tie vulnerability triage to the released artifact Prioritise findings only after they are matched to the compiled product, so remediation work is not driven by dependencies that never shipped.
- Measure false positives against build truth Compare source-based and binary-based results against build-time output to identify where your current process over-reports or under-reports risk.
Key takeaways
- Build-time SBOMs matter because the release artifact, not the repository snapshot, determines what defenders actually need to track.
- Source-only and binary-only methods each leave blind spots, especially where static linking, generated code or conditional compilation changes the shipped component set.
- Practitioners should move SBOM evidence into the build pipeline so vulnerability triage and compliance reporting point to the same compiled output.
Related NHI Mgmt Group resources: OWASP Top 10 A03 Guide · Source Code Leak Response Playbook · SBOM Guide · EmeraldWhale Git config credential theft
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 NIST CSF 2.0 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-02 — Secret Leakage | Source and binary SBOM gaps can hide secrets and dependencies that should have been inventoried before release. |
| NHI-06 — Insecure Cloud Deployment Configurations | Build-time inventory is part of controlling release configuration drift across software delivery pipelines. | |
| Recommendation — Scan build outputs for exposed dependencies and secrets before release so hidden components are not missed. Align build outputs with governed release configuration so shipped artifacts match approved composition. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Repository compromise and hidden dependency exposure often precede credential theft and data loss in source code incidents. |
| Recommendation — Map repository exposure to credential access and exfiltration tactics when inventory and access controls fail. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | SBOM evidence supports integrity and trust in the software delivery chain, where artifacts must be protected end to end. |
| Recommendation — Protect build and release artifacts so the software composition evidence remains trustworthy across the pipeline. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | SBOM generation is part of secure software development and release hygiene for embedded products. |
| Recommendation — Embed SBOM generation into software release processes and verify the resulting inventory against the compiled 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.
- Source Code SBOM: A source code SBOM is a software bill of materials generated from source files and build metadata. It captures declared dependencies, imports and other components visible before compilation, so it reflects what the project says it uses rather than everything that may end up in the shipped binary.
- Build-Time SBOM: A build-time SBOM is an inventory of software components produced during the build process, before the application is released. It lists libraries, packages, and their relationships so teams can trace what was assembled. Technically, it captures dependency composition at compile or packaging time, supporting vulnerability review, license analysis, and supply chain assurance.
- Binary SBOM: A binary SBOM is a software bill of materials generated from compiled application artifacts rather than source code. It lists the binaries, libraries, and embedded dependencies actually present in a build, helping teams verify what was shipped, identify hidden components, and support vulnerability, license, and supply chain analysis across deployed software.
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 controls to the broader software and supply chain decisions 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