[PATCH 0/3] sbom-cve-check: Update to version 1.3.0

[PATCH 0/3] sbom-cve-check: Update to version 1.3.0

[Benjamin Robin]

This series update sbom-cve-check to the latest release, and updates its
dependencies:
 - python3-spdx-python-model
 - python3-shacl2code

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
Benjamin Robin (3):
      python3-shacl2code: Update to version 1.0.1
      python3-spdx-python-model: Update to version 0.0.5
      python3-sbom-cve-check: Update to version 1.3.0

 ...2code_0.0.24.bb => python3-shacl2code_1.0.1.bb} |  2 +-
 ...enerate-bindings-allow-to-use-local-files.patch | 58 ----------------------
 ...0.0.4.bb => python3-spdx-python-model_0.0.5.bb} |  3 +-
 ...o-use-correct-type-for-the-version-attrib.patch | 31 ------------
 ...ck_1.2.0.bb => python3-sbom-cve-check_1.3.0.bb} |  4 +-
 5 files changed, 3 insertions(+), 95 deletions(-)
---
base-commit: 9a83f0878b6bacbc7b322cfec076b4e79ad7b8fb
change-id: 20260422-update-sbom-cve-check-and-depends-bb2ccdb86ee2

Best regards,
--  
Benjamin Robin <benjamin.robin@bootlin.com>

[PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Benjamin Robin]

sbom-cve-check version 1.3.0 now requires spdx-python-model 0.0.5
which is built using shacl2code 1.0.1.

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
 .../{python3-shacl2code_0.0.24.bb => python3-shacl2code_1.0.1.bb}       | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb b/meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
similarity index 81%
rename from meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb
rename to meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
index 93ed9a253040..904940926fee 100644
--- a/meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb
+++ b/meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
@@ -5,7 +5,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=0582f358628f299f29c23bf5fb2f73c9"
 
 PYPI_PACKAGE = "shacl2code"
-SRC_URI[sha256sum] = "d8b511054ca564b4514b9186ece7f5eb8048cfc5daa6625def1a3adba13c4f66"
+SRC_URI[sha256sum] = "c856822b40c330452b8b31e94a658ad4595a5ef03cdb75ea432ea9c73d0cf7d9"
 
 inherit pypi python_hatchling
 

-- 
2.53.0

RE: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Marko, Peter]

I have sent ton of new false-positive cleanup commits this weekend.
For many I couldn't find any explanation why they reappeared.
Since there were also new true positives I think this is fine.

But there should be a follow-up investigation for most of my commits to identify why those false-positives appeared and if the tooling can be fixed.

Peter

> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Wednesday, April 22, 2026 5:31 PM
> To: openembedded-core@lists.openembedded.org
> Cc: richard.purdie@linuxfoundation.org; Marko, Peter (FT D EU SK BFS1)
> <Peter.Marko@siemens.com>; ross.burton@arm.com; jpewhacker@gmail.com;
> olivier.benjamin@bootlin.com; antonin.godard@bootlin.com; mathieu.dubois-
> briand@bootlin.com; thomas.petazzoni@bootlin.com; Benjamin Robin
> <benjamin.robin@bootlin.com>
> Subject: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1
> 
> sbom-cve-check version 1.3.0 now requires spdx-python-model 0.0.5
> which is built using shacl2code 1.0.1.
> 
> Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
> ---
>  .../{python3-shacl2code_0.0.24.bb => python3-shacl2code_1.0.1.bb}       | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb
> b/meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
> similarity index 81%
> rename from meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb
> rename to meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
> index 93ed9a253040..904940926fee 100644
> --- a/meta/recipes-devtools/python/python3-shacl2code_0.0.24.bb
> +++ b/meta/recipes-devtools/python/python3-shacl2code_1.0.1.bb
> @@ -5,7 +5,7 @@ LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=0582f358628f299f29c23bf5fb2f73c9"
> 
>  PYPI_PACKAGE = "shacl2code"
> -SRC_URI[sha256sum] =
> "d8b511054ca564b4514b9186ece7f5eb8048cfc5daa6625def1a3adba13c4f66"
> +SRC_URI[sha256sum] =
> "c856822b40c330452b8b31e94a658ad4595a5ef03cdb75ea432ea9c73d0cf7d9"
> 
>  inherit pypi python_hatchling
> 
> 
> --
> 2.53.0

