Discrepancy in the Common Vulnerabilities and Exposures (CVEs) associated with OpenSSL versions 1.1.1n-0+deb11u4

[soufianejhioui]

Hello,

I am reaching out to you regarding a discrepancy I noticed regarding the Common Vulnerabilities and Exposures (CVEs) associated with OpenSSL versions 1.1.1n-0+deb11u4 and 1.1.1n-0+deb11u5.

According to the Debian Security Advisory DSA-5417, it is stated that all the detected CVEs have been addressed in either openssl 1.1.1n-0+deb11u4 or 1.1.1n-0+deb11u5. However, when I cross-referenced this information with Dependency-Track, it still lists these CVEs for openssl 1.1.1n-0+deb11u4. As a specific example, CVE-2022-1292, is listed on the Debian Security Tracker website (https://security-tracker.debian.org/tracker/CVE-2022-1292). According to the Debian Security Tracker, this vulnerability is marked as "fixed" in openssl 1.1.1n-0+deb11u4. However, Dependency-Track still reports this CVE as a vulnerability in the package version 1.1.1n-0+deb11u4.

I would appreciate it if you could kindly clarify the reasons for this discrepancy. Specifically, I would like to understand if the CVEs mentioned in Dependency-Track for openssl 1.1.1n-0+deb11u4 are indeed still valid, or if there are any mitigations or additional patches applied that make them non-applicable.

Best regards,

[Trakeur]

Hi,
Dependency track components are identified using CPE or PURL, but most of the time - at least in my personal experience - patches are not taken into account, so the vulnerabilities detected concern the initial version of the component.

You can, however, set a patch status on the vulnerability once it has been detected in the tool.

[chpark-edmunds]

Hi @Trakeur , could you clarify how to set a patch status for the vulnerability? Do you mean setting it to false positive and suppressing it in the project or something else?

Also is there a way to apply this to all projects? For example, a global rule that "1.1.1n-0+deb11u5" should ignore "CVE-2022-1292" in all projects since it is fixed in that version.

[Trakeur]

Hi,
Yes, that's basically what I meant, once the vulnerability has been detected (and is therefore not applicable) you can set the status to false positive or patched and remove it. However, I don't think there are any mechanisms for ignoring vulnerabilities for certain patches.

Possibly create a policy associated with this component to be alerted to its presence in a project, but I'm not sure that's really useful.