Why do source scans miss dependencies in embedded software?

Why embedded builds hide dependency truth

Embedded software often hides dependencies until compile time, link time, or image assembly, so a source-only scan sees less than the thing that actually ships. That matters because the deployed firmware can include generated code, vendor drops, conditional modules, and native components that never appear as obvious imports in the repository. Binary inspection and build metadata are usually needed to recover the full picture.

What source scanners commonly miss in firmware and device code

Source scans are strongest when dependencies are declared plainly and resolved from readable manifests. They are weaker when a build system assembles code from multiple layers, such as vendor-provided source trees, precompiled objects, firmware blobs, board support packages, or code paths that only exist under specific compile flags. In those cases, the scan may report a clean dependency tree while the shipped image still contains additional libraries and transitive components.

That gap is especially common in embedded environments where portability, hardware abstraction, and toolchain constraints drive unusual packaging. A library may be copied into the tree, patched locally, or linked from a system image outside the repository. If the scanner cannot observe the build inputs, compiler switches, or final binary composition, it cannot reliably infer what the runtime actually depends on.

Open source consumption controls are relevant here because dependency visibility is not just a software engineering concern, it is part of knowing what third-party code is present in the product. NHIMG’s Open Source Security Guide and S2C2F Secure Supply Chain Consumption Framework Guide both reinforce the same practical point: you need a consumption model that inventories what is ingested, not only what is written in source form.

How to close the gap between source, build, and binary inventory

The most reliable approach is to treat source scanning as one input, not the final inventory. Build system metadata, lock files, compiler manifests, package manager state, and binary analysis each contribute different evidence. Where firmware or native code is involved, the final bill of materials should be reconciled against the produced artifact, not inferred from repository contents alone.

Practitioners should also expect exceptions from vendor drops and conditional compilation. If a component can appear only on a specific target, under a feature flag, or after a build step that expands templates or generated code, the scan result must be validated against the actual release artefact. The answer is not to trust a single scanner, but to combine repository review, build provenance, and post-build inspection so omissions become visible before release.

Open source hygiene also helps prevent blind spots from becoming risk blind spots. NHIMG’s Top 10 Open Source Software Risks and Open Source Software Policy Template are useful when you need a formal rule for how dependencies are approved, pinned, and inventoried across the product lifecycle.

Risk and Threat Considerations

When dependency discovery is incomplete, the main risk is not just a bad inventory, it is an underestimated attack surface. Unseen libraries, firmware blobs, and transitive components can carry known vulnerabilities, licensing obligations, or update obligations that never make it into remediation plans or release governance.

Failure mechanism: The scan is limited to readable source and declared imports, while the real dependency is introduced by build-time generation, vendoring, conditional compilation, or final linking. That creates a gap between what teams think they shipped and what the device actually executes.

Impact: Vulnerable or unsupported components can remain in production unnoticed, and later patching, incident response, or compliance work can fail because the team does not know the component exists. In embedded products, that gap can persist for long periods because the deployed artefact is harder to inspect than ordinary application code.

Practitioner Guidance

What to verify: Confirm that the dependency inventory is derived from the build output, not only the source tree. If the final image differs from the repository through code generation, vendoring, or conditional compilation, validate both views before trusting the result.

Implementation sequence: Start with source scanning for declared dependencies, then reconcile it with build metadata and a binary or firmware analysis step. When the three disagree, treat the artifact as authoritative and investigate the missing component rather than assuming the scanner is wrong.

Practitioner takeaway: For embedded software, dependency truth lives in the shipped binary and the build pipeline, so the practical control is reconciliation, not a better source scan alone.

Related resources from NHI Mgmt Group

• Why do transitive dependencies create unexpected open-source license risk in modern software?
• Why do static scans miss real application risk once software reaches production?
• Why do open source dependencies complicate secure software delivery?
• What are the best practices for securing open-source dependencies in enterprise software?