Re: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Benjamin Robin]

Hello Peter,

On Sunday, April 26, 2026 at 9:22 PM, Marko, Peter wrote:
> I have sent ton of new false-positive cleanup commits this weekend.
> For many I couldn't find any explanation why they reappeared.
> Since there were also new true positives I think this is fine.
> 
> But there should be a follow-up investigation for most of my commits to identify why those false-positives appeared and if the tooling can be fixed.
> Peter

The current behavior of sbom-cve-check is documented here:
https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve

I don't think that the tool is not currently working as designed, but maybe
there are wrong entries the product database. Also maybe we could improve
the algorithm to try to reduce the number of false-positives.
The main problem is that the current state of the CVEs databases is not great.
This is really not an easy problem to solve.

Most of the time, the proper solution is going to define CVE_PRODUCT.

If you have a list of CVEs that need to be investigated, could you send it.
This way I could explain or investigate why there is a problem?

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

Re: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Richard Purdie]

On Mon, 2026-04-27 at 09:25 +0200, Benjamin Robin wrote:
> On Sunday, April 26, 2026 at 9:22 PM, Marko, Peter wrote:
> > I have sent ton of new false-positive cleanup commits this weekend.
> > For many I couldn't find any explanation why they reappeared.
> > Since there were also new true positives I think this is fine.
> > 
> > But there should be a follow-up investigation for most of my
> > commits to identify why those false-positives appeared and if the
> > tooling can be fixed.
> > Peter
> 
> The current behavior of sbom-cve-check is documented here:
> https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve
> 
> I don't think that the tool is not currently working as designed, but
> maybe
> there are wrong entries the product database. Also maybe we could
> improve
> the algorithm to try to reduce the number of false-positives.
> The main problem is that the current state of the CVEs databases is
> not great.
> This is really not an easy problem to solve.
> 
> Most of the time, the proper solution is going to define CVE_PRODUCT.
> 
> If you have a list of CVEs that need to be investigated, could you
> send it.
> This way I could explain or investigate why there is a problem?

One idea in the back of my mind is our own "enrichment" data.

Rather than recipe fixes every time, perhaps we start maintaining our
own supplement to the CVE database data?

That might be useful to others, encourage collaboration and perhaps get
the upstream entries ultimately updated?

Cheers,

Richard

Re: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Benjamin Robin]

On Monday, April 27, 2026 at 9:59 AM, Richard Purdie wrote:
> On Mon, 2026-04-27 at 09:25 +0200, Benjamin Robin wrote:
> > On Sunday, April 26, 2026 at 9:22 PM, Marko, Peter wrote:
> > > I have sent ton of new false-positive cleanup commits this weekend.
> > > For many I couldn't find any explanation why they reappeared.
> > > Since there were also new true positives I think this is fine.
> > > 
> > > But there should be a follow-up investigation for most of my
> > > commits to identify why those false-positives appeared and if the
> > > tooling can be fixed.
> > > Peter
> > 
> > The current behavior of sbom-cve-check is documented here:
> > https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve
> > 
> > I don't think that the tool is not currently working as designed, but
> > maybe
> > there are wrong entries the product database. Also maybe we could
> > improve
> > the algorithm to try to reduce the number of false-positives.
> > The main problem is that the current state of the CVEs databases is
> > not great.
> > This is really not an easy problem to solve.
> > 
> > Most of the time, the proper solution is going to define CVE_PRODUCT.
> > 
> > If you have a list of CVEs that need to be investigated, could you
> > send it.
> > This way I could explain or investigate why there is a problem?
> 
> One idea in the back of my mind is our own "enrichment" data.
> 
> Rather than recipe fixes every time, perhaps we start maintaining our
> own supplement to the CVE database data?

