[RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[stondo]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Hi all,

Back at the end of December 2025, I had a conversation with Adrian
regarding OpenVEX. Following my SPDX 3.0 enhancement series that was
merged recently [1], I would like to propose adding OpenVEX [2]
standalone document generation to the SPDX 3.0 workflow.


Context: current VEX landscape in oe-core
-----------------------------------------

Yocto currently has three VEX-related mechanisms:

1. SPDX embedded VEX (Joshua's recipe-level architecture in
   create-spdx-3.0): VEX assessment relationships embedded inside SPDX
   3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the richest
   VEX data source, now at recipe level after the package VEX
   removal [3].

2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex task
   that produces per-recipe JSON files and a rootfs manifest in a custom
   Yocto JSON format. Used for CVE reporting and consumed by external
   analysis tools.

3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build CVE
   analysis using an external tool that reads SPDX SBOMs + vex.bbclass
   manifests, then re-exports enriched SPDX 3 data.

What is currently missing is output in the OpenVEX format (openvex.dev),
which is a lightweight, interoperable JSON format adopted by an
increasing number of vulnerability management tools.


Motivation
----------

The OpenVEX specification [2] is gaining adoption as the standard VEX
transport format. Several widely-used tools already consume OpenVEX
natively:

  - Grype (Anchore):       grype --vex openvex.json
  - Trivy (Aqua Security): trivy image --vex openvex.json
  - cosign/sigstore:       VEX attestation support

Having standalone OpenVEX files alongside SPDX SBOMs would enable:

  - Direct integration with the scanning tools listed above
  - Separate distribution of VEX data without shipping the full SBOM
  - Compliance with EU Cyber Resilience Act and US Executive Order 14028
    requirements for machine-readable vulnerability assessments
  - Decoupled VEX lifecycle: documents can be updated independently
    when vulnerability status changes

This implementation does NOT replace or conflict with the existing VEX
mechanisms. It is an additional optional output format that reuses the
VEX data already produced by Joshua's recipe-level SPDX architecture.


Implementation
--------------

The approach hooks into the existing create-spdx-3.0 workflow. When a
recipe has CVE data, the implementation reads the VEX assessment
relationships already present in the SPDX output and generates a
standalone .vex.json file in OpenVEX format alongside the SPDX
document. The SPDX VEX statuses (patched, unpatched, ignored, unknown)
are mapped to their OpenVEX equivalents, and product identification
uses PURLs from the SPDX packages. The feature is disabled by default
and opt-in via a single configuration variable.

The series is two patches (generation logic + selftests), both included
below for anyone who wants to look at the details.


Open questions
--------------

1. Should the OpenVEX document ID scheme use a different namespace
   than https://openvex.dev/docs/yocto/ ?

2. Is the SSTATE_ALLOW_OVERLAP_FILES += "${DEPLOY_DIR_SPDX}" approach
   acceptable for VEX file sharing between recipe and package sstate
   tasks?

Looking forward to your feedback.

[1] https://lists.openembedded.org/g/openembedded-core/message/213367
[2] https://openvex.dev/
[3] commit 6406240932 ("spdx30: Remove package VEX")
[4] https://patchwork.openembedded.org/project/oe-core/list/?series=&submitter=&state=&q=sbom-cve-check&archive=&delegate=

Stefano Tondo (2):
  spdx30: Add OpenVEX standalone document generation
  oeqa/selftest: Add tests for OpenVEX integration

 meta/classes/create-spdx-3.0.bbclass |  19 +++
 meta/classes/spdx-common.bbclass     |  15 +++
 meta/lib/oe/spdx30_tasks.py          | 193 +++++++++++++++++++++++++++
 meta/lib/oeqa/selftest/cases/spdx.py |  90 +++++++++++++
 4 files changed, 317 insertions(+)

-- 
2.53.0

[RFC PATCH 1/2] spdx30: Add OpenVEX standalone document generation

[stondo]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Add OpenVEX document generation integrated into the SPDX 3.0 recipe-level
workflow. When enabled, standalone .vex.json files are generated alongside
SPDX documents for each recipe with CVE data.

Key changes:
- Add generate_openvex_from_spdx() and helper functions to spdx30_tasks.py
  that create OpenVEX documents from SPDX VEX assessment relationships
- Map SPDX VEX status to OpenVEX status (Patched->fixed, Unpatched->affected,
  Ignored->not_affected, Unknown->under_investigation)
- Extract product PURLs from SPDX packages with proper fallback chain
- Add VEX sstate copy in create_package_spdx() for sstate restore survival
- Add OPENVEX_GENERATE_STANDALONE, OPENVEX_AUTHOR, OPENVEX_ROLE variables
  to create-spdx-3.0.bbclass (default disabled)
- Add SSTATE_ALLOW_OVERLAP_FILES for DEPLOY_DIR_SPDX
- Document OpenVEX variables in spdx-common.bbclass

This implementation is designed to work with Joshua Watt's recipe-level
SPDX architecture where VEX data is created in create_recipe_spdx() with
the recipe_objset and 4-tuple cve_by_status format.

Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
---
 meta/classes/create-spdx-3.0.bbclass |  19 +++
 meta/classes/spdx-common.bbclass     |  15 +++
 meta/lib/oe/spdx30_tasks.py          | 193 +++++++++++++++++++++++++++
 3 files changed, 227 insertions(+)

diff --git a/meta/classes/create-spdx-3.0.bbclass b/meta/classes/create-spdx-3.0.bbclass
index 432adb14cd..0519f87c41 100644
--- a/meta/classes/create-spdx-3.0.bbclass
+++ b/meta/classes/create-spdx-3.0.bbclass
@@ -45,6 +45,17 @@ SPDX_INCLUDE_VEX[doc] = "Controls what VEX information is in the output. Set to
     including those already fixed upstream (warning: This can be large and \
     slow)."
 
+OPENVEX_GENERATE_STANDALONE ??= "0"
+OPENVEX_GENERATE_STANDALONE[doc] = "Controls whether standalone OpenVEX .vex.json \
+    files are generated alongside SPDX documents. Set to '1' to enable. VEX data \
+    remains embedded in SPDX when SPDX_INCLUDE_VEX is not 'none' regardless."
+
+OPENVEX_AUTHOR ??= "Yocto Build System"
+OPENVEX_AUTHOR[doc] = "Author name for generated OpenVEX documents."
+
+OPENVEX_ROLE ??= "Build System"
+OPENVEX_ROLE[doc] = "Author role for generated OpenVEX documents."
+
 SPDX_INCLUDE_TIMESTAMPS ?= "0"
 SPDX_INCLUDE_TIMESTAMPS[doc] = "Include time stamps in SPDX output. This is \
     useful if you want to know when artifacts were produced and when builds \
@@ -186,6 +197,9 @@ SPDX3_VAR_DEPS = "\
     SPDX_PROFILES \
     SPDX_NAMESPACE_PREFIX \
     SPDX_UUID_NAMESPACE \
+    OPENVEX_GENERATE_STANDALONE \
+    OPENVEX_AUTHOR \
+    OPENVEX_ROLE \
     "
 
 python do_create_recipe_spdx() {
@@ -223,6 +237,11 @@ SSTATETASKS += "do_create_spdx"
 do_create_spdx[sstate-inputdirs] = "${SPDXDEPLOY}"
 do_create_spdx[sstate-outputdirs] = "${DEPLOY_DIR_SPDX}"
 do_create_spdx[file-checksums] += "${SPDX3_DEP_FILES}"
+
+# Allow VEX files to overlap between create_recipe_spdx and
+# create_package_spdx sstate. VEX is generated during create_recipe_spdx
+# and copied to create_package_spdx sstate to ensure it survives restore.
+SSTATE_ALLOW_OVERLAP_FILES += "${DEPLOY_DIR_SPDX}"
 do_create_spdx[deptask] += "do_create_spdx"
 do_create_spdx[dirs] = "${SPDXWORK}"
 do_create_spdx[cleandirs] = "${SPDXDEPLOY} ${SPDXWORK}"
diff --git a/meta/classes/spdx-common.bbclass b/meta/classes/spdx-common.bbclass
index 40701730a6..c2960f04d2 100644
--- a/meta/classes/spdx-common.bbclass
+++ b/meta/classes/spdx-common.bbclass
@@ -82,6 +82,21 @@ SPDX_MULTILIB_SSTATE_ARCHS[doc] = "The list of sstate architectures to consider
     when collecting SPDX dependencies. This includes multilib architectures when \
     multilib is enabled. Defaults to SSTATE_ARCHS."
 
+OPENVEX_GENERATE_STANDALONE[doc] = "Controls whether standalone OpenVEX .vex.json \
+    files are generated in addition to VEX data embedded in SPDX documents. Set to \
+    '1' to enable standalone file generation. VEX data remains embedded in SPDX when \
+    SPDX_INCLUDE_VEX is not 'none' regardless of this setting. \
+    Default: '0' (disabled). Defined in create-spdx-3.0.bbclass."
+
+OPENVEX_AUTHOR[doc] = "Author name for generated OpenVEX documents. Identifies \
+    the person or organization that created the VEX document. \
+    Default: 'Yocto Build System'. Defined in create-spdx-3.0.bbclass."
+
+OPENVEX_ROLE[doc] = "Author role for generated OpenVEX documents. Describes the \
+    capacity in which the author is creating the VEX document (e.g., 'Build System', \
+    'Security Team', 'Maintainer'). Default: 'Build System'. \
+    Defined in create-spdx-3.0.bbclass."
+
 SPDX_FILE_EXCLUDE_PATTERNS ??= ""
 SPDX_FILE_EXCLUDE_PATTERNS[doc] = "Space-separated list of Python regular \
     expressions to exclude files from SPDX output. Files whose paths match \
diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
index cd9672c18e..ba9bef3105 100644
--- a/meta/lib/oe/spdx30_tasks.py
+++ b/meta/lib/oe/spdx30_tasks.py
@@ -790,9 +790,188 @@ def create_recipe_spdx(d):
             sorted(list(all_cves)),
         )
 
+    # Generate standalone OpenVEX document from recipe VEX data
+    generate_openvex_from_spdx(d, recipe_objset, deploydir, cve_by_status)
+
     oe.sbom30.write_recipe_jsonld_doc(d, recipe_objset, "static", deploydir)
 
 
+def generate_openvex_from_spdx(d, objset, deploydir, cve_by_status=None):
+    """
+    Generate OpenVEX document from SPDX 3.0.1 in-memory data structure.
+
+    Called from create_recipe_spdx() where CVE/VEX data originates,
+    leveraging the cve_by_status dict for accurate status mapping.
+    """
+    import json
+    import hashlib
+    from datetime import datetime, timezone
+
+    generate_standalone = d.getVar("OPENVEX_GENERATE_STANDALONE")
+    if generate_standalone != "1":
+        return
+
+    include_vex = d.getVar("SPDX_INCLUDE_VEX")
+    if include_vex == "none":
+        return
+
+    statements = []
+
+    if cve_by_status:
+        # Use cve_by_status dict directly (preferred path)
+        for status_key, cves in cve_by_status.items():
+            for cve_id, items in cves.items():
+                spdx_cve, detail, description, resources = items
+
+                statement = _make_vex_statement(d, objset, cve_id, status_key,
+                                                detail, description)
+                if statement:
+                    statements.append(statement)
+    else:
+        # Fallback: extract from VEX assessment relationships in objset
+        for obj in objset.foreach_type(oe.spdx30.security_Vulnerability):
+            cve_id = _get_cve_id(obj)
+            status, detail, description = _get_vex_status_from_relationships(
+                objset, obj
+            )
+            statement = _make_vex_statement(d, objset, cve_id, status,
+                                            detail, description)
+            if statement:
+                statements.append(statement)
+
+    if not statements:
+        bb.debug(1, "No vulnerabilities found in %s, skipping OpenVEX" % d.getVar("PN"))
+        return
+
+    author = d.getVar("OPENVEX_AUTHOR") or "Yocto Build System"
+    role = d.getVar("OPENVEX_ROLE") or "Build System"
+
+    statements_json = json.dumps(statements, sort_keys=True)
+    doc_id = hashlib.sha256(statements_json.encode()).hexdigest()[:16]
+
+    openvex_doc = {
+        "@context": "https://openvex.dev/ns/v0.2.0",
+        "@id": "https://openvex.dev/docs/yocto/vex-%s" % doc_id,
+        "author": author,
+        "role": role,
+        "timestamp": datetime.now(timezone.utc).isoformat().replace("+00:00", "Z"),
+        "version": 1,
+        "statements": statements,
+    }
+
+    # Write VEX to sstate staging area (deploydir) so it is included in
+    # the do_create_recipe_spdx sstate output and survives sstate restore.
+    pkg_arch = d.getVar("SSTATE_PKGARCH")
+    pkg_name = d.getVar("PN")
+    openvex_file = deploydir / pkg_arch / "recipes" / ("%s.vex.json" % pkg_name)
+
+    openvex_file.parent.mkdir(parents=True, exist_ok=True)
+
+    try:
+        with open(openvex_file, "w") as f:
+            json.dump(openvex_doc, f, indent=2)
+        bb.debug(1, "Created OpenVEX document: %s (%d statements)" % (
+            openvex_file, len(statements)))
+    except Exception as e:
+        bb.warn("Failed to write OpenVEX file %s: %s" % (openvex_file, e))
+
+
+def _get_cve_id(vuln_obj):
+    """Extract CVE ID from vulnerability external identifiers."""
+    for ext_id in vuln_obj.externalIdentifier:
+        if ext_id.identifier and ext_id.identifier.startswith("CVE-"):
+            return ext_id.identifier
+    return "Unknown"
+
+
+def _get_vex_status_from_relationships(objset, vuln_obj):
+    """Extract VEX status from SPDX assessment relationships (fallback path)."""
+    vuln_link = oe.sbom30.get_element_link_id(vuln_obj)
+
+    for rel in objset.foreach_type(oe.spdx30.security_VexVulnAssessmentRelationship):
+        if vuln_link in rel.to or vuln_link in rel.from_:
+            if rel.relationshipType == oe.spdx30.RelationshipType.fixedIn:
+                return "Patched", None, None
+            elif rel.relationshipType == oe.spdx30.RelationshipType.affects:
+                return "Unpatched", None, None
+            elif rel.relationshipType == oe.spdx30.RelationshipType.doesNotAffect:
+                desc = getattr(rel, "security_impactStatement", None)
+                return "Ignored", None, desc
+
+    return "Unknown", None, None
+
+
+def _make_vex_statement(d, objset, cve_id, status_key, detail, description):
+    """Create an OpenVEX statement dict from CVE status information."""
+    products = _extract_products(d, objset)
+
+    status_map = {
+        "Patched": "fixed",
+        "Unpatched": "affected",
+        "Ignored": "not_affected",
+        "Unknown": "under_investigation",
+    }
+    status = status_map.get(status_key, "affected")
+
+    statement = {
+        "vulnerability": {"name": cve_id},
+        "products": products,
+        "status": status,
+    }
+
+    if status == "fixed" and detail:
+        statement["status_notes"] = "Patched: %s" % detail
+
+    if status == "affected" and detail:
+        statement["status_notes"] = "Unpatched: %s" % detail
+        statement["action_statement"] = (
+            "This vulnerability is not yet patched. Consider updating "
+            "to a newer version or applying a backport patch."
+        )
+
+    if status == "not_affected":
+        statement["justification"] = "vulnerable_code_not_in_execute_path"
+        if description:
+            statement["impact_statement"] = description
+
+    if status == "under_investigation":
+        statement["status_notes"] = "CVE status is unknown or under investigation"
+
+    return statement
+
+
+def _extract_products(d, objset):
+    """Extract product identifiers (PURLs) from SPDX objset."""
+    products = []
+
+    for pkg in objset.foreach_type(oe.spdx30.software_Package):
+        if hasattr(pkg, "software_packageUrl") and pkg.software_packageUrl:
+            products.append({"@id": pkg.software_packageUrl})
+            continue
+
+        for ext_id in pkg.externalIdentifier:
+            if (
+                ext_id.externalIdentifierType
+                == oe.spdx30.ExternalIdentifierType.packageUrl
+            ):
+                products.append({"@id": ext_id.identifier})
+                break
+
+    # Fallback: generate PURL from recipe metadata
+    if not products:
+        recipe_purl = oe.purl.get_base_purl(d)
+        if recipe_purl:
+            products.append({"@id": "%s?type=source" % recipe_purl})
+        else:
+            doc_id = oe.sbom30.get_element_link_id(objset.doc)
+            if doc_id:
+                products.append({"@id": doc_id})
+            else:
+                products.append({"@id": "urn:spdx:unknown"})
+
+    return products
+
+
 def load_recipe_spdx(d):
 
     return oe.sbom30.find_root_obj_in_jsonld(
@@ -1133,6 +1312,20 @@ def create_package_spdx(d):
     providers = oe.spdx_common.collect_package_providers(d, direct_deps)
     pkg_arch = d.getVar("SSTATE_PKGARCH")
 
+    # Copy VEX file from create_recipe_spdx deploy output to
+    # create_package_spdx sstate input as a secondary capture path.
+    # The primary path is via create_recipe_spdx sstate, but this
+    # ensures VEX files are also available if create_package_spdx
+    # sstate is restored independently.
+    import shutil
+    pn = d.getVar("PN")
+    vex_src = deploy_dir_spdx / pkg_arch / "recipes" / ("%s.vex.json" % pn)
+    if vex_src.exists():
+        vex_dest = deploydir / pkg_arch / "recipes" / ("%s.vex.json" % pn)
+        vex_dest.parent.mkdir(parents=True, exist_ok=True)
+        shutil.copy2(str(vex_src), str(vex_dest))
+        bb.debug(1, "Copied VEX file to sstate: %s" % vex_dest)
+
     if get_is_native(d):
         return
 
-- 
2.53.0

[RFC PATCH 2/2] oeqa/selftest: Add tests for OpenVEX integration

[stondo]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Add two test methods to SPDX30Check:
- test_openvex_integration: Verifies VEX relationships exist in SPDX
  output and packages have PURLs for VEX product identification
- test_openvex_standalone_files: Verifies standalone .vex.json files
  are created with proper metadata when OPENVEX_GENERATE_STANDALONE=1

Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
---
 meta/lib/oeqa/selftest/cases/spdx.py | 90 ++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/spdx.py b/meta/lib/oeqa/selftest/cases/spdx.py
index 8285189382..661daa17d8 100644
--- a/meta/lib/oeqa/selftest/cases/spdx.py
+++ b/meta/lib/oeqa/selftest/cases/spdx.py
@@ -443,3 +443,93 @@ class SPDX30Check(SPDX3CheckBase, OESelftestTestCase):
                 r'\d',
                 f"Version '{version}' for package '{name}' should contain digits"
             )
+
+    def test_openvex_integration(self):
+        """
+        Test that OpenVEX generation is integrated into SPDX workflow.
+
+        Verifies VEX relationships are created for vulnerabilities and
+        packages have PURLs suitable for VEX product identification.
+        """
+        objset = self.check_recipe_spdx(
+            "busybox",
+            "{DEPLOY_DIR_SPDX}/{SSTATE_PKGARCH}/static/static-busybox.spdx.json",
+            task="create_recipe_spdx",
+            extraconf="""                OPENVEX_AUTHOR = "Test Author"
+                OPENVEX_ROLE = "securityAdvisor"
+                """,
+        )
+
+        # Check for VEX relationships (any type: Fixed, Affected, NotAffected, etc.)
+        vex_count = 0
+        for rel in objset.foreach_type(oe.spdx30.security_VexVulnAssessmentRelationship):
+            vex_count += 1
+            self.assertIsNotNone(rel.from_, "VEX relationship missing 'from' field")
+            self.assertIsNotNone(rel.to, "VEX relationship missing 'to' field")
+
+        if vex_count:
+            self.logger.info(f"Found {vex_count} VEX relationships in SPDX")
+        else:
+            self.logger.info("No VEX relationships found (expected if no CVEs)")
+
+        # Verify packages have PURLs for VEX product identification
+        packages_with_purls = []
+        for pkg in objset.foreach_type(oe.spdx30.software_Package):
+            if hasattr(pkg, "externalIdentifier") and pkg.externalIdentifier:
+                for ext_id in pkg.externalIdentifier:
+                    if hasattr(ext_id, "externalIdentifierType"):
+                        if "packageurl" in str(ext_id.externalIdentifierType).lower():
+                            packages_with_purls.append(pkg.name)
+                            break
+
+        self.assertGreater(
+            len(packages_with_purls), 0,
+            "Should have packages with PURLs for VEX product identification"
+        )
+        self.logger.info(f"Found {len(packages_with_purls)} packages with PURLs")
+
+    def test_openvex_standalone_files(self):
+        """
+        Test that standalone OpenVEX files are generated when enabled.
+
+        Verifies OpenVEX JSON files are created with required metadata
+        for a recipe with known CVEs (busybox).
+        """
+        import json
+        from pathlib import Path
+
+        self.check_recipe_spdx(
+            "busybox",
+            "{DEPLOY_DIR_SPDX}/{SSTATE_PKGARCH}/static/static-busybox.spdx.json",
+            task="create_recipe_spdx",
+            extraconf="""                OPENVEX_GENERATE_STANDALONE = "1"
+                OPENVEX_AUTHOR = "Test Security Team"
+                OPENVEX_ROLE = "securityAdvisor"
+                """,
+        )
+
+        deploy_dir_spdx = get_bb_var("DEPLOY_DIR_SPDX")
+        sstate_pkgarch = get_bb_var("SSTATE_PKGARCH", "busybox")
+
+        vex_file = Path(deploy_dir_spdx) / sstate_pkgarch / "recipes" / "busybox.vex.json"
+
+        self.assertExists(str(vex_file), "busybox.vex.json should exist (busybox has known CVEs)")
+
+        with open(vex_file, "r") as f:
+            vex_data = json.load(f)
+
+        self.assertIn("@context", vex_data, "VEX missing @context")
+        self.assertIn("statements", vex_data, "VEX missing statements")
+        self.assertGreater(len(vex_data["statements"]), 0, "VEX should have at least one statement")
+
+        self.assertEqual(
+            vex_data["author"],
+            "Test Security Team",
+            "VEX author not set correctly"
+        )
+
+        self.logger.info(
+            f"Validated OpenVEX file: busybox.vex.json "
+            f"({len(vex_data['statements'])} statements)"
+        )
+
-- 
2.53.0

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Richard Purdie]

