Why AppSec SCA Tools Fail for Firmware

Why AppSec SCA Tools Fail for Firmware

You bought a software composition analysis tool to find open-source risks hidden in your code. The scanner reads your repositories, parses your manifests, maps your declared dependencies against known CVEs, and returns a report. On a web service or a cloud application, that approach works well. Point the same tool at a firmware image, and two things go wrong at once: the report accounts for a small fraction of what you actually ship, and, for the fraction it does report, it judges by a version number that the firmware has already made unreliable.

What makes the shortfall easy to miss is that nothing about the scan looks broken—it completes, the findings are real, and the report reads as authoritative. What it never tells you is how much of the image went unread, or how many of the CVEs it flagged don’t actually apply to the build in front of it. The components it skips tend to be the open-source libraries that a regulator expects you to account for under the EU Cyber Resilience Act, and the weak points that an attacker probes first. The CVEs are over-reported by version; meanwhile, burn your triage hours on risk that was patched before the image ever shipped.

Finite State built its analysis around both gaps. Closing them comes down to two questions that a source-based tool was never designed to answer for firmware: what is actually in the image, and which of it is actually a risk.

What AppSec SCA Actually Reads

Traditional SCA assembles its component list from declarations—your package.json, your pom.xml, your lock files, your source tree. From those, the scanner works out which open-source libraries you pulled in, at which versions, and matches them to vulnerability data. The model rests on a few conditions:

• Source or a manifest exists for whatever you’re scanning.
• Dependencies entered the build through a package manager that recorded them.
• The shipped artifact corresponds cleanly to those declarations.

In modern app development, that model works. The manifest accurately describes the build, and the scanner has good reason to trust it. Finite State runs the same source-based analysis where it fits—on a cloud service, it’s the right call.

Embedded firmware is built differently, and the assumptions behind that model don't hold up in it.

Where Firmware Breaks the Model

There’s often no manifest at all in firmware. Firmware ships as a compiled image, often a single monolithic binary with its dependencies statically linked. A library like OpenSSL, zlib, or BusyBox gets compiled directly into the image with no package record pointing back to it. Nothing in the artifact announces “OpenSSL 1.0.2k lives here.” A manifest-driven scanner finds nothing to parse, so it reports nothing, or it reports only the handful of components that happened to leave a trail.

The image has to be unpacked before anything can read it. Embedded firmware arrives in formats application tooling was never built to open: SquashFS, JFFS2, UBI, cramfs, vendor-specific containers, layered compression, and sometimes encryption. Reaching the components means recursively unpacking the image, walking the embedded filesystem, and pulling apart what sits inside. Source-based SCA stops at the front door.

Most of the risk comes from suppliers you can’t see into. A meaningful share of any device’s firmware consists of precompiled code from chip vendors and integrators: board support packages, real-time operating systems, drivers, and SDKs delivered as binary blobs with no source attached. A scanner that depends on source or manifests cannot inspect any of it, so the parts of your firmware you understand least are exactly where your tool stays quietest. Finite State reads those blobs directly, which is the only reliable way to learn what a supplier compiled into your image.

The architecture is wrong for the tool. AppSec SCA is tuned for the ecosystems apps live in: npm, Maven, PyPI, and similar. Embedded targets run on ARM, MIPS, PowerPC, and RISC-V, built through cross-compiled toolchains. The conventions the scanner relies on to recognize components don’t survive the trip to a cross-compiled binary for an architecture it never modeled.

What the Scan Misses

On firmware, those shortfalls leave you exposed in more than one way: the inventory comes back incomplete, and a whole category of risk goes unexamined.

Start with the inventory. Statically linked libraries buried several layers into the image, supplier code you can’t decompose, and forgotten dependencies that should have been retired releases ago all go uncounted. Every component that stays invisible becomes a CVE you aren’t tracking and a disclosure obligation you can’t satisfy.

Then there’s the risk that never resembled a dependency to begin with. Hardcoded credentials, private keys, and certificates baked into the image, expired or weak cryptographic material, and insecure default configurations all sit in the binary itself. A scanner indexing package metadata passes straight over them, because it works a level above where these problems live. Finite State surfaces this entire class of finding as a routine part of unpacking the image.

Compliance is where those missing components turn into a liability you carry. CRA and FDA premarket expectations both call for an SBOM that reflects what actually ships, kept current across the product’s service life. Generate that SBOM from source or manifests, and it’s incomplete the moment it’s produced. The document captures the code your team wrote and stays quiet about the statically linked libraries and supplier blobs shipping right alongside it.

Finding the Component Isn’t Confirming the Risk

Suppose the scan did see everything—every statically linked library, every supplier blob, a complete inventory read straight from the image. You would still be holding a list of names and version numbers, and on firmware, that is where the second problem starts. Matching a component to its CVEs by version is a lookup: take “OpenSSL 1.0.2k,” ask the vulnerability database what’s filed against it, and return the list. That lookup is only as honest as the version string—and on firmware, that string is unreliable from two sides at once: the supplier’s and the database’s.