I am not sure this is the proper way of doing this.
 
> That might be useful to others, encourage collaboration and perhaps get
> the upstream entries ultimately updated?

The proper way is to contact the CNA which is responsible for the entry.
For example for https://cveawg.mitre.org/api/cve/CVE-2025-9951
The providerMetadata->orgId is 14ed7db2-1595-443d-9d34-6215bf890778, which
is "Google LLC", and the associated contact email is "alphabet-cna@google.com"
(see the CNA database inside sbom-cve-check: look for cna.toml)

But yes it is more work...

> Cheers,
> 
> Richard
> 


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

Re: [PATCH 1/3] python3-shacl2code: Update to version 1.0.1

[Richard Purdie]

On Mon, 2026-04-27 at 10:05 +0200, Benjamin Robin wrote:
> On Monday, April 27, 2026 at 9:59 AM, Richard Purdie wrote:
> > On Mon, 2026-04-27 at 09:25 +0200, Benjamin Robin wrote:
> > > On Sunday, April 26, 2026 at 9:22 PM, Marko, Peter wrote:
> > > > I have sent ton of new false-positive cleanup commits this weekend.
> > > > For many I couldn't find any explanation why they reappeared.
> > > > Since there were also new true positives I think this is fine.
> > > > 
> > > > But there should be a follow-up investigation for most of my
> > > > commits to identify why those false-positives appeared and if the
> > > > tooling can be fixed.
> > > > Peter
> > > 
> > > The current behavior of sbom-cve-check is documented here:
> > > https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve
> > > 
> > > I don't think that the tool is not currently working as designed, but
> > > maybe
> > > there are wrong entries the product database. Also maybe we could
> > > improve
> > > the algorithm to try to reduce the number of false-positives.
> > > The main problem is that the current state of the CVEs databases is
> > > not great.
> > > This is really not an easy problem to solve.
> > > 
> > > Most of the time, the proper solution is going to define CVE_PRODUCT.
> > > 
> > > If you have a list of CVEs that need to be investigated, could you
> > > send it.
> > > This way I could explain or investigate why there is a problem?
> > 
> > One idea in the back of my mind is our own "enrichment" data.
> > 
> > Rather than recipe fixes every time, perhaps we start maintaining our
> > own supplement to the CVE database data?
> 
> I am not sure this is the proper way of doing this.
>  
> > That might be useful to others, encourage collaboration and perhaps get
> > the upstream entries ultimately updated?
> 
> The proper way is to contact the CNA which is responsible for the entry.
> For example for https://cveawg.mitre.org/api/cve/CVE-2025-9951
> The providerMetadata->orgId is 14ed7db2-1595-443d-9d34-6215bf890778, which
> is "Google LLC", and the associated contact email is "alphabet-cna@google.com"
> (see the CNA database inside sbom-cve-check: look for cna.toml)
> 
> But yes it is more work...

I agree contacting the CNA is the right thing to do, however
realistically, some CNAs won't update or respond, so having some amount
of supplemental data is going to be the reality. Our aim would be to
keep it as minimal as possible but I suspect we would struggle to reach
zero based on our past results (which isn't for trying!).

Cheers,

Richard

[PATCH 2/3] python3-spdx-python-model: Update to version 0.0.5

[Benjamin Robin]

sbom-cve-check version 1.3.0 requires spdx-python-model 0.0.5

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
 ...enerate-bindings-allow-to-use-local-files.patch | 58 ----------------------
 ...0.0.4.bb => python3-spdx-python-model_0.0.5.bb} |  3 +-
 2 files changed, 1 insertion(+), 60 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-spdx-python-model/0001-generate-bindings-allow-to-use-local-files.patch b/meta/recipes-devtools/python/python3-spdx-python-model/0001-generate-bindings-allow-to-use-local-files.patch