On Tue, 2026-03-31 at 16:19 +0200, stondo@gmail.com wrote:
> Back at the end of December 2025, I had a conversation with Adrian
> regarding OpenVEX. Following my SPDX 3.0 enhancement series that was
> merged recently [1], I would like to propose adding OpenVEX [2]
> standalone document generation to the SPDX 3.0 workflow.
> 
> 
> Context: current VEX landscape in oe-core
> -----------------------------------------
> 
> Yocto currently has three VEX-related mechanisms:
> 
> 1. SPDX embedded VEX (Joshua's recipe-level architecture in
>    create-spdx-3.0): VEX assessment relationships embedded inside SPDX
>    3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the richest
>    VEX data source, now at recipe level after the package VEX
>    removal [3].
> 
> 2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex task
>    that produces per-recipe JSON files and a rootfs manifest in a custom
>    Yocto JSON format. Used for CVE reporting and consumed by external
>    analysis tools.
> 
> 3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build CVE
>    analysis using an external tool that reads SPDX SBOMs + vex.bbclass
>    manifests, then re-exports enriched SPDX 3 data.
> 
> What is currently missing is output in the OpenVEX format (openvex.dev),
> which is a lightweight, interoperable JSON format adopted by an
> increasing number of vulnerability management tools.

vex.bbclass is about to be removed, which simplifies things a bit.

