How to Generate a Firmware SBOM When You Have No Source Code

Most SBOM guidance assumes you have a build system to hook into. You run your SCA tool at CI, it reads your package manifests and lock files, and out comes a tidy inventory of components. That works fine when you own the code and control the pipeline.

Firmware is a different problem entirely.

When you're assessing a device you purchased, inherited, or are responsible for securing - a router, a PLC, a medical sensor, a smart camera - you have a binary. Maybe a .bin, maybe a compressed filesystem image, maybe a raw flash dump. You do not have the vendor's source tree, their dependency manifests, or their build logs. Standard SCA tools stop at the door.

This article explains how binary-based SBOM generation works, what to expect from the output, and where the process breaks down if you're not careful.

Why "no source" changes everything

Source-based analysis is fundamentally a manifest-reading exercise with some light parsing on top. The tool looks at package.json, requirements.txt, go.sum, pom.xml - files that a human developer already wrote to describe what the project depends on. The SCA tool is mostly organizing information that exists in a structured form.

Binary analysis has to reconstruct that information from scratch. The compiled artifact contains no manifest. It contains machine code, and embedded inside it - often compressed, sometimes stripped, occasionally obfuscated - are the libraries the vendor linked against. The analysis job is to find those libraries, identify their versions, and map them to known vulnerabilities.

That requires a different class of tooling: binary fingerprinting, reverse engineering, and component correlation.

How binary SBOM generation works in practice

At a high level, a binary-first SBOM workflow runs in three stages:

1. Upload and fingerprint

You upload the firmware image or binary. The platform extracts and decompresses whatever it can reach - filesystems, packed archives, ELF binaries nested inside - and begins fingerprinting the embedded components. This is not string-matching on version banners (though that helps). Robust binary fingerprinting uses function-level signatures, compile-time artifacts, and library-specific byte patterns to identify what was actually linked in, even when version strings were stripped.

KhaiCode's approach is to build a build-specific fingerprint of what's inside - not a generic CVE scan, but a component identification tied to the specific binary artifact you uploaded.

2. Component correlation and CVE mapping

Once components and versions are identified, they are correlated against vulnerability databases - CVEs, KEVs (Known Exploited Vulnerabilities), and other sources. The output starts to look like an SBOM: a structured list of components with identifiers, versions, and associated vulnerability data, exportable in SPDX or CycloneDX format.

This is the stage most tools stop at. You get a list of vulnerable components. Whether any of those vulnerabilities are actually reachable in your specific binary is a separate question.

3. Exploit validation

This is where binary analysis can go further than any manifest-based SCA tool. Because the analysis is working on the actual compiled artifact, it can test whether a vulnerability is reachable in the code as compiled and linked - not just whether the vulnerable version number appears in a manifest.

KhaiCode runs exploit-based verification against an in-house exploit template database to confirm exploitability in the specific binary under analysis. The result is not "this version of libssl has CVE-X" but rather "CVE-X is present and reachable in this binary." That distinction matters enormously when you're prioritizing remediation or making a risk decision about a device you cannot patch quickly.

What you get out

A binary SBOM from this workflow should produce:

The SBOM format compliance matters for regulatory reasons - FDA, NIS2, and similar frameworks are increasingly requiring SBOM attestation for devices and software. Generating a firmware SBOM in a recognized format gives you something you can actually hand to a regulator, a customer, or your own risk team.

Where the process gets hard

Binary SBOM generation is not magic. A few honest limitations:

Heavily obfuscated or encrypted firmware may not yield much. If the vendor ships encrypted firmware images and you do not have the decryption key, analysis is limited to what is accessible before decryption.

Highly customized embedded components - a vendor who took an open-source library and made significant modifications without updating version strings - may be misidentified or unidentified. Fingerprinting databases improve over time, but coverage is not universal.

False negatives are possible. A component that is present but poorly fingerprinted may not appear in the output. Binary-based analysis is more complete than no analysis at all, but you should treat the SBOM as a strong working inventory, not a certified complete bill of materials.

When to use binary SBOM analysis

The short answer: whenever you are responsible for the security of software or firmware you did not build and do not have source access to. That covers:

For software you do own and build from source, binary analysis can still run as a final check on what actually shipped - to catch discrepancies between your declared dependencies and what the linker actually put in the binary. That is a complementary use case, not a replacement for source-based SCA.

Getting started

If you are dealing with a firmware binary today and have no clear path to a source-based SBOM, binary composition analysis is the practical option.

KhaiCode specializes in exactly this problem - binary-first supply-chain security, SBOM generation in SPDX and CycloneDX, CVE/KEV correlation, and exploit-based exploitability validation, across software, firmware, and container images for both IT and OT environments. It is built and maintained by a small senior team with a background in security research and demanding operational environments.

You can learn more or request a demo at khaicode.com, or reach out to Apona if you want to talk through how binary SBOM fits alongside your existing source-based security tooling.

This post is about KhaiCode.

More on this