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?
>
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#244485):
https://lists.openembedded.org/g/openembedded-core/message/244485
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]]
-=-=-=-=-=-=-=-=-=-=-=-