Is there any reason we can't have an external script which extracts the
vex data from the spdx?

My personal view is that it might better to support various
conversion/extraction tools rather than trying to output all the
formats someone might want directly...

Cheers,

Richard

Re: [OE-core] [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Marta Rybczynska]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

On Tue, Mar 31, 2026 at 4:23 PM Richard Purdie via lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:

> On Tue, 2026-03-31 at 16:19 +0200, stondo@gmail.com wrote:
> > Back at the end of December 2025, I had a conversation with Adrian
> > regarding OpenVEX. Following my SPDX 3.0 enhancement series that was
> > merged recently [1], I would like to propose adding OpenVEX [2]
> > standalone document generation to the SPDX 3.0 workflow.
> >
> >
> > Context: current VEX landscape in oe-core
> > -----------------------------------------
> >
> > Yocto currently has three VEX-related mechanisms:
> >
> > 1. SPDX embedded VEX (Joshua's recipe-level architecture in
> >    create-spdx-3.0): VEX assessment relationships embedded inside SPDX
> >    3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the richest
> >    VEX data source, now at recipe level after the package VEX
> >    removal [3].
> >
> > 2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex task
> >    that produces per-recipe JSON files and a rootfs manifest in a custom
> >    Yocto JSON format. Used for CVE reporting and consumed by external
> >    analysis tools.
> >
> > 3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build CVE
> >    analysis using an external tool that reads SPDX SBOMs + vex.bbclass
> >    manifests, then re-exports enriched SPDX 3 data.
> >
> > What is currently missing is output in the OpenVEX format (openvex.dev),
> > which is a lightweight, interoperable JSON format adopted by an
> > increasing number of vulnerability management tools.
>
> vex.bbclass is about to be removed, which simplifies things a bit.
>
> Is there any reason we can't have an external script which extracts the
> vex data from the spdx?
>
> My personal view is that it might better to support various
> conversion/extraction tools rather than trying to output all the
> formats someone might want directly...
>
>
Useful VEX information includes vendor context (eg. checked that the
vulnerability
is not reachable under normal usage conditions). We do not have a framework
to
do so today. Necessarily, such VEX output will need to be manually edited by
vendors before publication.

