What this is. Opinion + Experience + Fact (30% opinion · 35% experience · 35% fact). Written in collaboration with AI — I discuss, I do not outsource.

Why most of a connected product's security exposure lives in code the team never wrote — and what to actually do about it. The short version: your firmware is mostly third-party components, their vulnerabilities are your vulnerabilities, and you can't respond to a flaw you can't see. Know what's inside, know which devices run it, and be able to push a fix.

Most of your firmware is code you didn't write, and a CVE can hide in it A shipped firmware image is mostly third-party code — vendor SDK, RTOS, libraries — with your application on top. A vulnerability disclosed in any dependency is a vulnerability in your product, even though you did not write that code. Your firmware image: mostly code you didn't write your application code a minority vendor SDK / HAL / drivers RTOS + protocol stacks open-source library — CVE disclosed here ! A CVE in any layer is a CVE in your product — even though you didn't write it. know what you shipped: keep an SBOM.

Here's an uncomfortable truth about the connected product you're shipping: your team wrote a minority of the code inside it. The rest is a vendor SDK, an operating system or RTOS, a networking stack, a crypto library, a handful of open-source components pulled in to save months of work. That's normal and sensible — nobody writes a TLS stack from scratch for fun. But it means most of your security surface is inherited, and when one of those components has a vulnerability, it's your product with the hole, whether or not anyone on your team ever opened that file.

This is software supply-chain security, and for embedded it's become unavoidable — both because attackers target widely-used components and because regulation now expects you to manage exactly this. Here's how I think about it.

1. Most of your firmware is code you didn't write

Add up the third-party layers — the chip vendor's SDK, the RTOS, the protocol stacks, the crypto — and they're frequently the majority of the binary. Every one of them is maintained by someone else, on their schedule, with their bugs. When a vulnerability (a CVE — a publicly catalogued security flaw) lands in one of them, your device inherits it directly. You didn't cause it, but you own it, because it's your product in the customer's hands.

This isn't an argument against using third-party code — it's an argument for treating it as part of your product rather than someone else's problem. The dependency is yours the moment you ship it.

▸ First principle. You inherit the bugs of everything you depend on.

2. You can't patch what you can't see

The first practical step isn't a scanner or a firewall — it's an inventory. Most teams genuinely cannot list every component and version inside a shipped firmware image. And without that list, when a new CVE is announced in some widely-used library, you can't even answer the basic question: are we affected? You end up either ignoring it and hoping, or burning days manually spelunking through build files.

The fix is a software bill of materials (SBOM): a complete, maintained list of what's inside — every component, every version. It turns "are we affected?" from a research project into a lookup. It's now a baseline expectation in secure-development guidance for exactly this reason. (It's the security-side twin of simply knowing what you shipped.)

▸ First principle. Security starts with knowing what you shipped.

3. A public flaw is a clock

Here's the part that decides outcomes: the moment a vulnerability is public, attackers have the same information you do. From that instant, security is a race, and what you're really measured on is response time — how fast you can answer "which of my devices are affected?" and get a fix to them. This is precisely what modern regulation, like the EU Cyber Resilience Act (the "CRA era"), now expects of connected products: not perfection, but the ability to know and to respond.

Answering "which firmware is each device running?" quickly is, once again, the observability habit — every device's trace stamped with its device id and firmware version, so scoping an exposure is a query, not a guess. That per-device visibility is part of why I build EmbedIQ, my open framework for embedded and edge. Pair it with a real path to update the field and a public CVE becomes a managed event instead of a fire drill.

▸ First principle. You can't stop a dependency from having a CVE — you decide how fast you respond.

Sources

The practices here — third-party components as the bulk of firmware, CVEs in dependencies as inherited risk, the software bill of materials (SBOM) as the basis of vulnerability management, and regulatory expectations for vulnerability handling and updates (e.g. the EU Cyber Resilience Act) — are standard software-supply-chain-security guidance. This piece is method and lived experience; it contains no product performance figures. The EmbedIQ capability referenced is limited to on-device, per-device id/firmware observability; SBOM generation and patching are described as the product's responsibility, not EmbedIQ features.

FAQ

Why is most of a device's security risk in code the team didn't write?
Because firmware is largely third-party: vendor SDKs, an operating system or RTOS, networking stacks, and crypto and open-source libraries often make up the majority of the binary. A vulnerability in any of them is a vulnerability in your product, whether or not your team ever touched that code.

What is an SBOM and why does it matter for firmware?
A software bill of materials is a complete, maintained list of every component and version inside your firmware. It matters because you can't patch what you can't see — when a new CVE is announced, an SBOM turns "are we affected?" from a manual investigation into a quick lookup.

How should a team respond to a CVE in a dependency?
Treat it as a clock: once public, attackers have it too. Determine which components and versions you ship (via your SBOM), identify which fielded devices are affected (via per-device firmware visibility), and push a fix. Speed of response, not avoiding CVEs entirely, is what matters.

What does regulation like the Cyber Resilience Act expect?
Broadly, that connected-product makers can identify the components in their products, handle vulnerabilities, and deliver security updates over the supported life of the device — i.e., know what's inside and be able to respond, rather than ship and forget.

This is an IoT security field note. If you're trying to get a handle on what's actually inside your firmware, the longer story and how I work live on my profile. — Ritesh | ritzylab.com