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.
Best regards,
Devansh Patel