Because of that, I agree with Richard that a standalone tool that extracts
the annotation
from SPDX and allows users to modify/add annotations is a better solution.

Kind regards,
Marta

[-- Attachment #2: Type: text/html, Size: 3283 bytes --]

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Joshua Watt]

On Tue, Mar 31, 2026 at 8:23 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2026-03-31 at 16:19 +0200, stondo@gmail.com wrote:
> > Back at the end of December 2025, I had a conversation with Adrian
> > regarding OpenVEX. Following my SPDX 3.0 enhancement series that was
> > merged recently [1], I would like to propose adding OpenVEX [2]
> > standalone document generation to the SPDX 3.0 workflow.
> >
> >
> > Context: current VEX landscape in oe-core
> > -----------------------------------------
> >
> > Yocto currently has three VEX-related mechanisms:
> >
> > 1. SPDX embedded VEX (Joshua's recipe-level architecture in
> >    create-spdx-3.0): VEX assessment relationships embedded inside SPDX
> >    3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the richest
> >    VEX data source, now at recipe level after the package VEX
> >    removal [3].
> >
> > 2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex task
> >    that produces per-recipe JSON files and a rootfs manifest in a custom
> >    Yocto JSON format. Used for CVE reporting and consumed by external
> >    analysis tools.
> >
> > 3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build CVE
> >    analysis using an external tool that reads SPDX SBOMs + vex.bbclass
> >    manifests, then re-exports enriched SPDX 3 data.
> >
> > What is currently missing is output in the OpenVEX format (openvex.dev),
> > which is a lightweight, interoperable JSON format adopted by an
> > increasing number of vulnerability management tools.
>
> vex.bbclass is about to be removed, which simplifies things a bit.
>
> Is there any reason we can't have an external script which extracts the
> vex data from the spdx?
>
> My personal view is that it might better to support various
> conversion/extraction tools rather than trying to output all the
> formats someone might want directly...

