Firmware Security: Think Your Source Code Is Secure? Check Your Firmware

Your source code might be clean, but your firmware is a party full of strangers. And some brought vulnerabilities, both known and unknown.

What Is Firmware Security?

Firmware security is the practice of protecting the compiled code that runs on a device, from the bootloader up through the application layer, against tampering, known vulnerabilities, and exposed secrets. It covers what actually ships on the hardware, not what sits in the repo.

That distinction is the whole game. Application security assumes you control the source, can rebuild at will, and can patch in days. Firmware security assumes none of that. You inherit binaries from suppliers you never audited. You ship to devices that stay in the field for a decade. And you often cannot see inside the thing you are shipping without taking it apart first.

Three properties make it its own discipline:

• The artifact is compiled. Analysis has to work on binaries, not text.
• The supply chain is opaque. Third-party libraries arrive pre-built, sometimes with no manifest at all.
• The patch window is long. A fix that takes a web team an afternoon can take a device team a quarter, and that assumes the device accepts updates at all.

Get this wrong and everything downstream, your SBOM, your vulnerability triage, your compliance evidence, describes a product you did not actually ship.

Why Source Code Isn’t the Final Word

We’ve all heard it: "We scan the source. We're good." But are we? Not quite. 

In reality, what you write and what ends up running on a device are rarely the same thing. Compilers optimize, build environments inject configs, and developers sometimes cut corners ( this is my shock and awe face). The result? Code mutations you didn’t see coming.

Compilation is Transformation

Think of source code like a movie script. What ends up on screen—the firmware—is the director’s cut. Scenes are edited, characters change, and sometimes a surprise actor shows up uncredited.

• Compilers strip symbols
• Build scripts swap dependencies
• Optimization settings remove or morph intended logic
• Static libraries get bundled in, sometimes without even telling you

Bottom line? By the time your firmware is built, it might be something very different from what you wrote.

Binaries Don’t Lie, But They Don’t Talk Easy

If you want the truth, you need to analyze the binaries themselves. And that means digging deep:

• Reverse Engineering to recover function names, structures, and linked libraries
• Signature Matching to identify known vulnerabilities in stripped or obfuscated code
• Reachability Analysis to determine if vulnerable code paths are actually accessible at runtime

Traditional scanners don’t do this. They either fail outright or stop at surface-level inspection.

Case Study: GRIPE vs. Finite State

We tested an intentionally vulnerable firmware (IoT Goat) with a traditional container scanner. It flagged 247 issues. Not bad, right?

Then we ran it through a binary-level analysis with the Finite State platform.

Result? Almost 7,000 findings. Including:

• Critical CVEs missed by the first scan
• Hardcoded credentials
• Crypto material
• Deeply buried, exploitable logic flaws

The truth was buried in the binaries. And most tools didn’t even bother to dig. We don’t fault them for that, it’s just not what they were designed to do - and gives us a false sense of security.

Why It Matters

• Regulations Are Coming (Or Are Already Here): Cyber Resilience Act, Cyber Trust Mark, FDA 524B... they want transparency and real risk assessments.
• Attackers Don’t Care About Your Source Code: They go after what runs.
• SBOM Accuracy Depends on Reality: And reality lives in your firmware, not your IDE.

• How Do Firmware Vulnerabilities Differ From Software Vulnerabilities?

They differ in four ways, and each one changes how you find them and how long you live with them.

Discovery is inverted. In application security you scan source and get a file name and a line number. In firmware, symbols are frequently stripped, so a vulnerable OpenSSL build looks like an anonymous blob of machine code. Identifying it means matching signatures against known binaries, not reading a dependency file.

Ownership is fragmented. A web app declares its dependencies. A firmware image bundles static libraries, vendor SDKs, and board support packages that arrive pre-compiled from three tiers of supplier. A CVE in any of them is still yours to disclose and still yours to fix.

Persistence is longer. Application vulnerabilities die when you redeploy. Firmware vulnerabilities survive reboots, factory resets, and OS reinstalls, because the compromised code sits below the layer doing the resetting. That durability is exactly why attackers go looking for it, and it is what turns a single flawed component into a firmware breach that persists through remediation.

