Re: [master] [PATCH] apt: Add CVE_PRODUCT to support product name

["Himanshu Jadon -X (hjadon - E INFOCHIPS PRIVATE LIMITED at Cisco)" <hjadon@cisco.com>]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3008 bytes --]