Agreed. I already prototyped this here:
https://github.com/JPEWdev/spdx3toopenvex feel free to use it as a
reference for how to do the conversion from SPDX 3 -> OpenVEX


>
> Cheers,
>
> Richard
>

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Freihofer, Adrian]

On Tue, 2026-03-31 at 09:04 -0600, Joshua Watt wrote:
> On Tue, Mar 31, 2026 at 8:23 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Tue, 2026-03-31 at 16:19 +0200, stondo@gmail.com wrote:
> > > Back at the end of December 2025, I had a conversation with
> > > Adrian
> > > regarding OpenVEX. Following my SPDX 3.0 enhancement series that
> > > was
> > > merged recently [1], I would like to propose adding OpenVEX [2]
> > > standalone document generation to the SPDX 3.0 workflow.
> > > 
> > > 
> > > Context: current VEX landscape in oe-core
> > > -----------------------------------------
> > > 
> > > Yocto currently has three VEX-related mechanisms:
> > > 
> > > 1. SPDX embedded VEX (Joshua's recipe-level architecture in
> > >    create-spdx-3.0): VEX assessment relationships embedded inside
> > > SPDX
> > >    3.0 documents, controlled by SPDX_INCLUDE_VEX. This is the
> > > richest
> > >    VEX data source, now at recipe level after the package VEX
> > >    removal [3].
> > > 
> > > 2. vex.bbclass (Marta Rybczynska): A standalone do_generate_vex
> > > task
> > >    that produces per-recipe JSON files and a rootfs manifest in a
> > > custom
> > >    Yocto JSON format. Used for CVE reporting and consumed by
> > > external
> > >    analysis tools.
> > > 
> > > 3. sbom-cve-check (Benjamin Robin, under review [4]): Post-build
> > > CVE
> > >    analysis using an external tool that reads SPDX SBOMs +
> > > vex.bbclass
> > >    manifests, then re-exports enriched SPDX 3 data.
> > > 
> > > What is currently missing is output in the OpenVEX format
> > > (openvex.dev),
> > > which is a lightweight, interoperable JSON format adopted by an
> > > increasing number of vulnerability management tools.
> > 
> > vex.bbclass is about to be removed, which simplifies things a bit.
> > 
> > Is there any reason we can't have an external script which extracts
> > the
> > vex data from the spdx?
> > 
> > My personal view is that it might better to support various
> > conversion/extraction tools rather than trying to output all the
> > formats someone might want directly...
> 
> Agreed. I already prototyped this here:
> https://github.com/JPEWdev/spdx3toopenvex
>  feel free to use it as a
> reference for how to do the conversion from SPDX 3 -> OpenVEX
> 

