Is the nRF Connect SDK different from Zephyr here?

The SBOM command is the same, because the SDK is a west workspace. What differs is the set of modules, and some of them are vendor libraries the mapping tables may not know yet.

What about Nordic's prebuilt radio libraries?

Prebuilt binaries are shown as binary components with no identifier. Declarable lists them for you to review and does not claim anything about what is inside.

Do my files leave my browser?

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

Is this the same as Nordic's own tools?

No. Declarable reads what the build already wrote. It is not made or endorsed by Nordic Semiconductor or the Zephyr Project.

Platforms

nRF Connect SDK

An nRF Connect SDK SBOM that vulnerability databases can match

The nRF Connect SDK is a west workspace built around Zephyr, so west spdx writes the same four SPDX documents. The same gaps follow: documents that point at each other, a long list of build targets, and module versions that are commits and not releases.

Nordic adds its own libraries and prebuilt radio components on top. Those have no entry in a public vulnerability database under the name the SBOM uses, so they come back as unknown, not as safe. Declarable shows them as "not checked", never as zero known issues.

Check an SBOM, free Run it in CI →

The CI guide gives you the recipe for your nRF Connect SDK 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 nRF Connect SDK

From your nRF Connect SDK workspace, in the same way as Zephyr:

west spdx --init -d build
west build -d build
west spdx -d build

What to upload

app.spdx, zephyr.spdx, build.spdx, modules-deps.spdx — the four documents west spdx writes into your build folder
.config (optional) — shows which subsystems are compiled in
west.yml (optional) — the module list with pinned revisions, including the nRF Connect SDK manifest

What the check gives back

The documents merged into one component list
Identifiers added for the Zephyr modules the mapping tables know
Components with no identifier listed as "not checked yet", with the reason
A fixed CycloneDX file to download

Check an SBOM, free

Questions

Is the nRF Connect SDK different from Zephyr here?: The SBOM command is the same, because the SDK is a west workspace. What differs is the set of modules, and some of them are vendor libraries the mapping tables may not know yet.
What about Nordic's prebuilt radio libraries?: Prebuilt binaries are shown as binary components with no identifier. Declarable lists them for you to review and does not claim anything about what is inside.
Do my files leave my browser?: The files are read in your browser. When you ask for a vulnerability check, only component identifiers are sent.
Is this the same as Nordic's own tools?: No. Declarable reads what the build already wrote. It is not made or endorsed by Nordic Semiconductor or the Zephyr Project.

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 nRF Connect SDK SBOM that vulnerability databases can match

The CI guide gives you the recipe for your nRF Connect SDK 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.