Several false positives with version 4.0.1

This is a continued issue of #1580 with version 4.0.1 Even though the number of false positives has reduced, there are still several false positives left, e.g.:

javax.annotation-api-1.2.jar: ids:(cpe:/a:oracle:glassfish:1.2, javax.annotation:javax.annotation-api:1.2) : CVE-2013-2566, CVE-2015-2808
jersey-apache-client4-1.19.1.jar: ids:(cpe:/a:oracle:oracle_client:1.19.1, com.sun.jersey.contribs:jersey-apache-client4:1.19.1) : CVE-2006-0550

Simply incrementing the filter score to 30 is no proper solution. You will end up with several more false positives with the new version in contrast to version 3.3.4 (as you can already see by the list of created issues in the recent days). And even more important: As the score of searches can’t be predicted in any way (it might be 5 or one million), you might even end up with false negatives, which would be even more worse.

[GFriedrich]

@jeremylong I’m using dependency-check for about a year now and I really appreciate the work on this project. I’m familiar with the solution to suppress false positives and that they may appear. Nevertheless my feeling is that with the current solution (after updating the Lucene version and adapting the filter score) the situation worsened by a factor X (in both ways: false positives and false negatives) and I’m wondering whether there is a better solution to this. I’ve thought about it in the last couples of days and I’m wondering whether it’s possible to kind of “disable” the breaking build for identifiers with a “low” confidence, because at least to me the false positives only happened for these. So instead of breaking the build for all vulnerabilities, it should only print a warning for those with a “low confidence”. What do you think about that? Do you have “real world” situations, where only the low confidence identities match the real vulnerabilities? I think I will try that solution with a patch and get back at you with the results once I’m done.

[jeremylong]

@malejpavouk

Running a full update:

• Using 4.0.2 CLI -: [INFO] Check for updates complete (136559 ms)
• Using 5.0.0-SNAPSHOT - full update: [INFO] Check for updates complete (163898 ms)

So the update time has unfortunately increased slightly. However, we are storing a data in a more parsed version (for instance, CPEs instead of being stored as vendor, product, CPE - each field of the CPE:2.3 is stored separately); in the end this helps improves the analysis. However, if implemented correctly in an environment the data file would be stored between executions - so the ~2-3 minutes to perform the update should really be a one time hit.

Scanning my entire local maven repository -

• Using 4.0.2 CLI [INFO] Analysis Complete (448 seconds)
• Using 5.0.0-SNAPSHOT CLi [INFO] Analysis Complete (228 seconds)

The biggest improvements were around the JAR and Archive Analyzers. So for some projects the improvement is likely negligible. But I know we have a few users with very large projects that will see a definite improvement (of course only when they are able to save the DB between builds).