Know what is in every build you ship, and what is wrong with it

The Cyber Resilience Act turns a good habit into an obligation: know what your firmware is made of, watch it for known vulnerabilities, and fix them in the field. Pinscope already updates the devices; now it also keeps the SBOM of each build and checks it every day.

Why now

From 11 September 2026, makers of products sold in the EU have to report actively exploited vulnerabilities in them within 24 hours of knowing. From 11 December 2027, every new product needs a machine-readable SBOM, vulnerabilities handled without delay through security updates, and a support period of at least five years in most cases. That is Regulation (EU) 2024/2847, the Cyber Resilience Act, and it covers the firmware on a microcontroller as much as an app.

The hard part is not making an SBOM: ESP-IDF and Zephyr write one for you. It is keeping track, for every build you shipped, of what in it has become vulnerable since, and on which devices that build still runs.

What it does

In a project's new Security tab, on the paid plans:

attach the SBOM of a build to its firmware image, by hand or from CI with the image;
the packages linked into the firmware are checked against the NVD every day;
each vulnerability is listed with the devices that run an affected build;
you record a status for each one, affected, not affected or fixed, with a note;
a new vulnerability arrives by email and webhook the day it is published;
the support period and everything above export as a JSON or CSV report.

The same answers as Espressif's checker

Matching an SBOM against the NVD is easy to get wrong in both directions: miss a vulnerability because a package is named differently, or flood the list with ones that do not apply. We follow esp-idf-sbom, Espressif's own tool: only packages actually linked into the application are checked, the name aliases it knows are applied (mbed TLS has been published under more than one vendor), and the vulnerabilities Espressif has excluded for ESP-IDF, with its reasons, are left out. On ESP-IDF 5.5.3 the result is exactly the list idf.py sbom-check prints.

An SBOM from your build

Pinscope reads SPDX (tag-value, JSON, 3.0) and CycloneDX. The build tools already write them:

# ESP-IDF (pip install esp-idf-sbom)
idf.py sbom-create          # writes build/<project>.spdx

# Zephyr
west spdx --init -d build
west build ... -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d build          # writes build/spdx/*.spdx

Arduino and PlatformIO builds have no SBOM generator of their own yet. Any SPDX or CycloneDX file of the build works, written by hand or by another tool, as long as each package carries its CPE, the identifier the NVD uses (for example cpe:2.3:a:espressif:esp-idf:5.5.1:*:*:*:*:*:*:* for the ESP-IDF that arduino-esp32 is built on); packages without one are listed but not checked.

Attach it to the firmware it belongs to, in the dashboard's Security tab, or from CI together with the image:

curl -fsSL https://pinscope.dev/ci.sh | sh -s -- build/app.bin --sbom build/app.spdx

The GitHub Action takes the same file as its sbom input.

What it leaves to you

The risk assessment, the technical documentation, the conformity assessment and the report to the authorities stay with you. Pinscope gives them the facts: what is in each build, what is vulnerable, where it runs, and when you fixed it. More on what the Act asks and what Pinscope covers.