[master] apt: Add CVE_PRODUCT to support product name

From: Himanshu Jadon <hjadon@cisco.com>

- NVD contains older debian:apt CPEs, but they are deprecated and
  explicitly replaced by debian:advanced_package_tool, so the recipe
  should use the active normalized product identity.
- Therefore, set CVE_PRODUCT to align with the NVD CPE and ensure
  correct CVE reporting.

Signed-off-by: Himanshu Jadon <hjadon@cisco.com>
---
 meta/recipes-devtools/apt/apt_3.0.3.bb | 3 +++
 1 file changed, 3 insertions(+)

On Tue, 2026-04-21 at 04:10 -0700, Himanshu Jadon -X (hjadon - E
INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote:
> From: Himanshu Jadon <hjadon@cisco.com>
> 
> - NVD contains older debian:apt CPEs, but they are deprecated and
>   explicitly replaced by debian:advanced_package_tool, so the recipe
>   should use the active normalized product identity.
> - Therefore, set CVE_PRODUCT to align with the NVD CPE and ensure
>   correct CVE reporting.
> 
> Signed-off-by: Himanshu Jadon <hjadon@cisco.com>
> ---
>  meta/recipes-devtools/apt/apt_3.0.3.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-devtools/apt/apt_3.0.3.bb b/meta/recipes-devtools/apt/apt_3.0.3.bb
> index d2dfe48e9a..871564baea 100644
> --- a/meta/recipes-devtools/apt/apt_3.0.3.bb
> +++ b/meta/recipes-devtools/apt/apt_3.0.3.bb
> @@ -148,3 +148,6 @@ do_install:append() {
>  	# Avoid non-reproducible -src package
>  	sed -i -e "s,${B}/include/,,g" ${B}/apt-pkg/tagfile-keys.cc
>  }
> +
> +# Add CVE_PRODUCT to match the NVD CPE product name
> +CVE_PRODUCT = "debian:advanced_package_tool"

CVE-2020-3810 [1] appears to have CPE "debian:apt" but not
"debian:advanced_package_tool", so I don't think we should exclude the
older CPE here.

[1]: https://nvd.nist.gov/vuln/detail/CVE-2020-3810

What is the goal of this patch and other patches from Cisco which set
CVE_PRODUCT? In most cases there don't seem to be any false positives
that you're trying to resolve, so I'm still unsure why CVE_PRODUCT needs
to be set in so many recipes.

Best regards,

Hi Paul,

Thanks for raising this point.

The main intention of these patches is to improve CVE correlation in cases where the recipe name does not match the active NVD product identity properly, or where NVD has moved from an older/deprecated product string to a newer normalized one. In such situations, depending only on default recipe-name-based matching can lead to missed CVEs.

We have already added CVE_PRODUCT internally for multiple packages and have seen better reporting because of that, which also helps improve the overall security view. For example:
- abseil-cpp -> abseil:common_libraries, which results in reporting of CVE-2025-0838 with CVSS v3 9.8
- onig -> oniguruma_project:oniguruma, where the current DB contains multiple CVEs with CVSS v3 9.8 such as CVE-2017-9224 and CVE-2019-1901
- apr -> apache:portable_runtime, where the current DB contains CVE-2022-2496 and CVE-2022-2833, both CVSS v3 9.8

This also helps in the longer term by making SBOM-to-CVE correlation more reliable and by reducing dependency on implicit recipe-name matching when the upstream NVD product naming differs.

So the purpose here is not only metadata cleanup, and not only false-positive handling. The main goal is to make the mapping explicit wherever it improves correctness, avoids missed CVEs, and gives better security reporting.

Regarding deprecated CPEs, I agree that they should not be removed blindly. If a deprecated CPE still carries CVEs that are relevant for the recipe version being considered, then it makes sense to keep that older alias along with the newer active one.

In the specific apt case, the older debian:apt alias is deprecated, and the CVEs currently associated with that alias do not apply to apt_3.0.3. So in this case the deprecated alias is not adding relevant coverage for the current recipe version, whereas debian:advanced_package_tool is the active NVD product identity. Because of that, this patch uses the new identity instead of carrying the deprecated one unnecessarily.

Additionally, whenever we come across cases where the NVD CPE naming or mapping itself looks inconsistent or incorrect, we are also informing NVD separately so that the source data can be corrected there as well. So these recipe-side CVE_PRODUCT updates are for improving present correlation, while the underlying CPE/data-quality issues should ideally be corrected upstream in NVD.

I also think there is scope to improve the cve-check class itself so that it can report when a deprecated CPE is being used in a recipe. That would make such cases more visible and help maintain the mappings more cleanly.

Best regards,
Himanshu

On Tue, 2026-04-21 at 07:04 -0700, Himanshu Jadon -X (hjadon - E
INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote:
> Hi Paul,
> 
> Thanks for raising this point.
> 
> The main intention of these patches is to improve CVE correlation in cases where the recipe name does not match the active NVD product identity properly, or where NVD has moved from an older/deprecated product string to a newer normalized one. In such situations, depending only on default recipe-name-based matching can lead to missed CVEs.
> 
> We have already added CVE_PRODUCT internally for multiple packages and have seen better reporting because of that, which also helps improve the overall security view. For example:
> - abseil-cpp -> abseil:common_libraries, which results in reporting of CVE-2025-0838 with CVSS v3 9.8
> - onig -> oniguruma_project:oniguruma, where the current DB contains multiple CVEs with CVSS v3 9.8 such as CVE-2017-9224 and CVE-2019-1901
> - apr -> apache:portable_runtime, where the current DB contains CVE-2022-2496 and CVE-2022-2833, both CVSS v3 9.8
> 
> This also helps in the longer term by making SBOM-to-CVE correlation more reliable and by reducing dependency on implicit recipe-name matching when the upstream NVD product naming differs.
> 
> So the purpose here is not only metadata cleanup, and not only false-positive handling. The main goal is to make the mapping explicit wherever it improves correctness, avoids missed CVEs, and gives better security reporting.
> 
> Regarding deprecated CPEs, I agree that they should not be removed blindly. If a deprecated CPE still carries CVEs that are relevant for the recipe version being considered, then it makes sense to keep that older alias along with the newer active one.
> 
> In the specific apt case, the older debian:apt alias is deprecated, and the CVEs currently associated with that alias do not apply to apt_3.0.3. So in this case the deprecated alias is not adding relevant coverage for the current recipe version, whereas debian:advanced_package_tool is the active NVD product identity. Because of that, this patch uses the new identity instead of carrying the deprecated one unnecessarily.
> 
> Additionally, whenever we come across cases where the NVD CPE naming or mapping itself looks inconsistent or incorrect, we are also informing NVD separately so that the source data can be corrected there as well. So these recipe-side CVE_PRODUCT updates are for improving present correlation, while the underlying CPE/data-quality issues should ideally be corrected upstream in NVD.
> 
> I also think there is scope to improve the cve-check class itself so that it can report when a deprecated CPE is being used in a recipe. That would make such cases more visible and help maintain the mappings more cleanly.
> 
> Best regards,
> Himanshu

Hi Himanshu,

I've discussed this with Richard and Ross. We should keep the older CPE
in the list, both for completeness and because future CVEs may be filed
using the older CPE by mistake.

So, we should set:

    CVE_PRODUCT = "debian:apt debian:advanced_package_tool"

Also, please quote the email you're replying to in future (as I have
done here) so that the conversation is easier to follow.

Best regards,