deleted file mode 100644
index ec24d7beb3c5..000000000000
--- a/meta/recipes-devtools/python/python3-spdx-python-model/0001-generate-bindings-allow-to-use-local-files.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 9fb565a0a70c6985fa1efde13cfe7fb4851588ce Mon Sep 17 00:00:00 2001
-From: Benjamin Robin <benjamin.robin@bootlin.com>
-Date: Tue, 24 Feb 2026 10:59:25 +0100
-Subject: [PATCH] generate-bindings: allow to use local files
-
-shacl2code needs to download the following URLs during build time:
- - https://spdx.org/rdf/3.0.1/spdx-model.ttl
- - https://spdx.org/rdf/3.0.1/spdx-json-serialize-annotations.ttl
- - https://spdx.org/rdf/3.0.1/spdx-context.jsonld
-
-There are a lot of package build tools that do not allow to download
-a file during the build. So provide a way to use local file:
-If the environment variable SHACL2CODE_SPDX_DIR is defined, load
-the SPDX model and SPDX context from the directory specified by this
-environment variable.
-
-Upstream-Status: Submitted [https://github.com/spdx/spdx-python-model/pull/19]
-
-Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
----
- gen/generate-bindings | 22 ++++++++++++++++------
- 1 file changed, 16 insertions(+), 6 deletions(-)
-
-diff --git a/gen/generate-bindings b/gen/generate-bindings
-index b963c55a3bc9..bc7041ee3bb9 100755
---- a/gen/generate-bindings
-+++ b/gen/generate-bindings
-@@ -14,12 +14,22 @@ echo "# Import all versions" > __init__.py
- for v in $SPDX_VERSIONS; do
-     MODNAME="v$(echo "$v" | sed 's/[^a-zA-Z0-9_]/_/g')"
-
--    shacl2code generate --input https://spdx.org/rdf/$v/spdx-model.ttl \
--        --input https://spdx.org/rdf/$v/spdx-json-serialize-annotations.ttl \
--        --context https://spdx.org/rdf/$v/spdx-context.jsonld \
--        --license Apache-2.0 \
--        python \
--        -o "$MODNAME.py"
-+    if [ -n "${SHACL2CODE_SPDX_DIR}" ] && [ -d "${SHACL2CODE_SPDX_DIR}/$v" ]
-+    then
-+        shacl2code generate --input "file://${SHACL2CODE_SPDX_DIR}/$v/spdx-model.ttl" \
-+            --input "file://${SHACL2CODE_SPDX_DIR}/$v/spdx-json-serialize-annotations.ttl" \
-+            --context-url "file://${SHACL2CODE_SPDX_DIR}/$v/spdx-context.jsonld" https://spdx.org/rdf/$v/spdx-context.jsonld  \
-+            --license Apache-2.0 \
-+            python \
-+            -o "$MODNAME.py"
-+    else
-+        shacl2code generate --input https://spdx.org/rdf/$v/spdx-model.ttl \
-+            --input https://spdx.org/rdf/$v/spdx-json-serialize-annotations.ttl \
-+            --context https://spdx.org/rdf/$v/spdx-context.jsonld \
-+            --license Apache-2.0 \
-+            python \
-+            -o "$MODNAME.py"
-+    fi
-
-     echo "from . import $MODNAME" >> __init__.py
- done
---
-2.53.0
diff --git a/meta/recipes-devtools/python/python3-spdx-python-model_0.0.4.bb b/meta/recipes-devtools/python/python3-spdx-python-model_0.0.5.bb
similarity index 89%
rename from meta/recipes-devtools/python/python3-spdx-python-model_0.0.4.bb
rename to meta/recipes-devtools/python/python3-spdx-python-model_0.0.5.bb
index 00c3b3913c2e..c77bdffada9a 100644
--- a/meta/recipes-devtools/python/python3-spdx-python-model_0.0.4.bb
+++ b/meta/recipes-devtools/python/python3-spdx-python-model_0.0.5.bb
@@ -5,13 +5,12 @@ LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
 
 PYPI_PACKAGE = "spdx_python_model"
-SRC_URI[sha256sum] = "bdec725398babcbdd4bcb7c16cf23497d06a48d0ef3ea1edb19a3b0d431ab8c1"
+SRC_URI[sha256sum] = "4bcf7c6e5e2e8f0b787ed4eb8fb519e2ed776e820cb6d9eb93e44e98eb92ca2d"
 
 SRC_URI += " \
     https://spdx.org/rdf/3.0.1/spdx-context.jsonld;name=spdx1 \
     https://spdx.org/rdf/3.0.1/spdx-json-serialize-annotations.ttl;name=spdx2 \
     https://spdx.org/rdf/3.0.1/spdx-model.ttl;name=spdx3 \
-    file://0001-generate-bindings-allow-to-use-local-files.patch \
 "
 
 SRC_URI[spdx1.sha256sum] = "c72b0928f094c83e5c127784edb1ebca2af74a104fcacc007c332b23cbc788bd"

-- 
2.53.0

[PATCH 3/3] python3-sbom-cve-check: Update to version 1.3.0

[Benjamin Robin]

For details on this new release, see:
https://github.com/bootlin/sbom-cve-check/releases/tag/v1.3.0

Signed-off-by: Benjamin Robin <benjamin.robin@bootlin.com>
---
 ...o-use-correct-type-for-the-version-attrib.patch | 31 ----------------------
 ...ck_1.2.0.bb => python3-sbom-cve-check_1.3.0.bb} |  4 +--
 2 files changed, 1 insertion(+), 34 deletions(-)

