Different false-positives on different systems with identical configuration (maven-plugin)

[BenniG82]

trafficstars

Describe the bug After upgrading to version 9 of the dependency-check-maven plugin, we have observed an inconsistent number of false positives across different systems, despite having identical configurations.

We are running the following command:

mvn --batch-mode org.owasp:dependency-check-maven:aggregate -DskipTests=true -Dformats=HTML,JSON,XML

we run aggregate here, because our real project is a multi module maven project, running the "check" goal causes the same behavior

On most systems the minimal pom.xml causes the following findings:

commons-compress-1.23.0.jar (pkg:maven/org.apache.commons/[email protected], cpe:2.3:a:apache:commons_compress:1.23.0:*:*:*:*:*:*:*) : CVE-2023-42503
de.flapdoodle.embed.mongo-4.9.2.jar (pkg:maven/de.flapdoodle.embed/[email protected], cpe:2.3:a:mongodb:mongodb:4.9.2:*:*:*:*:*:*:*) : CVE-2014-8180
de.flapdoodle.embed.mongo.packageresolver-4.9.1.jar (pkg:maven/de.flapdoodle.embed/[email protected], cpe:2.3:a:mongodb:mongodb:4.9.1:*:*:*:*:*:*:*) : CVE-2014-8180
spring-boot-3.0.4.jar (pkg:maven/org.springframework.boot/[email protected], cpe:2.3:a:vmware:spring_boot:3.0.4:*:*:*:*:*:*:*) : CVE-2023-20873, CVE-2023-20883, CVE-2023-34055
spring-core-6.0.6.jar (pkg:maven/org.springframework/[email protected], cpe:2.3:a:pivotal_software:spring_framework:6.0.6:*:*:*:*:*:*:*, cpe:2.3:a:springsource:spring_framework:6.0.6:*:*:*:*:*:*:*, cpe:2.3:a:vmware:spring_framework:6.0.6:*:*:*:*:*:*:*) : CVE-2023-20860, CVE-2023-34053, CVE-2023-20861, CVE-2023-20863

The issues found with flapdoodle are false-positives because the CVEs are actually about MongoDB itself, not the flapdoodle JAR files.

On some systems these false-positives are not found and only the following output is generated:

commons-compress-1.23.0.jar (pkg:maven/org.apache.commons/[email protected], cpe:2.3:a:apache:commons_compress:1.23.0:*:*:*:*:*:*:*) : CVE-2023-42503
spring-boot-3.0.4.jar (pkg:maven/org.springframework.boot/[email protected], cpe:2.3:a:vmware:spring_boot:3.0.4:*:*:*:*:*:*:*) : CVE-2023-20873, CVE-2023-20883, CVE-2023-34055
spring-core-6.0.6.jar (pkg:maven/org.springframework/[email protected], cpe:2.3:a:pivotal_software:spring_framework:6.0.6:*:*:*:*:*:*:*, cpe:2.3:a:springsource:spring_framework:6.0.6:*:*:*:*:*:*:*, cpe:2.3:a:vmware:spring_framework:6.0.6:*:*:*:*:*:*:*) : CVE-2023-20860, CVE-2023-34053, CVE-2023-20861, CVE-2023-20863

During the analysis of the issue, I also managed to produce different behaviors on the same system. So, the problem likely isn't caused by different Java versions or environmental settings. In my tests, among other things, I experimented with the "dataDirectory" setting.

minimal pom.xml

Version of dependency-check used The problem occurs using version 9.0.7 of the maven plugin

Log file Log file of a run without false positives: https://gist.github.com/BenniG82/38eb7f75128b667961a071192da001d8 Log file of a run with false positives: https://gist.github.com/BenniG82/5349c685ed41d5f1ed0059f412a9bc08

To Reproduce Steps to reproduce the behavior:

1. Use the minimal pom.xml
2. Run mvn --batch-mode org.owasp:dependency-check-maven:aggregate -DskipTests=true -Dformats=HTML,JSON,XML
3. Check the output of found issues.

Expected behavior The findings should be consistent across all environments using the same configuration.

Additional context I noticed that the size of the database file odc.mv.db was different between the systems (127.6MB vs. 128.7MB). So, I tried using the odc.mv.db file from a system without false-positives on one that had false-positives, and the false-positives disappeared. This makes me think something may have went wrong when matching data with the NVD.

Sadly, I couldn't find any differences in the content of the two databases. All the tables have the same number of entries, and the results from the SQL below look the same to me, except for the different database IDs.

select * from VULNERABILITY vuln
                  join PUBLIC.SOFTWARE software on software.CVEID = vuln.ID
                  join PUBLIC.CPEENTRY entry on entry.ID = software.CPEENTRYID
