Re: [wrynose][RFC PATCH 00/11] sbom-cve-check update

[Benjamin Robin <benjamin.robin@bootlin.com>]

On Friday, August 14, 2026 at 12:05 AM, Marko, Peter wrote:

> > On Thursday, August 13, 2026 at 1:46 PM, Paul Barker wrote:
> > > On Sat, 2026-08-08 at 12:51 +0200, Peter Marko wrote:
> > > > This series updates sbom-cve-check tooling in wrynose to current master.
> > > > Unfortunately it shows that having cve-check tooling in upstream
> > > > components violates LTS patch acceptance policies.
> > > >
> > > > In this case the most visible is python3-shacl2code (1.0.1 -> 1.1.0),
> > > > but also sbom-cve-check-update-nvd-native introduces new features
> > > > (which is actually the reason why this upgrade is wanted).
> > > > For now this should not be a big issue as all the dependencies are very
> > > > new and used exclusively in cve-check, however by time they may be used
> > > > in other recipes or tooling, too.
> > > >
> > > > So I am sending this series as RFC to discuss future of CVE checking on
> > > > LTS branches.
> > > > * should we go with this series as is (possibly updating policy text)?
> > > > * or are we stuck with old code for next 3.5 years?
> > > > * or separate the tooling to meta-sbom-cve-check which would only have
> > > >   master branch to service all currently supported releases?
> > > > * or create mixins layer (to be also used by AB cve-metrics jobs)?
> > > > * or are there some other suggestions how to rework this series?
> > > >
> > > > My preference would be to have cve-check aligned for all supported
> > > > releases (even scarthgap), so I would welcome opinions and discussion
> > > > on this topic.
> > 
> > Hello Peter,
> > 
> > Thank you for taking the time to create this series. I had been planning
> > to work on it, but I was a bit busy :)
> > 
> > >
> > > Hi Peter,
> > >
> > > The TSC has discussed this series and is happy for sbom-cve-check to be
> > > updated on wrynose. It's in line with the expectations we had when
> > > wrynose was released, and the upstream maintainer is involved.
> > >
> > > For scarthgap it's a different question. That still has the
> > > cve-check.bbclass implementation instead of sbom-cve-check, this would
> > > be whole new framework rather than a set of updates. I wonder if this
> > > can be handled via an LTS mixin layer instead of a backport in OE-core?
> 
> Paul,
> 
> as the meta-sbom-cve-check layer shows, sbom-cve-check can co-exist with the old cve-check.
> It does not have to be the super-invasive with breaking change.
> 
> So in theory it should be pretty easy to copy 3 classes and bunch of support recipes.
> But I'm also fine with having an external layer for that.
> 
> Question is if Yocto project would also switch cve-metrics to the sbom-cve-check.
> That would of course highly increase the open CVE numbers but would also help identify missing CVE fixes.
> 
> > 
> > Hello Paul,
> > 
> > Technically, I think we could backport sbom-cve-check to scarthgap, but
> > indeed it still has the cve-check.bbclass implementation.
> > 
> > sbom-cve-check can be run outside of Yocto, but if you want it integrated
> > into Yocto, there's already a layer for that:
> > https://github.com/bootlin/meta-sbom-cve-check
> 
> Benjamin,
> 
> This is super cool.
> However, cve-metrics uses sbom-cve-check-recipe, which is not part of this layer.
> When updating, please consider adding it.
> 
> Peter

Peter,

I will be on vacation, so I won’t have time to work on this.
Feel free to create a PR to add this feature. I don't know if it's possible
to simply add `sbom-cve-check-recipe` to Scarthgap—I haven't checked yet—but
I have some slight doubts about it (though I could be completely wrong).


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