| Message ID | 20260422-update-sbom-cve-check-and-depends-v1-1-4646f840ce48@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | sbom-cve-check: Update to version 1.3.0 | expand |
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
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,
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
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 >
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
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
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(-)