Why do I need this if esp-idf-sbom writes identifiers?

It writes them for components that carry an sbom.yml. The others come out without one. Declarable fills those from its mapping rows and leaves the rest marked as unknown.

What happens to the closed radio libraries?

They are listed as binary components and flagged. Declarable does not guess a vulnerability status for something it cannot see inside.

Do my files leave my browser?

The file is read in your browser. When you ask for a vulnerability check, only component identifiers are sent.

Is this made by Espressif?

No. Declarable reads what esp-idf-sbom writes and is not made or endorsed by Espressif.

Platforms

ESP-IDF

An ESP-IDF SBOM with the gaps filled in

ESP-IDF is the best-placed of the common platforms: esp-idf-sbom reads an sbom.yml file from each component and writes the identifiers it finds. For components that ship one, such as mbedTLS, lwIP and FreeRTOS, you already get a usable identifier.

The gap is the components with no sbom.yml. They come out under a made-up fallback name with no identifier, so a database cannot match them. Espressif's closed radio libraries (Bluetooth, Wi-Fi, PHY and coexistence) carry nothing at all, because they are prebuilt binaries.

Check an SBOM, free Run it in CI →

The CI guide gives you the recipe for your ESP-IDF build, and says where the API key and product id come from. Uploading from CI is part of the Maker plan and above (see pricing).

An is the list your build writes.

The free check reads your file in your browser and sends only component names, versions and identifiers when you press Check. The CI path uploads the file to your account.

Getting the SBOM out of ESP-IDF

From a built project:

idf.py build
idf.py sbom-create

What to upload

the SPDX or CycloneDX file esp-idf-sbom writes — either format works
dependencies.lock (optional, beside the SBOM, never alone) — adds the resolved versions of your managed components, which the SBOM alone leaves out

What the check gives back

Identifiers added for the components with none, from the mapping rows
The closed radio libraries flagged as binary blobs, with no identifier invented for them
The cve-exclude-list the component maintainers wrote into the SBOM (CVEs they judged not to apply, with their reason) kept as their statement, not ours, and shown as a suggestion for you to confirm, never applied
A count of what was added and what is still unknown
A fixed CycloneDX file to download

Check an SBOM, free

Questions

Why do I need this if esp-idf-sbom writes identifiers?: It writes them for components that carry an sbom.yml. The others come out without one. Declarable fills those from its mapping rows and leaves the rest marked as unknown.
What happens to the closed radio libraries?: They are listed as binary components and flagged. Declarable does not guess a vulnerability status for something it cannot see inside.
Do my files leave my browser?: The file is read in your browser. When you ask for a vulnerability check, only component identifiers are sent.
Is this made by Espressif?: No. Declarable reads what esp-idf-sbom writes and is not made or endorsed by Espressif.

Sources

Facts on this page checked on 2026-10-14.

Declarable prepares documentation for you to review. It is not legal advice and not certification. You sign your own declaration of conformity.

An ESP-IDF SBOM with the gaps filled in

The CI guide gives you the recipe for your ESP-IDF build, and says where the API key and product id come from. Uploading from CI is part of the Maker plan and above (see pricing).

An is the list your build writes.

The free check reads your file in your browser and sends only component names, versions and identifiers when you press Check. The CI path uploads the file to your account.