where vuln.CVE='CVE-2014-8180';

Output from Database causing false positives:

87125,CVE-2014-8180,MongoDB on Red Hat Satellite 6 allows local users to bypass authentication by logging in with an empty password and delete information which can cause a Denial of Service.,LOW,3.9,2.9,true,false,false,false,false,2.1,LOCAL,LOW,NONE,NONE,NONE,PARTIAL,2.0,1.8,3.6,LOCAL,LOW,LOW,NONE,UNCHANGED,NONE,NONE,HIGH,5.5,MEDIUM,3.0,87125,97571,,,,,true,97571,a,mongodb,mongodb,*,*,*,*,*,*,*,*,native
87125,CVE-2014-8180,MongoDB on Red Hat Satellite 6 allows local users to bypass authentication by logging in with an empty password and delete information which can cause a Denial of Service.,LOW,3.9,2.9,true,false,false,false,false,2.1,LOCAL,LOW,NONE,NONE,NONE,PARTIAL,2.0,1.8,3.6,LOCAL,LOW,LOW,NONE,UNCHANGED,NONE,NONE,HIGH,5.5,MEDIUM,3.0,87125,145458,,,,,false,145458,a,redhat,satellite,6.0,*,*,*,*,*,*,*,

Output from Database without false positives:

75706,CVE-2014-8180,MongoDB on Red Hat Satellite 6 allows local users to bypass authentication by logging in with an empty password and delete information which can cause a Denial of Service.,LOW,3.9,2.9,true,false,false,false,false,2.1,LOCAL,LOW,NONE,NONE,NONE,PARTIAL,2.0,1.8,3.6,LOCAL,LOW,LOW,NONE,UNCHANGED,NONE,NONE,HIGH,5.5,MEDIUM,3.0,75706,121951,,,,,true,121951,a,mongodb,mongodb,*,*,*,*,*,*,*,*,native
75706,CVE-2014-8180,MongoDB on Red Hat Satellite 6 allows local users to bypass authentication by logging in with an empty password and delete information which can cause a Denial of Service.,LOW,3.9,2.9,true,false,false,false,false,2.1,LOCAL,LOW,NONE,NONE,NONE,PARTIAL,2.0,1.8,3.6,LOCAL,LOW,LOW,NONE,UNCHANGED,NONE,NONE,HIGH,5.5,MEDIUM,3.0,75706,170642,,,,,false,170642,a,redhat,satellite,6.0,*,*,*,*,*,*,*,

I've uploaded the pom.xml, a part of our supressions.xml, the logfiles and the TARed Databases to this repo: https://github.com/BenniG82/owasp-false-positives-problem/tree/master

[BenniG82]

After further investigation I found out, that this behavior is caused by different "ecosystems" for the same cpeEntries in the different DBs.

When executing the following SQL query:

SELECT part, vendor, product, version, update_version, edition, lang, sw_edition, target_sw, target_hw, other, ecosystem
FROM cpeEntry
WHERE vendor = 'mongodb'
  AND product = 'mongodb'

I observed that within the 'no_false_positives_db', I receive 53 entries, each with an 'ecosystem' labeled as "native". Conversely, in the 'with_false_positives_db', although I also retrieve 53 entries, only 23 of them are labeled "native" for the 'ecosystem', with the rest being null.

From what I've determined, this discrepancy leads to an empty 'cpes' set at CPEAnalyzer#determineIdentifiers, as the filterEcosystem fails to find any matches for my dependency from the "java" ecosystem when there are no cpePlusEntries with a "null" ecosystem.

protected boolean determineIdentifiers(Dependency dependency, String vendor, String product,
            Confidence currentConfidence) throws UnsupportedEncodingException, AnalysisException {

        final CpeBuilder cpeBuilder = new CpeBuilder();

        final Set<CpePlus> cpePlusEntries = cve.getCPEs(vendor, product);
/* => */        final Set<Cpe> cpes = filterEcosystem(dependency.getEcosystem(), cpePlusEntries); // <== 
        if (cpes == null || cpes.isEmpty()) {
            return false;
        }

So far, it looks to me like creating/updating the CVE database isn't 100% deterministic.

[jeremylong]

Thank you for the investigation on this. I have the databases - but I'll need to review the logic on the ecosystem to figure out what can cause this.

[BenniG82]

@jeremylong To provide as much info as possible: Both databases where created "from scratch". I didn't have any older db-Versions on my testing machine and for both it was the very first and only update.

[aikebah]

@jeremylong #6300 is also showing these kinds of ecosystem inconsistencies