SBOM Tools for Firmware and Embedded Devices: What Most Solutions Miss
Generating a software bill of materials for firmware is a different problem than generating one for application code. Most SBOM tooling was designed with source code in mind - you run it against a repo, it reads package manifests, and it outputs a component list. That works fine for a Node.js web app. It falls apart when the target is a compiled firmware image for a medical device, an IIoT sensor, or an industrial controller.
This article is for security teams and product security engineers who need accurate SBOMs for binary artifacts - firmware blobs, device images, OT software - and are running into the limits of source-based tooling.
Why Source-Based SBOM Tools Struggle with Firmware
Source-aware SBOM tools rely on package manifests, dependency files, and build metadata. When you're working with firmware, those artifacts often don't exist, can't be extracted, or don't match what actually shipped. A vendor may have statically linked a library version that differs from what their build system claims. A third-party component may have been copied in, modified, and stripped of any identifying metadata.
The result is an SBOM that looks complete but isn't. Missing components mean missing CVE correlations, which means your vulnerability analysis is working from an incomplete picture. In regulated industries - medical devices, automotive, industrial control systems - that gap is not a compliance footnote; it's a patient safety or operational risk.
The core problem: firmware is a binary artifact. To generate a trustworthy SBOM for it, you need tools that analyze what's actually in the binary, not what the build system says should be there.
What Binary-First SBOM Analysis Looks Like
A binary-first approach starts from the compiled artifact - the thing that actually runs on the device. Instead of reading manifests, it fingerprints embedded libraries and components directly from the binary, identifies them against a known-component database, and builds the SBOM from that.
KhaiCode is built around this model. Upload a binary - firmware, container image, OT software - and it identifies the components inside using binary fingerprinting, then generates a standards-compliant SBOM in SPDX or CycloneDX format. No source code required.
That "no source required" piece matters more than it might sound. A lot of firmware security work involves third-party or vendor-supplied binaries where source access simply isn't available. OT environments often run software that predates modern build pipelines by a decade. Medical device manufacturers frequently receive firmware from component vendors with no source visibility at all. Binary-first analysis works on what you actually have.
From SBOM to Exploitability: The Step Most Tools Skip
An accurate component list is necessary but not sufficient. A firmware image might contain 200 identified components, 40 of which have known CVEs. What do you actually fix first?
Most SBOM tools hand you the list and leave the triage to you. The gap between "this CVE exists" and "this CVE is exploitable in this specific binary" is where security teams burn time and where prioritization errors happen.
KhaiCode's approach is to add exploit validation on top of the SBOM. After fingerprinting components and correlating CVEs and KEVs (Known Exploited Vulnerabilities from CISA), it applies binary analysis to assess whether a given vulnerability is actually reachable and exploitable in the binary as built. The output isn't just a vulnerability list - it's exploitability intelligence: which findings represent real attack paths in the artifact you shipped.
This is particularly relevant for firmware because build configurations, static linking, and platform constraints mean a CVE that's critical in one context may be completely unreachable in another. Generic CVE correlation without exploit validation produces noise. Exploit validation against the actual binary produces signal.
Emulation for Device-Realistic Testing
Another gap in many firmware security programs is that testing happens against a list of components, not against the running device environment. An attacker doesn't exploit a component list - they exploit the device as it runs.
KhaiCode includes multi-architecture emulation for edge devices, IIoT and IoT sensors, mobile systems, and embedded devices. The goal is to find vulnerabilities in the same environment where attacks occur, not in a generic analysis context. For teams building or securing products that run on non-standard architectures or constrained hardware, this closes a meaningful gap between what static analysis finds and what real-world exploitation looks like.
Scope: IT, OT, and Firmware Across the Stack
One practical advantage of a binary-first platform is that it handles diverse artifact types without requiring a different tool for each environment. KhaiCode covers software binaries, firmware images, containers, and OT software - which matters for organizations where the attack surface spans both IT infrastructure and operational technology, and where a single consistent SBOM format is needed across all of it.
SPDX and CycloneDX output means the SBOMs integrate with existing vulnerability management workflows, compliance reporting, and partner/customer disclosure processes.
Choosing the Right Tool for the Job
If your primary artifacts are source-code repositories and you have full build metadata available, a source-aware SCA tool is a reasonable starting point. If you're working with compiled firmware, vendor-supplied binaries, OT software, or any artifact where source access is limited or absent, you need a tool that starts from the binary.
The two approaches are complementary, not competing. Teams doing full-stack supply chain security often need both: source analysis for the code they write, binary analysis for the code that runs.
For firmware and embedded device supply chain security specifically, the question to ask of any SBOM tool is simple: can it analyze the binary without source code, and can it tell you which findings are actually exploitable in the artifact as built? If the answer to either question is no, the SBOM you're generating has gaps you can't see.
KhaiCode is available through Apona. If you're evaluating binary SBOM and exploit validation for firmware or embedded systems, reach out at apona.ai to see it against a real artifact.
This post is about KhaiCode.