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.
Why source-only scans miss what actually ships
Repository scans are built around what is present in source control, but embedded products are assembled from more than repository content. A firmware image can include vendor blobs, cross-compiled libraries, bootloader pieces, and generated artefacts that never appear as readable source, so a source-only inventory is incomplete from the start.
The practical gap is that the repository is usually the design input, not the full delivery artefact. If your scan never sees the final build output, it cannot reliably account for code pulled in during compilation, linked from external SDKs, or packaged into release images after the source review has finished.
That is why the same repository can look clean while the shipped device still contains additional components that matter for licensing, vulnerability exposure, and patch planning. A repository scan is useful, but it is only one view of the software supply chain.
What embedded build paths hide from composition analysis
Embedded build systems often assemble software through scripts, manifests, and toolchains that resolve dependencies outside the repository tree. In practice, a build may pull in static libraries, prebuilt objects, board support packages, or vendor firmware that are selected by configuration rather than checked in as source.
That creates blind spots in software composition analysis when the scanner only inspects files in the repository. If the artefact is generated, downloaded, or substituted late in the build, the component can reach production without ever being visible in the source snapshot that was scanned.
Firmware images and release bundles deserve separate scrutiny because they are the closest representation of what is actually deployed. When organisations scan build artefacts and manifests alongside source, they get a better chance of identifying third-party code, inherited dependencies, and code paths that were introduced by the build process rather than the repository itself.
How to raise coverage without trusting source control alone
The answer is not to abandon repository scanning, but to widen the evidence set. For embedded software, the most reliable inventory usually comes from correlating source repositories, build artefacts, firmware images, package manifests, and any bill-of-materials data the pipeline can produce.
A stronger process also needs version-aware provenance, because a component may be present in the image even when it is not declared in the repository metadata. That is the difference between knowing what developers intended to ship and knowing what the device actually contains.
MITRE D3FEND Guide is useful here because it treats software repositories, file artefacts, and integrity checks as separate defensive objects, which helps teams think beyond source-only visibility.
CISA Secure Software Attestation Form Guide is relevant when you need to explain why build provenance and artefact evidence matter as much as repository content in release assurance.
Risk and Threat Considerations
When repository scans miss embedded components, the risk is not just an incomplete report, it is an incomplete trust decision. Vulnerable or unapproved code can ship inside a firmware image even when the repository scan appears clean, which weakens vulnerability management, supplier assurance, and incident response.
Failure mechanism: The scan boundary stops at source control, while the real software bill of materials is assembled later from generated outputs, linked binaries, and vendor-supplied images.
Impact: Teams may miss exposed libraries, inherited flaws, or unexpected third-party code in a device, leaving remediation, disclosure, and patch prioritisation based on partial evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Build Provenance | Build provenance is central when repo scans miss binaries and generated artefacts. |
| Recommendation — Capture provenance for build inputs, outputs, and dependencies before release. | ||
| OWASP ASVS | V13 — Configuration | Configuration and build-time assembly determine what ends up in the shipped image. |
| Recommendation — Review build configuration and dependency resolution for hidden included components. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Software inventory and secure release checks help find components beyond source control. |
| Recommendation — Validate release artefacts and inventory the software you actually deploy. | ||
| NIST CSF 2.0 | ID.AM-02 — Software, services, and hardware assets are inventoried | The question is fundamentally about incomplete software asset inventory across artefacts. |
| Recommendation — Inventory shipped firmware and build artefacts, not just repository source. | ||
Practitioner Guidance
What to verify: Confirm that your scanning workflow covers the final build artefact, not just the repository, and check whether the pipeline can export manifests or component lists from the exact image being shipped.
Implementation sequence: Start with a source scan, then compare it against the built image, then resolve any drift caused by generated files, binary drops, or vendor packages. If the two views differ, treat the build output as the authoritative inventory for release decisions.
Practitioner takeaway: For embedded software, the security question is never “Did we scan the repo?”, it is “Did we inventory the thing that actually ships?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org