ESP32 Firmware SBOM: Finding Publicly Known Vulnerabilities for EN 18031 and the CRA

If you place a connected radio product on the EU market, two regulations now converge on the same demand. EN 18031, harmonized under the RED Directive and mandatory since August 2025, requires you to show your device ships with no publicly known exploitable vulnerabilities. The Cyber Resilience Act asks for the same outcome and names the artifact: products must be placed on the market without known exploitable vulnerabilities, and manufacturers must draw up a software bill of materials. Neither is satisfied by good intentions: both need you to know, concretely, every component inside your firmware and whether any of them carries a known flaw.

For application and container software, this is a solved problem. A mature ecosystem (Syft, Grype, Trivy, Dependency-Track) grew up around package managers and Linux images, where every dependency has a name, a version and a registry to look it up in. Firmware has none of that. Bare-metal C is vendored into the source tree, submodules are pinned to a git commit, and there is often no package manager and no registered identifier at all. The tooling that makes SBOMs trivial for a Docker image has historically had nothing to grip onto in an embedded build.

This is where one of the biggest names in IoT silicon quietly did the hard part for you. Espressif, whose ESP32 chips sit inside an enormous share of the world's Wi-Fi connected devices, ships an SBOM and vulnerability tool built directly into ESP-IDF. It generates the inventory from your real build and scans it against the National Vulnerability Database. It is not flawless, and this article is honest about where you still need to reach for a second database. But if you are shipping on an Espressif device, a job that is genuinely hard on most embedded platforms is largely done for you.

The two regimes arrive at the SBOM from opposite directions, and it helps to see exactly how. The CRA (Regulation (EU) 2024/2847) is blunt: Annex I, Part II, point 1 requires manufacturers to document components "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products."

That phrase deserves care, because it is easy to read too much into it. "At the very least the top-level dependencies" is the SBOM's explicit minimum depth, not a statement that top-level is enough. The same Annex I obligation is broader than the SBOM clause: you must document the components contained in the product and handle vulnerabilities in all integrated components (Recital 34). A transitive library compiled or statically linked into your firmware is an integrated component, so if a known exploitable flaw lives there, listing only the direct dependency does not discharge the duty. In practice you want the fullest reliable inventory your tooling produces, excluding build-only or unreachable dependencies with a documented reason rather than stopping at level one. On ESP32 that burden is largely lifted: as we will see, Espressif's tool already emits the full dependency graph, not just the direct dependencies.

EN 18031 never uses the word SBOM, but it lands you in the same place. Its requirement is GEC-1: up-to-date software and hardware with no publicly known exploitable vulnerabilities. You cannot demonstrate that a device carries no known vulnerability without first knowing what it is made of. The SBOM is not a deliverable the standard names; it is the practical prerequisite for the claim it does demand.

And both regimes converge on one word: exploitable. The CRA requires products placed on the market "without known exploitable vulnerabilities": one "that has the potential to be effectively used by an adversary under practical operational conditions." Not present. Exploitable. That distinction is what turns an intimidating raw CVE count into a short, defensible list, and, as we will see, it is exactly the line Espressif's tool already draws for you.

Espressif builds this into ESP-IDF. The esp-idf-sbom tool reached version 1.2.0 in June 2026 and is marked production-stable. Build your project first, then generate the inventory:

That writes an NTIA-compliant SPDX file into build/. To scan it for known vulnerabilities:

The standalone CLI gives you more control, and is what you want in CI:

The critical detail is the input: **project_description.json comes from your actual build**. The inventory describes the firmware you are about to ship, not a static catalogue of everything the SDK contains, which removes most of the noise generic scanners generate.

It also goes deep, not just wide. The SBOM is not a flat list of top-level components: it describes an SPDX package for the project application, the ESP-IDF framework, the toolchain, every component pulled into the build, and the git submodules and subpackages beneath them, linked by SPDX relationships. That is the full dependency graph, exactly the deeper-than-top-level coverage the CRA's broader obligations point toward.

Pass --format to control the serialization. Pick CycloneDX if you want VEX statements travelling alongside the inventory:

Supported values are spdx-tag-value@2.2 (default), spdx-json@2.2, spdx-json-ld@3.0.1 and cyclonedx-json@1.6. In CI the check exits non-zero when it finds a vulnerability or an invalid manifest, so a failing build is your signal to stop and triage.

Hitting the public NVD API on every build is slow and rate-limited: sync a local mirror once, then scan offline:

