On Thu, 2026-08-27 at 05:47 -0700, Devansh Patel wrote: > On Wed, Aug 26, 2026 at 02:32 PM, Paul Barker wrote: > > > > > On Mon, 2026-08-24 at 04:01 -0700, Devansh Patel -X (devanshp - E > > INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > > > > > From: Devansh Patel <[email protected]> > > > > > > The current "binutils" mapping generates a vendor-wildcard product > > > identity for the packaged GNU Binutils source. > > > > > > Use "gnu:binutils", which matches the active NVD dictionary CPE, NVD > > > configuration criteria, and CNA affected data for the Sourceware project. > > > > > > This changes the generated identity from > > > cpe:2.3:*:*:binutils:2.47:*:*:*:*:*:*:* to > > > cpe:2.3:*:gnu:binutils:2.47:*:*:*:*:*:*:*, but sbom-cve-check 1.3.3 > > > with the frozen 2026-08-10 databases has no current CVE report delta. > > > > > > Signed-off-by: Devansh Patel <[email protected]> > > > --- > > > meta/recipes-devtools/binutils/binutils_2.47.bb | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/meta/recipes-devtools/binutils/binutils_2.47.bb > > > b/meta/recipes-devtools/binutils/binutils_2.47.bb > > > index 79bcac2025..798d886614 100644 > > > --- a/meta/recipes-devtools/binutils/binutils_2.47.bb > > > +++ b/meta/recipes-devtools/binutils/binutils_2.47.bb > > > @@ -1,6 +1,8 @@ > > > require binutils.inc > > > require binutils-${PV}.inc > > > > > > +CVE_PRODUCT = "gnu:binutils" > > > > Hi, > > > > We have a default CVE_PRODUCT value so that we don't have to manually > > maintain mappings in every recipe. Per-recipe CVE_PRODUCT assignments > > are useful when the default mapping either misses CVEs or matches > > unrelated CVEs. > > > > In this case you say there is no CVE report delta between having this > > CVE_PRODUCT assignment and not having it - so is there any reason it is > > needed? > > Hi Paul, > > Thanks for the feedback. I wanted to clarify the broader intention > behind these CVE_PRODUCT updates, as there are two related use cases > we are trying to address. > > CVE_PRODUCT is used for both CVE report generation and for deriving > the CPE identity exposed in the SPDX SBOM. The default ${BPN}-based > mapping can be sufficient for CVE matching when the recipe and NVD > product names already align, which is why in some of these patches > there is no immediate CVE report delta. > > However, from the SBOM perspective, product-name-only matching can > still leave the vendor unspecified. Since this CPE identity is exposed > in the SPDX 2.3/3.0 output and consumed by downstream security > tooling, we want the SBOM to carry an explicit and accurate upstream > component identity rather than relying on an implicit vendor-wildcard > mapping. > > The "no CVE report delta" in these patches was therefore intended as a > regression check, not as the motivation for the change: it confirms > that making the identity more specific does not lose currently > reported CVEs. > > This is also an evolution of the earlier discussion around CVE_PRODUCT > [1]. Initially, the focus was on cases where the recipe name did not > correspond to the vulnerability product name and explicit mappings > were needed to avoid missed CVEs. We are continuing that same work but > also covering the second consumer of this metadata: the SBOM. In older > flows such as Scarthgap, CVE reporting and SPDX generation are > separate consumers of the recipe metadata. In Wrynose, cve-check has > been replaced by sbom-cve-check, where the generated SPDX itself is > used as input to the CVE analysis. So, maintaining an accurate > component identity in the SBOM is increasingly part of the CVE > reporting path itself. > > So, the overall goal is to keep CVE_PRODUCT accurate for both > purposes: complete CVE correlation and an unambiguous vendor/product > identity in the generated SPDX SBOM, while preserving any aliases > required for valid CVE coverage. > > [1] https://lists.openembedded.org/g/openembedded-core/topic/118935618
Hi Devansh, The commit messages for these changes make no mention of the SBOM output. Commit messages need to explain *why* a change is proposed. So from the patches you sent I could only infer that this was solely about CVE matching accuracy. CVE_PRODUCT assignments have so far been used when the default leads to either CVEs being missed, or unrelated CVEs being matched. We haven't carried CVE_PRODUCT assignments purely for SBOM accuracy. I don't really have the context to understand if this is required or not - I think we need some discussion and input from others here. Could you send an email to the openembedded-architecture list to discuss the need for additional CVE_PRODUCT assignments before sending further patches like this? Best regards, -- Paul Barker
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#244494): https://lists.openembedded.org/g/openembedded-core/message/244494 Mute This Topic: https://lists.openembedded.org/mt/120901042/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
