Hello Het,

Thanks for explaining your use-case.
However this change in current form is wrong because it removes existing 
(although a bit old) CVEs from Yocto reports.
And reporting all existing CVEs for a component is currently an integral part 
of the reports.
From my perspective, your change looks like “just report CVEs from 2012 
onwards” which I think we also don’t want to take.

If you would like to change the current behavior of “replicating NVD DB”, that 
should be discussed and implemented globally, not in a single recipe.
I could image some variable which would (if configured) take only single 
vendor:product namespace or map all namespaces into this “current” one.

(adding Joshua and Marta to the discussion for spdx/vex discussions)

Best Regards,
  Peter

From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]>
Sent: Friday, February 27, 2026 13:52
To: Marko, Peter (FT D EU SK BFS1) <[email protected]>; 
[email protected]
Cc: xe-linux-external(mailer list) <[email protected]>; Viral Chavda 
(vchavda) <[email protected]>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to 
exclude false positives

Hello Peter,

I agree that historical CVEs must remain resolvable in SPDX/VEX. However, the 
issue we are trying to address is different. The core concern is the scope and 
signal-to-noise ratio. If we include all historical NVD CPE vendor namespaces 
for util-linux in active reporting - including legacy aliases such as 
`util-linux_project` - we effectively introduce deprecated namespaces and CVEs 
that apply only to very old source trees. In practice, this can result in 
hundreds of CPE/version combinations, many tied to code that has been removed 
or heavily refactored, which significantly increases developer triage effort.

From a reporting perspective, this adds noise, increases review overhead, and 
raises the maintenance burden within CI and security pipelines. There is an 
important distinction between archival completeness(essentially replicating the 
full NVD dataset) and operational relevance(what actually applies to the 
current codebase used in Yocto builds). Publishing the entire NVD surface area 
for util-linux risks turning our report into a mirror of NVD rather than a 
focused and actionable vulnerability assessment.

We are mindful of the versions actually in use. Many CVEs under 
`andries_brouwer` or the legacy `linux` vendor namespace relate to releases 
from 2005–2011, while the Yocto build integrates specific, maintained versions 
of util-linux. Automatically including all historical vendor namespaces can 
lead to unnecessary VEX justifications and additional developer workload 
without materially improving the security posture. Because NVD contains 
deprecated CPEs, aliases, and historical vendor transitions, treating them all 
equally in operational reporting can inflate results, require review of 
irrelevant legacy CVEs, and ultimately reduce signal quality.

Please feel free to share your perspective.

Thanks & Regards,
Het.
________________________________
From: Marko, Peter <[email protected]<mailto:[email protected]>>
Sent: Friday, February 27, 2026 2:40 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
 
<[email protected]<mailto:[email protected]>>
Cc: xe-linux-external(mailer list) 
<[email protected]<mailto:[email protected]>>; Viral Chavda 
(vchavda) <[email protected]<mailto:[email protected]>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to 
exclude false positives


Hello,



It is important that all historical entries are kept known to Yocto build 
system.

Otherwise spdx/vex will not indicate the historical CVEs as resolved.



Therefore this change is incorrect.

Alternatively you could limit it to the 4 historical vendor strings, but not 
limiting it to only the current vendor string.



Peter



From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]<mailto:[email protected]>>
Sent: Friday, February 27, 2026 10:05
To: Marko, Peter (FT D EU SK BFS1) 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Cc: xe-linux-external(mailer list) 
<[email protected]<mailto:[email protected]>>; Viral Chavda 
(vchavda) <[email protected]<mailto:[email protected]>>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to 
exclude false positives



Hi,



A review was conducted of the database entries, upstream sources, and the 
associated CVE records for util-linux. Below is a detailed analysis and the 
corresponding rationale.



Observations:

  *   There are four vendor names associated with the util‑linux product: 
andries_brouwer, linux, util-linux_project, and kernel.

  *   `andries_brouwer:util-linux` and `linux:util-linux` are legacy entries 
from older CVEs (pre-2012).

  *   `util-linux_project` represents a transitional vendor namespace, now 
largely deprecated.



Upstream Source Mapping:

  *   The current upstream source code repositories found from README are:

     *   GitHub: https://github.com/util-linux/util-linux.git

     *   Kernel.org: 
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

  *   CVEs from 2018–2024 referencing util-linux use the CPE vendor `kernel`:

        "cpe:2.3:a:kernel:util-linux"

  *   Legacy CVEs (e.g., CVE-2008-1926, CVE-2011-1675/1676/1677) sometimes 
reference `linux:util-linux` or `andries_brouwer:util-linux`, but these are 
historical and correspond to older releases no longer maintained.



Conclusion:

  *   All entries are “correct” in the sense that they exist in historical 
CVE/CPE mappings.

  *   However, only `kernel:util-linux` corresponds to the current upstream 
project and is used in **active CVE tracking** today.



False Positive Analysis:

  1.  The proposed change aligns CVE mapping with the official upstream project.

  1.  It ensures that CVEs from modern releases are correctly linked to the 
live repository.

  1.  It maintains historical records in the database for reference, but 
prevents them from being misattributed to “current” upstream versions.



Key point:

  *   There are no false positives being removed and historical entries 
(`linux:util-linux`, `andries_brouwer:util-linux`) remain in the database for 
archival purposes.



Commit message will be updated accordingly.



Regards.

Het

________________________________

From: Marko, Peter <[email protected]<mailto:[email protected]>>
Sent: Thursday, February 26, 2026 6:47 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
 
<[email protected]<mailto:[email protected]>>
Cc: xe-linux-external(mailer list) 
<[email protected]<mailto:[email protected]>>; Viral Chavda 
(vchavda) <[email protected]<mailto:[email protected]>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to 
exclude false positives




> -----Original Message-----
> From: 
> [email protected]<mailto:[email protected]>
>  <openembedded-
> [email protected]<mailto:[email protected]>> On Behalf Of 
> Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: 
> [email protected]<mailto:[email protected]>
> Cc: [email protected]<mailto:[email protected]>; 
> [email protected]<mailto:[email protected]>
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
>
> From: Het Patel <[email protected]<mailto:[email protected]>>
>
> - Added the vendor to CVE_PRODUCT to prevent false positives.
>
> Signed-off-by: Het Patel <[email protected]<mailto:[email protected]>>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc 
> b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
>
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
>
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like 
'%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#232186): 
https://lists.openembedded.org/g/openembedded-core/message/232186
Mute This Topic: https://lists.openembedded.org/mt/118011172/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to