The mirror occupies roughly 900 MB, a fair trade for reproducible, offline-capable scans. Espressif also publishes an official GitHub Action, espressif/esp-idf-sbom-action, and runs a daily security dashboard over ESP-IDF releases as a useful independent cross-check.

Espressif's docs walk through a project pinned to an outdated libexpat 2.6.0. Running the checker prints a report summary straight to the terminal:

Thirty-two packages scanned, three CVEs against one XML parser, matched on the component's platform identifier cpe:2.3:a:libexpat_project:libexpat:2.6.0. On a real product with dozens of components, an unfiltered scan is how teams end up staring at a hundred findings the week before launch, and this is where Espressif's tool behaves better than most.

From the tool's own docs: "only packages with direct or indirect relationship to the project package are examined." The example every ESP32 developer will recognise: if mbedtls is compiled through a dependency but not linked into the final binary, it appears in the SBOM but is not reachable from the root project, so it is recorded in the inventory yet not flagged as a vulnerability. That is exactly the line EN 18031's GEC-1 and the CRA's definition of exploitable both ask you to draw, and most general-purpose scanners do not.

A few flags let you move that line deliberately, depending on how wide a net you want:

The honest limitation, stated plainly: the built-in checker queries the National Vulnerability Database only, matching by CPE, the identifier you saw in the report above. It does not query OSV, the GitHub Advisory Database, or OSS Index.

That matters more in 2026 than it did in 2023. NIST itself confirmed in April 2026: "Starting in early 2024, the NVD developed a significant backlog of unenriched CVEs... we have been unable to clear that backlog." A CVE that never receives CPE data cannot be matched by a CPE-based scanner, and this bites embedded work hardest, where libraries are often vendored into the source tree or pinned to a git commit with no registered CPE at all.

Alongside every CPE, esp-idf-sbom emits a Package URL (PURL), for example pkg:github/madler/zlib@<version>. A PURL points at the upstream source repository, and that is the key that unlocks the databases CPE cannot reach. OSV (osv.dev) matches by git commit range, so it can catch a vulnerable copy of a C library vendored into your tree with no CPE whatsoever. The GitHub Advisory Database carries first-party maintainer advisories, sometimes ahead of NVD.

This is not a workaround: it is the intended use of a portable, machine-readable bill of materials. Generate once with Espressif's tool, then query several databases with the identifiers it already gave you.

A raw scan tells you which components contain a vulnerability. Neither regulation asks that question; both ask whether it is exploitable in the product you are shipping. Triaging that down is where the SBOM-to-CVE pipeline earns its keep. For each finding, ask three questions in order: is the vulnerable code compiled into this build? If so, is the affected feature enabled in your configuration? If so, is it reachable by an adversary under practical conditions? A flaw in a TLS 1.3 handshake path is not exploitable in firmware that never negotiates TLS 1.3.

A decision you cannot show is a decision you did not make. VEX, a Vulnerability Exploitability eXchange statement, records the outcome in a structured form. Every finding gets one of four statuses: not_affected, affected, fixed, or under_investigation. Where you claim not_affected, you must supply one of five standard justifications:

esp-idf-sbom emits not_affected VEX statements in its CycloneDX output and supports per-CVE exclusion lists with documented reasons in SPDX. So the justification you reasoned through in a design review travels with the bill of materials, machine-readable, ready for a market surveillance authority or downstream integrator. If you have filled an EN 18031 vulnerability table, these categories will look familiar: VEX is the same reasoning in a form a machine can consume.

What Espressif's tool cannot do alone is see the CVEs NVD has not enriched, or the vendored library that never had a CPE. That is no reason for pessimism: the SBOM it produces already carries the PURLs those other databases need. Generate once, query broadly, judge honestly, and write the verdict down where a machine can read it. That is the engineering half. Turning those triaged findings into technical documentation that survives a market surveillance review is the compliance half, and it is where RedComply lives.

RedComply structures the whole EN 18031 assessment, including the vulnerability handling section GEC-1 drives. Import your findings, record each as remediated, mitigated, accepted, or not exploitable, and let the platform carry those justifications through to your test plan and Declaration of Conformity. The AI assistant reads your uploaded evidence (scan reports, advisories, design notes) and helps you write justifications that reference the actual document.

Run the scan with Espressif's tool. Bring the verdicts to RedComply and let the documentation build itself. Visit redcomply.com to see how the vulnerability handling section fits into a full EN 18031 assessment.