I agree that generating the SBOM and then processing it with
independent, specialized tools is the right approach — and I believe
that was also what I proposed, based on Ross's post in that earlier
discussion.

Taking this further, though, raises an interesting question: how could
CVEs discovered after the SBOM/VEX was built with Bitbake be handled in
a more automated way?

A tool with access to the latest CVE database, an XL SBOM, and the
corresponding source and debug packages could likely mark many CVEs as
not_affected automatically — for instance, because certain source files
are not compiled, or a relevant #ifdef is disabled.

Would it make sense to extend sbom-cve-check to support exporting an
OpenVEX document covering all CVEs at the time of execution? Such a
tool would need to:

 * Download the CVE database
 * Extract static CVE status information from the SPDX document
 * Attempt to automatically evaluate the status of CVEs found in the
   database but not mentioned in the static SPDX

This essentially describes merging Joshua's tool with Benjamin's sbom-
cve-check into a unified tool that can ingest SPDX data, NIST
information, source files, and more — and produce various outputs such
as CVE check graphs, summary tables, and VEX documents in multiple
variants.

It's also worth asking how Yocto-specific such a tool would actually
need to be. It could potentially be generic enough to support various
Linux distributions — which leads to the question: does something like
this already exist?

Regards,
Adrian

> 
> > 
> > Cheers,
> > 
> > Richard
> > 

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Benjamin Robin]

