Which Yocto releases does this cover?

Both shapes create-spdx writes are read: the archive from Yocto 5.0 and earlier, and the single SPDX 3 JSON document from 5.1 on. The format has changed between releases, so a file from a release we have not seen may need work.

Why is the archive compressed with zstd?

That is how Yocto packs it. Declarable unpacks it in your browser, so you do not need to extract it first.

Do my files leave my browser?

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

Does this replace Yocto's own CVE checking?

No. Yocto can check CVEs at build time. Declarable works from the SBOM you will hand to others, and shows what is known against it between releases. If you also upload the cve-check report or the recipes with CVE_STATUS lines, the decisions your build already made come along as suggestions for you to confirm, never applied on their own.

Platforms

Yocto

A Yocto SBOM that vulnerability databases can match

create-spdx writes its SBOM in one of two shapes, and Declarable reads both. Yocto 5.0 and earlier write a compressed archive holding an index and one SPDX document per recipe and per package, each pointing at the others: for a small image that is over a hundred documents, with no single list of what is in the image. From Yocto 5.1 it writes one SPDX 3 JSON document for the image.

Yocto vulnerability tracking uses its own product names (CVE_PRODUCT), and they do not always match the recipe names in the SBOM. A recipe called one thing can be tracked under another, so a naive match misses it.

Check an SBOM, free Run it in CI →

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

Add this to conf/local.conf, build the image, then take the archive from the deploy folder:

INHERIT += "create-spdx"

bitbake core-image-minimal
ls tmp/deploy/images/*/*.spdx.tar.zst

What to upload

<image>.rootfs.spdx.tar.zst (Yocto 5.0 and earlier) — the whole archive from your deploy folder; Declarable unpacks it in your browser
<image>.rootfs.spdx.json (Yocto 5.1 and later) — the one SPDX 3 JSON document create-spdx writes instead of an archive; upload it as it is
license.manifest (optional) — cross-check of what is really in the image
the cve-check JSON report (optional) — Yocto's own list of the CVEs it checked and what it decided about each
recipe or local.conf files with CVE_STATUS lines (optional) — where you or a layer marked a CVE as fixed, ignored or not affecting you

What the check gives back

The index and the per-recipe documents folded into one component list
Identifiers added from recipe names to the vendor and product pairs vulnerability databases use
Packages that are in the image but not in the SBOM, if you added the manifest
Your build's own CVE decisions (from the cve-check report and CVE_STATUS lines) offered as suggestions for you to confirm, never applied
A fixed CycloneDX file to download

Check an SBOM, free

Questions

Which Yocto releases does this cover?: Both shapes create-spdx writes are read: the archive from Yocto 5.0 and earlier, and the single SPDX 3 JSON document from 5.1 on. The format has changed between releases, so a file from a release we have not seen may need work.
Why is the archive compressed with zstd?: That is how Yocto packs it. Declarable unpacks it in your browser, so you do not need to extract it first.
Do my files leave my browser?: The archive is read in your browser. When you ask for a vulnerability check, only component identifiers are sent.
Does this replace Yocto's own CVE checking?: No. Yocto can check CVEs at build time. Declarable works from the SBOM you will hand to others, and shows what is known against it between releases. If you also upload the cve-check report or the recipes with CVE_STATUS lines, the decisions your build already made come along as suggestions for you to confirm, never applied on their own.

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.

A Yocto SBOM that vulnerability databases can match

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