Remediation is physical. Sometimes the fix needs a signed update the device was never built to accept, or a technician on site, or a recall.

The practical effect: a firmware vulnerability found late is not the same event as an application vulnerability found late. One is a sprint item. The other is a field campaign.

Take Action

1. Include binary analysis in your CI/CD. Yes, it’s possible. Yes, it scales.
2. Scan your firmware, not just your codebase. Bonus: you catch your suppliers’ mistakes, too.
3. Correlate code-level intent with binary-level output. See if what you meant is what you shipped.

Firmware Security Best Practices for IoT Device Manufacturers

Most best-practice lists assume you are designing a device from scratch. Useful, unless you are shipping v7 of a product line that started in 2016. These are ordered for teams who already have a portfolio in the field.

• Establish a boot chain you can prove. Secure boot verifies each stage before it executes, so a modified image refuses to run. Ship it with keys you control and a documented recovery path, or you will brick a fleet the first time a signing step goes wrong.
• Sign, encrypt, and version every update. An unsigned update mechanism is a remote code execution vector you built yourself. Add rollback protection so nobody can force a downgrade to a version with a known CVE.
• Generate the SBOM from the binary, not the build manifest. A manifest lists what you meant to include. The binary contains what your compiler, your build scripts, and your suppliers actually included. When the two disagree, the binary is the one attackers get. That is the whole argument for SBOM generation grounded in the shipped artifact.
• Close the interfaces you stopped using. JTAG, UART, and debug consoles left live in production are the fastest route from physical access to full firmware extraction. Audit them per release, not per project.
• Rank findings by reachability, not severity alone. A CVSS 9.8 in a library your product never calls is not your top priority. A 6.5 sitting in the code path that handles network input is. Exploitability-based prioritization is what stops a 7,000-finding report from becoming shelfware.
• Build a disclosure path before you need one. The Cyber Resilience Act, FDA 524B, and the US Cyber Trust Mark all expect a manufacturer to detect, triage, and report. You cannot report what you never had visibility into, which makes analysis capability a prerequisite for compliance rather than a parallel workstream.
• Monitor after ship, continuously. A component that was clean at release keeps accumulating CVEs for as long as the product is in the field. For a ten-year device, that is ten years of new findings against a frozen binary.

The teams who do this well stop treating firmware as a build output that stops mattering once the box leaves the dock.

Final Word

Your source code might tell a beautiful story, but attackers read your firmware. If you’re not analyzing your binaries, you’re leaving your devices open to surprise plot twists. And in IoT security, surprise is rarely good.

Firmware Security FAQ

What is firmware security and why is it important?

Firmware security protects the compiled code running on a device against tampering, known vulnerabilities, and exposed credentials. It matters because firmware executes below the operating system, which means a compromise there survives the resets and reinstalls that clear ordinary malware, and because most device makers inherit the majority of their firmware from suppliers rather than writing it.

Can you assess firmware security without source code?

Yes, and often you have no choice. Supplier components, vendor SDKs, and legacy builds routinely arrive as binaries with no source attached. Binary analysis recovers structure, identifies linked libraries, and matches known vulnerable builds through signature comparison. Our team walks through the workflow in black box firmware analysis.

Does secure boot make firmware analysis unnecessary?

No. Secure boot proves the image you shipped is the image that runs. It says nothing about whether that image contains a five-year-old OpenSSL build or a hardcoded credential. Integrity and vulnerability are separate problems, and secure boot only solves the first one.

Do SBOM requirements apply to firmware?

They do, and firmware is where SBOM generation is hardest. Regulators and enterprise buyers increasingly ask for a bill of materials covering everything in the shipped product, including statically linked and third-party components that a build manifest omits.

How often should shipped firmware be re-analyzed?

Continuously, because the binary stays frozen while the vulnerability data around it does not. A component with zero known CVEs at release can accumulate several within a year. Point-in-time analysis at ship date tells you about a product that no longer reflects current risk.