Vulnerability Id missmatch since Version 8.0.0

[fahol-coop]

Describe the bug since Version 8.0.0 we have problems with the dependency core.wcm.components.core-2.23.2.jar. The project is identified as the CMS Project itself, instead of a dependency that can be part of the CMS.

looks like the CPE has a missmatch here. Older Versions don't have this issue, So it's something since the breaking change in Version 8.0.0

Version of dependency-check used The problem occurs using version 8.0.0+ Log file dependency-check Version 7.4.4, returns the mapping for core components without the critical CVE's (cpe:2.3:a:adobe:adobe_consulting_services_commons:2.23.2:::::::) --> OK dependency-check Version 8.0.0 and higher, returns the mapping for core components with the critical CVE's (cpe:2.3:a:adobe:download_manager:2.23.0:::::::) --> Wrong

To Reproduce Steps to reproduce the behavior:

com.adobe.cq core.wcm.components.core 2.23.2

1. Add Dependency to your pom
2. start owasp check with Version 7.4.4
3. start owasp check with Version 8.0.0+
4. compare cpe's

Expected behavior Version 8.0.0 should work the same as Version 7.4.4.

[aikebah]

@fahol-coop why would you expect us to report vulnerabilities for another inappropriate CPE just because we used to do so in the past?

https://github.com/Adobe-Consulting-Services/acs-aem-commons (the github project for the CPE you mention for 7.4.4) is just as invalid as the CPE that 8.0.0 establishes.

Your library is at https://github.com/adobe/aem-core-wcm-components/tree/main

[fahol-coop]

if the old one was also wrong, then both are Wrong.

I correct my question. What should happen, that the correct CPE is connected to the library? Because the current state shows a lot of CVE's that doesn't match.

[aikebah]

http://jeremylong.github.io/DependencyCheck/general/suppression.html

If you file an FP report for the 8.x case quoting the incorrect CPE from its report we can easily include the required suppression into the hosted suppressions file that is consulted by DependencyCheck 8.x.

There is likely to not be a correct CPE within the NVD datafeed (if there was one it would've likely been matched already instead of the current and previous inappropriate ones; most likely there was never a CVE for this set of libraries).

[fahol-coop]

there are 3 wrong mappings for this dependency in Version 8.x.x.

I found no official place for reporting. Do you know if something exists?

Suppressions:

`

^pkg:maven/com\.adobe\.cq/core\.wcm\.components\.core@.*$ cpe:/a:adobe:download_manager

`

`

^pkg:maven/com\.adobe\.cq/core\.wcm\.components\.core@.*$ cpe:/a:adobe:experience_manager

`

`

^pkg:maven/com\.adobe\.cq/core\.wcm\.components\.core@.*$ cpe:/a:adobe:experience_manager_forms

`

[aikebah]

@fahol-coop when you click 'create issue' from withn this github repo one of the items is "false positive report" when you click the button for it you get a form in which you can fill the details of the false-positive

[fahol-coop]

New false positive report issues created. https://github.com/jeremylong/DependencyCheck/issues/5904 https://github.com/jeremylong/DependencyCheck/issues/5905 https://github.com/jeremylong/DependencyCheck/issues/5906

This ticket can be closed

[fahol-coop]

@aikebah the suppressions are working. But now there is a new issue. There are 4 others CPE that doesn't match the dependency.

cpe:2.3:a:adobe:form_client:2.23.2::::::: cpe:2.3:a:list_site_pro:list_site_pro:2.23.2::::::: cpe:2.3:a:oembed_project:oembed:2.23.2::::::: cpe:2.3:a:xml_library_project:xml_library:2.23.2:::::::

What is the commen way to fix that?

[aikebah]

For now:further suppressions to also remove these false positives... (if you file the FP reports for these CPEs I'll arrange that the suppressions get published)

Root cause is the way DependencyCheck works and the lack of CVEs registered for wcm core (see also the information in the documentation on false positives I posted above) By suppressing the 'best matches' ODC is now linking the 'next best matches' from CPEs that appear in the NVD vulnerability data that appear to match the collected evidences (the evidences are in a collapsed section of the HTML report that DependencyCheck creates)

While getting these out of the way with suppressions is a good short-term measure I've also spotted a way to potentially improve the results a bit (by ignoring some more OSGi related Manifest entries) which I'll work on to get a PR out for a future release of DependencyCheck.

[fahol-coop]

Issues created

https://github.com/jeremylong/DependencyCheck/issues/5908 https://github.com/jeremylong/DependencyCheck/issues/5909 https://github.com/jeremylong/DependencyCheck/issues/5910 https://github.com/jeremylong/DependencyCheck/issues/5911

[aikebah]

@fahol-coop With these now also in place according to my validation run ODC has finally agreed with us that whatever a proper CPE would be for this library it's not one of the CPEs that appear in the NIST NVD vulnerabilities database.

[aikebah]

To force a refresh of the hostedSuppressionsFile if you have the caching enabled (that is: do not run the tool in a newly created blank environment) you can use the 'hosted suppressions valid for hours' option of your build-tool with a value of 0 to force an immediate refresh (otherwise the cached copy will only expire after 2 hours)

E.g. for the Maven plugin that would be mvn -DhostedSuppressionsValidForHours=0 ...your-regular-build-arguments

[fahol-coop]

@aikebah thank you for your help. It's working now, I have testet it in my local IDE.