On Mon, Aug 24, 2026 at 04:38 PM, Quentin Schulz wrote:
Hi Devansh,

On 8/24/26 1:01 PM, Devansh Patel via lists.openembedded.org wrote:
From: Devansh Patel <devanshp@cisco.com>

The current inherited "u-boot-tools" identity has no vulnerability records even
though this recipe builds host utilities from the U-Boot source tree, so
source-aligned CVEs are missed.

Use "u-boot:u-boot" for the CNA affected-data identity and
"denx:u-boot" for the NVD dictionary CPE and configuration identity.
How about using a file that is included by both u-boot-tools and u-boot
so that we don't have to not forget to update both?

u-boot-common.inc is included by both u-boot-tools.bb and u-boot.bb so
that seems like an ideal candidate (if so, then we probably could remove
CVE_PRODUCT from u-boot.inc?)
Hi Quentin,
Thanks, I agree that u-boot-common.inc is the correct location. I will move the mapping there and remove it from u-boot.inc, so both recipes inherit it.
We only have denx:u-boot today in u-boot.inc, how did you come to the
conclusion we also needed u-boot:u-boot?
u-boot:u-boot is not an NVD CPE. It comes from the authoritative CNA affected data for CVE-2026-29007, CVE-2026-29008, and CVE-2026-29009, where VulnCheck uses affected.vendor=u-boot and affected.product=u-boot.

OE-Core master’s sbom-cve-check consumes CVE List V5 affected data directly as well as NVD data. NVD currently also maps those three records to denx:u-boot, so the CNA token adds no exclusive CVEs today. Keeping it nevertheless allows CNA records to be matched while NVD enrichment is pending or absent. I will clarify that distinction in v2.
Cheers,
Quentin
Regards,
Devansh Patel