False Positive on jenkins.war: LTS versions

[jeremylong]

False positives exist due to how LTS versions are listed in the NVD. See https://github.com/jeremylong/DependencyCheck/issues/3364#issuecomment-888560473

[haugsrud]

Is there any way to get around this? I assume I have this issue for one of my applications where it lists 380 vulnerabilities all referring to an older Jenkins-version that I am actually running. When I run this project locally I get 0 vulnerabilities, and I guess that comes from me not running Jenkins locally?

[aikebah]

Is there any way to get around this? I assume I have this issue for one of my applications where it lists 380 vulnerabilities all referring to an older Jenkins-version that I am actually running. When I run this project locally I get 0 vulnerabilities, and I guess that comes from me not running Jenkins locally?

@haugsrud That's not the item that this issue is about. Your scan shows a false-positive match of some EJB-jar that, with the evidences encountered, is detected (with LOW confidence) as the Jenkins product. So your issue is a regular false-positive. The typical resolution for such a FP is to add a CPE suppression for jenkins to the suppression-filter in your project.

The most likely causes for a different results locally are either

• a different scan compared to the scan command that runs on Jenkins (other scan arguments, different versions of dependency-check, different tool e.g. CLI on Jenkins versus gradle-plugin locally)
• meta-data in the jar-file containing the term 'Jenkins' on a build-artifact built on your Jenkins server and something else (e.g. your username) on a local build. Whether this is the case you can find out by comparing the 'Evidence' section of the mentioned jar-file between the report on Jenkins and your local report. If Jenkins shows evidences that contain (case-insensitive) 'jenkins' which do not appear on your local scan that that's an indicator for the root-cause of your false-posiitive.

This issue is about the fact that when DependencyCheck scans an actual war-file of Jenkins itself for an LTS version it does not detect the LTS nature of it and flags issues that are not applicable as the LTS version has been patched. Regular Jenkins versions follow major.minor model, LTS versions follow major.minor.lts-revision model, where major.minor is some selected older version of Jenkins.

Within the NVD the Jenkins versions are listed in two patterns for the versions that a CVE applies to

• 'regular/weekly' jenkins releases up-to (including) majorA.minorB
• 'stable/LTS' jenkins release up-to (including) majorX.minorY.revisionZ

As Dependency-check doesn't currently support the LTS pattern that's used in the NVD it compares the LTS's majorX.minorY.revisionZ to the regular majorA.minorB and flags the LTS as vulnerable.

E.g. for https://nvd.nist.gov/vuln/detail/CVE-2021-21697 DependencyCheck currently flags LTS version 2.303.3 (which contains the patch) as vulnerable because 2.303.3 is not higher than 2.318 - the last of the weekly releases that still contains the vulnerability