diff --git a/meta/recipes-devtools/sbom-cve-check/files/0001-export_yocto-use-correct-type-for-the-version-attrib.patch b/meta/recipes-devtools/sbom-cve-check/files/0001-export_yocto-use-correct-type-for-the-version-attrib.patch
deleted file mode 100644
index 392f0b99ea70..000000000000
--- a/meta/recipes-devtools/sbom-cve-check/files/0001-export_yocto-use-correct-type-for-the-version-attrib.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 1a5ae49c520d3569ed12f0c6373b4223d428f92b Mon Sep 17 00:00:00 2001
-From: Ross Burton <ross.burton@arm.com>
-Date: Thu, 9 Apr 2026 11:55:19 +0100
-Subject: [PATCH] export_yocto: use correct type for the version attribute
-
-This should be a string, not an integer:
-
-https://git.openembedded.org/openembedded-core/tree/meta/classes/cve-check.bbclass?h=yocto-5.2.4#n235
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton <ross.burton@arm.com>
----
- src/sbom_cve_check/export/export_yocto.py | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/sbom_cve_check/export/export_yocto.py b/src/sbom_cve_check/export/export_yocto.py
-index c8261f4..78d72c0 100644
---- a/src/sbom_cve_check/export/export_yocto.py
-+++ b/src/sbom_cve_check/export/export_yocto.py
-@@ -172,7 +172,7 @@ class YoctoCveCheckExport(BaseExport):
-         :return: Generator context.
-         """
-         yield
--        json_obj = {"version": 1, "package": self._packages}
-+        json_obj = {"version": "1", "package": self._packages}
-         with self._open_output_as_text() as f:
-             json.dump(json_obj, f, indent=2)
- 
--- 
-2.43.0
-
diff --git a/meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.2.0.bb b/meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.3.0.bb
similarity index 69%
rename from meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.2.0.bb
rename to meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.3.0.bb
index 2a09d8ea4c38..96fc167ecbc3 100644
--- a/meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.2.0.bb
+++ b/meta/recipes-devtools/sbom-cve-check/python3-sbom-cve-check_1.3.0.bb
@@ -5,9 +5,7 @@ LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=570a9b3749dd0463a1778803b12a6dce"
 
 PYPI_PACKAGE = "sbom_cve_check"
-SRC_URI[sha256sum] = "0b01474c541fb4b9d29d36f86fae6d0f27ff2b991fcb59b2fbeb70c1eaa09664"
-
-SRC_URI += "file://0001-export_yocto-use-correct-type-for-the-version-attrib.patch"
+SRC_URI[sha256sum] = "dad6f9df848f6dd7b69922baef0ec187b66ad0847fe0cf62614529e27203e842"
 
 inherit pypi python_hatchling
 

-- 
2.53.0