In July 2020, researchers at JSOF disclosed Ripple20: 19 vulnerabilities in a single embedded TCP/IP stack, made by Treck Inc., that had been quietly licensed and copied into firmware from more than 79 vendors and shipped inside an estimated 100 million-plus devices — insulin pumps, industrial routers, printers, point-of-sale terminals. No single vendor wrote that vulnerable code, and most had no idea it was running inside their products. That is the defining problem of IoT firmware supply chains: a router, camera, or medical pump is rarely built from scratch. It is assembled from a chipset vendor's SDK, an ODM's board support package, a handful of open source libraries pulled in years earlier, and whatever proprietary glue code the brand on the box actually wrote. Each layer can carry vulnerabilities, backdoors, or stale dependencies that outlive the engineer who added them. Securing that chain means knowing what is actually inside the binary you shipped — not just what your own team wrote.
What makes IoT firmware supply chains harder to secure than application supply chains?
Firmware ships as a compiled, often stripped binary image assembled across multiple vendor tiers, with none of the manifests, lockfiles, or build logs that application supply chains rely on. A typical connected device passes through a silicon vendor's SDK, an ODM's board support package, and an OEM's branding layer before it reaches a customer — and the SBOM data, if it exists at all, usually stops at whichever tier last touched the source code. Ripple20 is the textbook case: the Treck TCP/IP stack had been OEM'd and re-OEM'd since the 1990s, so by 2020 no manifest anywhere listed it as a dependency in most of the affected products. Compounding this, IoT devices are frequently deployed for 10 to 15 years with infrequent or no over-the-air updates, meaning a 2020-era vulnerability can still be running unpatched on hardware installed in 2026. Cross-compilation for ARM, MIPS, or proprietary RTOS targets also strips symbol tables and debug metadata, so the string-matching and manifest-parsing techniques that work on an npm or Maven project frequently return nothing on a firmware binary.
How have vulnerable third-party components in firmware actually been exploited?
Attackers have repeatedly gone after the shared libraries and SDKs embedded inside firmware rather than the branded product wrapped around them, because one vulnerable component reaches every device that licensed it. The Mirai botnet, first observed in August 2016, compromised roughly 600,000 IoT devices using hardcoded default credentials and was later used in the October 21, 2016 attack on Dyn's DNS infrastructure that knocked Twitter, Netflix, and Reddit offline. In 2018, Cisco Talos disclosed VPNFilter, malware attributed to the APT28 group that had infected an estimated 500,000 routers and NAS devices across 54 countries by exploiting known firmware vulnerabilities rather than zero-days. More recently, Realtek's eCos-based Wi-Fi SoC SDK vulnerabilities — CVE-2021-35394 and related CVEs disclosed in August 2021 — were being actively exploited by Mirai variants within days, because the flaw sat in a chipset SDK licensed across dozens of downstream router and camera brands. Each of these incidents shares the same shape: one upstream component, many downstream victims who never audited what they'd licensed.
Which regulations now require an SBOM for firmware and connected devices?
Three overlapping mandates now require a software bill of materials for firmware, and they apply to different but expanding parts of the IoT market. US Executive Order 14028, signed May 12, 2021, directs federal agencies to require an SBOM meeting NTIA's minimum elements from any software vendor selling into government, a requirement that flows down to embedded and IoT vendors in federal supply chains. The FDA's Section 524B authority, added to the Food, Drug, and Cosmetic Act in December 2022 and enforced starting October 1, 2023, requires makers of "cyber devices" to submit an SBOM with every premarket submission, directly covering connected medical devices from infusion pumps to imaging equipment. The EU's Cyber Resilience Act, which entered into force on December 10, 2024, applies to essentially all products with digital elements sold in the EU and requires manufacturers to maintain an SBOM and report actively exploited vulnerabilities within 24 hours once its reporting obligations take effect in September 2026, with the full compliance deadline in December 2027. A firmware vendor selling into US federal, healthcare, and EU markets simultaneously is now subject to all three.
Can traditional software composition analysis even see inside a firmware image?
Not reliably — SCA tools built around source repositories and package manifests such as package.json or pom.xml fail on cross-compiled, stripped firmware binaries that carry none of that metadata. This is precisely why Ripple20 and its 2021 successor, Name:Wreck (nine vulnerabilities across TCP/IP stacks including FreeBSD's and Siemens' Nucleus NET, again affecting an estimated 100 million-plus devices), were found through manual reverse engineering rather than automated dependency scanning: the vulnerable stacks simply didn't appear in any manifest a scanner could read. Generating an accurate firmware SBOM instead requires unpacking the actual filesystem image — extracting the kernel, bootloader, and application binaries — and fingerprinting embedded libraries by binary signature, string artifacts, and version symbols rather than by manifest lookup. Tools that only parse source trees will report a clean bill of health on a device that is, in fact, running a decade-old vulnerable networking stack, because they never looked at what actually got compiled and flashed.
Is every vulnerable component found in a firmware image actually exploitable on the device?
No — most CVEs disclosed in embedded libraries are never reachable at runtime, because the vulnerable function is compiled into the binary but never called, is stripped out for that SKU, or sits behind a feature flag the manufacturer disabled by default. Microsoft's MSRC disclosed BadAlloc in April 2021, a set of 25 memory-allocation vulnerabilities spanning real-time operating systems and IoT SDKs including Amazon FreeRTOS and Google Cloud IoT Device SDK — but only devices actually invoking the vulnerable allocation path in their running configuration were exploitable, and many shipped configurations never exercised it. Treating every CVE in an SBOM as equally urgent produces exactly the alert fatigue that causes real firmware vulnerabilities like Ripple20's to sit unpatched for years: security teams triaging thousands of line items per device line can't tell which handful are the ones an attacker on the network can actually reach. Determining reachability — tracing the call path from the device's actual running services down to the vulnerable function — is what separates a firmware SBOM that's audit paperwork from one that drives real remediation priority.
How Safeguard Helps
Safeguard generates accurate SBOMs directly from firmware images and container/build artifacts, and ingests existing SBOMs from ODMs and chipset vendors, so security and compliance teams get a single, continuously updated inventory instead of a manifest that stops at the last tier that bothered to publish one. Griffin AI, Safeguard's reasoning engine, correlates that inventory against newly disclosed CVEs — the next Ripple20 or Realtek-style SDK flaw — and applies reachability analysis to determine which vulnerable functions are actually invoked by the device's compiled, running code paths, cutting a thousand-line CVE list down to the handful that matter for that specific build. For the subset of issues that are open source and patchable, Safeguard opens auto-fix pull requests against the affected component version, so engineering teams can ship a validated fix instead of researching one from scratch. Combined, this turns firmware SBOM generation, EU CRA and FDA 524B compliance reporting, and vulnerability triage from a manual audit exercise into a workflow that keeps pace with how firmware actually gets built and shipped.