Hello,

On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote:
> I agree that generating the SBOM and then processing it with
> independent, specialized tools is the right approach — and I believe
> that was also what I proposed, based on Ross's post in that earlier
> discussion.
> 
> Taking this further, though, raises an interesting question: how could
> CVEs discovered after the SBOM/VEX was built with Bitbake be handled in
> a more automated way?

I’m not sure I fully understand the question. This is exactly the purpose
of `sbom-cve-check`. It can be executed automatically from Yocto
post-build, or at any time later outside of Yocto.

> A tool with access to the latest CVE database, an XL SBOM, and the
> corresponding source and debug packages could likely mark many CVEs as
> not_affected automatically — for instance, because certain source files
> are not compiled, or a relevant #ifdef is disabled.

`sbom-cve-check` is designed to do precisely this, or at least that is
the goal. However, supporting `#ifdef` is not planned in the short term;
filtering is currently done by filename.
Unfortunately, not many CVE entries contain the information needed to
automatically mark them as not affected. Only the kernel typically has
this information properly filled in.

> Would it make sense to extend sbom-cve-check to support exporting an
> OpenVEX document covering all CVEs at the time of execution? Such a
> tool would need to:
> 
>  * Download the CVE database
>  * Extract static CVE status information from the SPDX document
>  * Attempt to automatically evaluate the status of CVEs found in the
>    database but not mentioned in the static SPDX

I’m not sure I follow what you mean, this is exactly what
`sbom-cve-check` is already trying to do. It can generate OpenVEX files.
Perhaps not everything is perfect yet (far from it), and some parts may
still need improvement.

> This essentially describes merging Joshua's tool with Benjamin's sbom-
> cve-check into a unified tool that can ingest SPDX data, NIST
> information, source files, and more — and produce various outputs such
> as CVE check graphs, summary tables, and VEX documents in multiple
> variants.

`sbom-cve-check` can generate multiple export formats and can be extended
to support additional formats.

> It's also worth asking how Yocto-specific such a tool would actually
> need to be. It could potentially be generic enough to support various
> Linux distributions — which leads to the question: does something like
> this already exist?

The goal of `sbom-cve-check` is not to be tied to Yocto. As long as you
can provide an SBOM in a supported format, `sbom-cve-check` should work.
That said, there is still a lot of development needed to fully achieve
this goal.

> 
> Regards,
> Adrian

Best regards,
-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Freihofer, Adrian]

