[OE-core][PATCH] binutils: correct CVE_PRODUCT mapping

[OE-core][PATCH] binutils: correct CVE_PRODUCT mapping

[Devansh Patel -X (devanshp - E INFOCHIPS PRIVATE LIMITED at Cisco)]

From: Devansh Patel <devanshp@cisco.com>

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 <devanshp@cisco.com>
---
 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"
+
 # perl-native for pod2man for man page generation
 DEPENDS += "zlib perl-native"
 
-- 
2.35.6

Re: [OE-core][PATCH] binutils: correct CVE_PRODUCT mapping

[Paul Barker]

On Mon, 2026-08-24 at 04:01 -0700, Devansh Patel -X (devanshp - E
INFOCHIPS PRIVATE LIMITED at Cisco) wrote:
> From: Devansh Patel <devanshp@cisco.com>
> 
> 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 <devanshp@cisco.com>
> ---
>  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?

Best regards,

-- 
Paul Barker

Re: [PATCH] binutils: correct CVE_PRODUCT mapping

[Devansh Patel]

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

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 <devanshp@cisco.com>
>> 
>> 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 <devanshp@cisco.com>
>> ---
>> 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?
> 
> Best regards,
> 
> --
> Paul Barker

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

Best regards,
Devansh Patel

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

Re: [PATCH] binutils: correct CVE_PRODUCT mapping

[Paul Barker]

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 <devanshp@cisco.com>
> > > 
> > > 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 <devanshp@cisco.com>
> > > ---
> > > 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

Re: [PATCH] binutils: correct CVE_PRODUCT mapping

[Devansh Patel]

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

On Thu, Aug 27, 2026 at 07:54 PM, Paul Barker wrote:

> 
> 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

Hi Paul,

Thank you for the clarification.

We are reviewing the proposed CVE_PRODUCT changes internally at Cisco, particularly
the relationship between CVE matching, CPE identities in SPDX output, and the
sbom-cve-check workflow.

The main question is whether a vendor-qualified mapping is appropriate when it improves
the component identity in the SBOM but does not change the reported CVEs, and how existing
product aliases should be retained where they are necessary for complete CVE coverage.

We will ask our Cisco representative to raise this broader topic to the openembedded community
with more details. In the meantime, we will pause further CVE_PRODUCT submissions
that are intended to improve SBOM identity.

We will continue proposing mappings where the default value demonstrably misses relevant CVEs
or produces unrelated matches, with the specific CVE-reporting impact documented in the commit message.

Best regards,
Devansh

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