SBOM, CRA and Yocto releases

Bitloom reads the evidence your build already produces and tells you, release by release, what is missing for a machine-readable SBOM and for vulnerability handling under the EU Cyber Resilience Act. It reports engineering evidence; it is not a conformity assessment or legal advice.

Release awareness#

Bitloom detects the Yocto series from LAYERSERIES_CORENAMES in the core layer (Poky, separate OE-Core or kas workspaces) and shows it in the top bar, the web header and the CRA report.

Every operation, SBOM option, CRA check and Studio default asks one registry of release capabilities (bitloom/capabilities.py, listed in the command reference). Each capability is decided by evidence in the project first: the class in its layers (vex.bbclass, sbom-cve-check.bbclass, create-spdx-3.0.bbclass…), the tool in its own BitBake (bitbake-config-build, bitbake-setup), the kind of workspace; the release number is the fallback when the layers are not visible from Bitloom. A backport is therefore offered, and a class a release lacks is not. Configuration shows the answer for the active project (web: What this release can do; TUI: the Release · health rows). When a feature does not exist in the project's release, Bitloom says so and offers what the release can do:

• the command center marks the operation (not in this release), disables queueing and names the alternative (for example cve-check on Scarthgap instead of sbom-cve-check);
• the web dashboard refuses it with the same explanation;
• bitloom --ci skips it with a warning annotation and a JUnit <skipped> entry instead of failing the matrix;
• the SBOM settings screen shows n/a and refuses to enable it.

When the release cannot be detected locally (for example layers only inside a container image), Bitloom lets the runtime decide and probes optional tasks before queueing.

Screenshot Command center on Scarthgap explaining that sbom-cve-check needs Wrynose

SBOM quality#

Artifacts → s (or bitloom --sbom) analyses the newest image and SDK SBOMs offline:

• SPDX 3.0 JSON-LD (IMAGE.spdx.json, Styhead and later).
• SPDX 2.2 images, which ship IMAGE.spdx.tar.zst: Bitloom joins the image manifest with the per-package and recipe documents in tmp/deploy/spdx, so no zstd tooling is needed.

An SPDX 3 image SBOM from OpenEmbedded also describes the recipes that produced the image (including -native build tools), the downloaded source archives and the image itself. Coverage is measured on the installed packages (software_primaryPurpose install), the components that ship; the report lists how many other elements the document describes.

For each SBOM it reports the share of packages with a version, a PURL, a CPE, licence information and a supplier, the VEX status counts (affected, under investigation, fixed, not affected) with the affected CVE identifiers, the CVEs that SPDX 2.2 recipes record as fixed, and the packages without a licence or identifier. The Organization: OpenEmbedded () placeholder does not count as a supplier: set your company in the SBOM settings.

Screenshot SBOM quality of the Wrynose sample workspace

CRA readiness#

Configuration → c (or bitloom --cra, exit code 2 when a check warns) lists:

It also shows the CRA timeline: reporting obligations for actively exploited vulnerabilities and severe incidents (Article 14) apply from 11 September 2026; the essential requirements of Annex I apply from 11 December 2027.

Screenshot CRA readiness for the Wrynose sample

EN 40000#

The CRA harmonised standards are being written by CEN/CENELEC JTC 13 as the EN 40000 series. prEN 40000-1-3 covers vulnerability handling: receipt, assessment, remediation, communication and tracking of vulnerabilities, corresponding to Annex I Part II of the regulation. It is a draft at the time of writing.

Bitloom does not implement or certify the standard. Its compliance features are organised around the evidence such a process needs from the build: a per-build SBOM whose identifiers allow matching, VEX status and CVE analysis per release, dispositions with an owner and an expiry date, change traceability through buildhistory, and reproducibility bundles.

Vulnerabilities#

SBOM-based CVE tools cross the components of an SBOM with vulnerability databases. Artifacts → v (web: the Vulnerabilities panel in SBOM & CRA, CLI: bitloom --vulns) merges their results into one list, one row per CVE and package, the most urgent first:

Each finding shows the severity (from CVSS v4, then v3, then v2), the score, the CVE with its link, the package and version, the status (Unpatched, Patched, Ignored) with the tool's detail (for example version-in-range or not-applicable-config), and the review recorded in Bitloom.

• Filter by source, status (unpatched, all, reviewed), minimum CVSS and text (/).
• r records a review for the selected CVE: owner, reason or evidence reference, and an expiry date (the same dispositions as Developer → Security). A review never marks the upstream vulnerability as fixed.
• g scans the newest SPDX JSON SBOM with Grype (when installed) as a visible job; the list reopens with the results when it finishes. SPDX 2.2 images ship their SBOM as an archive: extract it first.
• x exports the findings shown (same filters) to <state>/exports in the format you choose; the web dashboard has the same Export menu.

Export formats#

From the command line or CI:

bitloom --vulns --format md -o vulnerabilities.md               # unpatched findings
bitloom --vulns --format html --all-statuses -o report.html     # with patched and ignored
bitloom --vulns --format sarif -o bitloom.sarif --min-cvss 7    # then upload with github/codeql-action/upload-sarif

Identifiers link to NVD, CVE.org and OSV for CVEs and to the GitHub advisory database for GHSA identifiers; the tool's own reference link is kept as well.

VulnScout (Savoir-faire Linux) reads the same SPDX SBOMs, cve-check JSON, Yocto VEX and Grype results and adds a web assessment workflow and a CI mode (--match-condition, exit code 2); its meta-vulnscout layer runs it from BitBake.

CRA readiness lists Unpatched vulnerabilities (critical and high count as a warning), and CI can gate on findings:

bitloom --vulns --min-cvss 7 --fail-on-unpatched   # exit 2 when an unpatched finding scores 7.0 or more

Screenshot Vulnerabilities with severity, status and detail

Screenshot Vulnerabilities panel in the web dashboard

do_sbom_cve_check fails with “No such file or directory: …rootfs-.spdx.json”. The image SBOM was reused from an earlier build (sstate or hash equivalence) and carries that build's IMAGE_NAME timestamp, while sbom-cve-check looks for the name of the current run. It happens after a change that rebuilds the root filesystem but not the SBOM. Rebuild the SBOM in the same run: bitbake core-image-minimal -C create_image_sbom_spdx (about three minutes on a warm build). Bitloom's failure diagnosis recognises it (stale SBOM) and gives the command.

Fixing a finding in Yocto: update the recipe or backport the fix with a patch carrying a CVE: CVE-… tag (sbom-cve-check and cve-check mark it Patched), correct the product/version matching with CVE_PRODUCT/CVE_VERSION, or record an assessment with CVE_STATUS[CVE-…] = "reason: explanation".

SBOM settings#

Configuration → s manages SBOM, vulnerability and traceability options. Each option explains what it does, why it matters for the CRA and which releases provide it. Options whose first release is not confirmed are marked ?; press v to verify the variable in your runtime with bitbake-getvar.

Enter/Space toggles or edits, ^O applies. Host and container profiles get one managed block in conf/local.conf (with a timestamped backup); kas profiles get a bitloom-sbom.yml overlay appended to the profile's kas_file, because kas regenerates local.conf. Fragments are enabled or disabled by queueing bitbake-config-build.

Screenshot SBOM settings with explanations and release windows

New operations#

Try it#

bitloom --demo creates demo-scarthgap and demo-wrynose next to the generic demo. Press P to switch: the Wrynose sample has an SPDX 3 SBOM with VEX and an sbom-cve-check report; the Scarthgap sample has an SPDX 2.2 SBOM and a cve-check summary. Every sample file is labelled; nothing claims a real build.

Sources: Yocto security manual: checking for vulnerabilities, VulnScout, Yocto Project 6.0 release notes, Yocto reference manual: classes and variables, Bootlin: sbom-cve-check in Wrynose, EN 40000-1-3 overview.