---
title: "SBOM and CVEs"
---

# SBOM and CVEs

The image's SPDX 2.2 or 3.0 SBOM read from the build and exported byte for byte, and cve-check reports with scores, the layer line that decides each CVE, CVE_STATUS written with a documented reason, and two releases compared.

Regulated releases need the image's SBOM and a reasoned status for every CVE. Both come from the build itself (`INHERIT += "create-spdx cve-check"`); the CVE data is the build's own NVD database, and the editor downloads nothing.

**State:** modelled with real cve-check output of two releases (poky scarthgap, BitBake 2.8.1, NVD records from a local mirror); a CVE_STATUS line written by the module and read back as Patched by a real `bitbake -c cve_check`; an SPDX 2.2 archive read through zstd and GNU tar and exported unchanged; SPDX 2.2, 3.0 and meta-wr-sbom files written with OE-Core's serializers; the running app against a stand-in build host. Not run on a real image's SBOM, on Wind River LTS 24 and 25 output, against a real build server, on Windows, or with the kirkstone SPDX 2.2 fallback. VEX as its own file is not read.

## The SBOM

**Open SBOM** picks the image's SBOM on the build host: SPDX 2.2 (create-spdx's `.spdx.tar.zst`, or Wind River's meta-wr-sbom) or SPDX 3.0. The **SBOM** editor shows:

- the counts of packages installed in the image, recipes, licence identifiers and documents;
- each package with version, licence, recipe, sources, CVEs fixed and runtime dependencies, and in detail its declared and concluded licence, supplier, homepage, CPE and purl, files, VEX and the SPDX document;
- search by package, version, licence, recipe, CPE or purl, and **Licences of the image**.

**Export the SBOM as the Build Wrote It** saves the file byte for byte and reports its SHA-256 on the build host, for the release record.

## CVE triage

**Open CVE Report** picks a cve-check report: the image report, an `sbom-cve-check` export or a run's summary. The **CVE Triage** editor shows:

- counts of unpatched, ignored and patched CVEs, with critical, high, medium and low;
- each CVE with status, recipe, version, the CVSS v2, v3.x and v4.0 score and vector, attack vector, the reason, and the layer file and line that decides it (a `CVE_STATUS` line or a CVE patch), with the summary;
- filters by status and score.

## Record a decision

1. On a CVE choose **Add CVE Status...**.
2. Pick the reason from the list OpenEmbedded-Core's `cve-check-map.conf` documents (for example `not-applicable-config`, `backported-patch`, `cpe-incorrect`), each with how it is reported.
3. Pick the product layer. The confirmation shows the bbappend file and the exact line.

Run `bitbake -c cve_check <recipe>` again on the build host to see the CVE reported with your reason.

## Compare releases

In the CVE editor, **Compare with an Earlier Build** opens the earlier release's report; **Export CVE Comparison** writes it as Markdown or CSV.

## Agent tools

Four read-only tools (SBOMs and reports of the build, an SBOM's packages, CVEs with where they are decided, two builds compared) and one write, a CVE status, always confirmed with the file and line.

Next: [Licence compliance](https://neuralinverse.com/docs/modules/embedded-linux/licences/).