On Wed, 2026-04-01 at 09:43 +0200, Benjamin Robin wrote:
> [You don't often get email from benjamin.robin@bootlin.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello,
> 
> On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote:
> > I agree that generating the SBOM and then processing it with
> > independent, specialized tools is the right approach — and I
> > believe
> > that was also what I proposed, based on Ross's post in that earlier
> > discussion.
> > 
> > Taking this further, though, raises an interesting question: how
> > could
> > CVEs discovered after the SBOM/VEX was built with Bitbake be
> > handled in
> > a more automated way?
> 
> I’m not sure I fully understand the question. This is exactly the
> purpose
> of `sbom-cve-check`. It can be executed automatically from Yocto
> post-build, or at any time later outside of Yocto.

I was not aware that sbom-cve-check can export the CVE status as
OpenVEX. If so, this question is obsolete and sbom-cve-check already
does what I'm proposing. :-)

> 
> > A tool with access to the latest CVE database, an XL SBOM, and the
> > corresponding source and debug packages could likely mark many CVEs
> > as
> > not_affected automatically — for instance, because certain source
> > files
> > are not compiled, or a relevant #ifdef is disabled.
> 
> `sbom-cve-check` is designed to do precisely this, or at least that
> is
> the goal. However, supporting `#ifdef` is not planned in the short
> term;
> filtering is currently done by filename.
> Unfortunately, not many CVE entries contain the information needed to
> automatically mark them as not affected. Only the kernel typically
> has
> this information properly filled in.

That sounds already very good. The kernel is by far the most relevant
part which should be supported by this feature.
Let's hope that other projects start adding the source lines to their
CVEs in the future. Then it will become even more valuable.

> 
> > Would it make sense to extend sbom-cve-check to support exporting
> > an
> > OpenVEX document covering all CVEs at the time of execution? Such a
> > tool would need to:
> > 
> >  * Download the CVE database
> >  * Extract static CVE status information from the SPDX document
> >  * Attempt to automatically evaluate the status of CVEs found in
> > the
> >    database but not mentioned in the static SPDX
> 
> I’m not sure I follow what you mean, this is exactly what
> `sbom-cve-check` is already trying to do. It can generate OpenVEX
> files.
> Perhaps not everything is perfect yet (far from it), and some parts
> may
> still need improvement.

Having an initial version which defines this new architecture would
already be a very big step! Thank you for driving this.

> 
> > This essentially describes merging Joshua's tool with Benjamin's
> > sbom-
> > cve-check into a unified tool that can ingest SPDX data, NIST
> > information, source files, and more — and produce various outputs
> > such
> > as CVE check graphs, summary tables, and VEX documents in multiple
> > variants.
> 
> `sbom-cve-check` can generate multiple export formats and can be
> extended
> to support additional formats.

That leads then to the question about the purpose of the tool from
Joshua. If I understand correctly it does something like e.g.
  sbom-cve-check --do-not-use-cve-db-just-filter-sbom
could do, right? The code used for that would probably already be in
the sbom-cve-check and probably have 99% overlap with the code from
Joshua's tool.

I'm just guessing and trying to understand where we could help.

Thank you,
Adrian

> 
> > It's also worth asking how Yocto-specific such a tool would
> > actually
> > need to be. It could potentially be generic enough to support
> > various
> > Linux distributions — which leads to the question: does something
> > like
> > this already exist?
> 
> The goal of `sbom-cve-check` is not to be tied to Yocto. As long as
> you
> can provide an SBOM in a supported format, `sbom-cve-check` should
> work.
> That said, there is still a lot of development needed to fully
> achieve
> this goal.
> 
> > 
> > Regards,
> > Adrian
> 
> Best regards,
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> 

Re: [RFC PATCH 0/2] spdx30: Add OpenVEX standalone document generation

[Benjamin Robin]

On Wednesday, April 1, 2026 at 11:58 AM, Freihofer, Adrian wrote:
> On Wed, 2026-04-01 at 09:43 +0200, Benjamin Robin wrote:
> > [You don't often get email from benjamin.robin@bootlin.com. Learn why
> > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > Hello,
> > 
> > On Wednesday, April 1, 2026 at 12:05 AM, Freihofer, Adrian wrote:
> > > I agree that generating the SBOM and then processing it with
> > > independent, specialized tools is the right approach — and I
> > > believe
> > > that was also what I proposed, based on Ross's post in that earlier
> > > discussion.
> > > 
> > > Taking this further, though, raises an interesting question: how
> > > could
> > > CVEs discovered after the SBOM/VEX was built with Bitbake be
> > > handled in
> > > a more automated way?
> > 
> > I’m not sure I fully understand the question. This is exactly the
> > purpose
> > of `sbom-cve-check`. It can be executed automatically from Yocto
> > post-build, or at any time later outside of Yocto.
> 
> I was not aware that sbom-cve-check can export the CVE status as
> OpenVEX. If so, this question is obsolete and sbom-cve-check already
> does what I'm proposing. :-)

Hum, sorry. I have no idea why I said that sbom-cve-check can export
to OpenVEX. It can take has input (as annotation) an OpenVEX file.
But currently there is no export to OpenVEX

> > > A tool with access to the latest CVE database, an XL SBOM, and the
> > > corresponding source and debug packages could likely mark many CVEs
> > > as
> > > not_affected automatically — for instance, because certain source
> > > files
> > > are not compiled, or a relevant #ifdef is disabled.
> > 
> > `sbom-cve-check` is designed to do precisely this, or at least that
> > is
> > the goal. However, supporting `#ifdef` is not planned in the short
> > term;
> > filtering is currently done by filename.
> > Unfortunately, not many CVE entries contain the information needed to
> > automatically mark them as not affected. Only the kernel typically
> > has
> > this information properly filled in.
> 
> That sounds already very good. The kernel is by far the most relevant
> part which should be supported by this feature.
> Let's hope that other projects start adding the source lines to their
> CVEs in the future. Then it will become even more valuable.
> 
> > 
> > > Would it make sense to extend sbom-cve-check to support exporting
> > > an
> > > OpenVEX document covering all CVEs at the time of execution? Such a
> > > tool would need to:
> > > 
> > >  * Download the CVE database
> > >  * Extract static CVE status information from the SPDX document
> > >  * Attempt to automatically evaluate the status of CVEs found in
> > > the
> > >    database but not mentioned in the static SPDX
> > 
> > I’m not sure I follow what you mean, this is exactly what
> > `sbom-cve-check` is already trying to do. It can generate OpenVEX
> > files.
> > Perhaps not everything is perfect yet (far from it), and some parts
> > may
> > still need improvement.

Sorry see answer above. It cannot generate for now OpenVEX file.

> Having an initial version which defines this new architecture would
> already be a very big step! Thank you for driving this.
> 
> > 
> > > This essentially describes merging Joshua's tool with Benjamin's
> > > sbom-
> > > cve-check into a unified tool that can ingest SPDX data, NIST
> > > information, source files, and more — and produce various outputs
> > > such
> > > as CVE check graphs, summary tables, and VEX documents in multiple
> > > variants.
> > 
> > `sbom-cve-check` can generate multiple export formats and can be
> > extended
> > to support additional formats.
> 
> That leads then to the question about the purpose of the tool from
> Joshua. If I understand correctly it does something like e.g.
>   sbom-cve-check --do-not-use-cve-db-just-filter-sbom
> could do, right? The code used for that would probably already be in
> the sbom-cve-check and probably have 99% overlap with the code from
> Joshua's tool.

The command would be something like that:

sbom-cve-check --ignore-default-config --sbom sbom.spdx.json \
 --export-path openvex.json --export-type openvex

But again there is no openvex export-type (Yet)

> I'm just guessing and trying to understand where we could help.
> 
> Thank you,
> Adrian
> 
> > 
> > > It's also worth asking how Yocto-specific such a tool would
> > > actually
> > > need to be. It could potentially be generic enough to support
> > > various
> > > Linux distributions — which leads to the question: does something
> > > like
> > > this already exist?
> > 
> > The goal of `sbom-cve-check` is not to be tied to Yocto. As long as
> > you
> > can provide an SBOM in a supported format, `sbom-cve-check` should
> > work.
> > That said, there is still a lot of development needed to fully
> > achieve
> > this goal.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com