Suppliers patch without bumping the version. A vendor backports a security fix into the build they ship you and leaves the version label untouched—the code is fixed, the string still reads 1.0.2k. A version lookup reports the CVE as present when the vulnerable code is already gone. Your team opens a ticket and burns hours confirming a fix someone else made, on a finding that was never real. And because the supplier compiled that build and you can’t see their source, the version string is the only signal a source-based tool has—so it follows the label straight into the wrong answer.

Vulnerability databases over-claim by version. That’s the same failure from the database’s side, and it’s just as common. NVD’s entry for CVE-2017-13704 marks every dnsmasq release up to and including 2.77 as affected, with no lower bound at all, so the range reaches back across years of releases the bug never touched. And the flaw was genuinely new in 2.77: it arrived in a memset() hardening change added that release, and was fixed in 2.78. A 2.62 build—many releases older than the code that introduced the bug—cannot contain it, yet any scanner matching on NVD’s open-ended range flags it as vulnerable all the same.

Either way, the only way to tell the two apart is to read the code. The version string is a label that a backport doesn’t update, and an attacker doesn’t care about; the binary is the evidence. It’s the same move firmware already forced on the inventory—stop trusting the manifest, read the image—applied one level up: stop trusting the version, read the code. That’s the difference between a list of the CVEs that might apply to your build and a verdict on the ones that actually do.

Analyze the Image You Actually Ship

Firmware SCA is software composition analysis performed on the compiled binary, so the inventory reflects what ships on the device instead of what the source tree declares. Binary SCA runs on the final artifact, after every build step has finished—no drift creeps in between a declared dependency and what the linker actually pulled in, because the analysis begins from the finished binary. That one shift—read the image, not the manifest—is what makes both halves of the problem solvable.

Doing it at a production scale takes tooling built for it. Within the Finite State Product Security OS, the Finite State Platform owns this layer: it recursively unpacks firmware across 130+ binary formats and 30+ instruction set architectures, walks the embedded filesystems, and identifies components straight from the compiled image—statically linked libraries and supplier blobs included, manifest or no manifest. It then correlates every finding against 200+ vulnerability and exploit intelligence sources and reconciles it with any supplier SBOMs you’ve collected. Finite State calls the result a ground truth inventory: a component list you can defend in front of an auditor, because it was read from the binary you actually shipped. That answers the first question—what’s in the image.

The second question—which of them is actually a risk—is where reading the binary pays off again. A complete inventory surfaces far more findings than a source scan ever would, and most of them aren’t reachable in the way your device is built and configured. Exploitability-based prioritization ranks the list by what an attacker could actually trigger in your specific image, which lets teams set aside roughly 90% of the noise and spend their triage hours on the vulnerabilities a real adversary could exploit. Deep binary analysis and reachability work together: one establishes everything present in the image, the other narrows it to the short list worth acting on first.

Reachability tells you a vulnerability can be triggered; the next step is to confirm it against the code itself—and that capability is now in early access at Finite State. It exercises the vulnerability to establish whether it’s genuinely exploitable in the way your device is built and configured, and reads the binary to settle the version-string problem from earlier—checking whether the vulnerable function is actually present or was quietly backported out, so a supplier’s silent fix reads as resolved instead of as an open ticket. The result is evidence you can hand an auditor or a customer: a per-finding verdict grounded in what the analysis actually observed and sealed as a replayable record, with the discipline to return inconclusive when the evidence doesn’t support a cleaner answer rather than dress up a guess.

Start From the Binary

Source-based SCA does real work on the artifact it was designed for. Embedded firmware is a different artifact, and a scanner that has only ever read repositories has never examined the image running on the device. It can’t see the components compiled into the binary—and for the ones it does name, it trusts a version string the firmware has already made unreliable. The SBOM it generates describes your source tree, which is not the same as describing your product, and the CVE list it returns describes a database’s idea of your versions, not the code you actually shipped.

For an automotive ECU, an industrial controller, or a medical device expected to stand up for a decade in the field, that distance decides whether you hold an inventory and a risk picture you can defend—or one you’re hoping no auditor examines too closely.

Closing that distance is the whole reason to analyze the binary. Book a demo to watch the Finite State Platform unpack a firmware image, surface the components a source scan never reaches, and rank what’s left by what an attacker could actually reach in your build—the part of your product you’ve been shipping without seeing.

Roland Lindsey is Lead Solutions Engineer at Finite State, with 30+ years in security and the last decade in software composition analysis. He currently works with device manufacturers on firmware supply-chain security and SBOM analysis, and on building agentic systems for vulnerability triage, remediation, and automated workflow.