search

jeremylong / DependencyCheck

OWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.
https://owasp.org/www-project-dependency-check/
Apache License 2.0
6.3k stars 1.26k forks source link

Improper check on Maven-Dependencies that share part of their artifact name with a maybe evidental other library #6912

Closed mischoem closed 3 weeks ago

mischoem commented 3 weeks ago

Describe the bug We wrote an convinient wrapper regarding liquibase. Because of our architectural requirements we have to call that artifact "techbase-liquibase-core", and we release it in a lower version than the "real" liquibase-core in its dependencies. The CVE check treats "our" version same as the "real" liquibase-core and points out a CVE that is not existing. As you can see in the attached example, seems that every dependency, thats artifacts name is similar to or containing the literal "liquibase-core" is treated as "liquibase-core".

Version of dependency-check used Maven -> dependency-check-maven:10.0.3:aggregate

Log file I added a small maven project, where you can recreate the behaviour easily. Just call "mvn verify" on the root project. It contains two modules in a Reactor: 1) foo-liquibase-core: contains a Dummy class, nothing to worry about and no dependencies 2) a-client: uses foo-liquibase-core as dependency

To Reproduce Steps to reproduce the behavior:

  1. Unzip the atttached file owasp-test.zip
  2. Be sure to have a running Maven environment
  3. Call "mvn verify" on the root project
  4. CVE (9.8 Score) is detected where CVE could never be.

Expected behavior No CVE findings and no matching to the real "liquibase-core"

Additional context

jeremylong commented 3 weeks ago

See the following articles:

https://jeremylong.github.io/DependencyCheck/general/internals.html https://jeremylong.github.io/DependencyCheck/general/thereport.html https://jeremylong.github.io/DependencyCheck/general/suppression.html

jeremylong commented 3 weeks ago

The solution is to simply create a suppression file for you scans.

mischoem commented 3 weeks ago

The solution is to simply create a suppression file for you scans. Hi @jeremylong,

Thanks for the quick response! Suppressing this one case might be a good workaround for us, but I (and my colleagues) can't believe that the behavior shown in the simple example above is the expected behavior of the tool.

When using a Lucene index: Could this issue be related to the standard tokenization in Lucene, which splits tokens at dashes, making it difficult for the search to differentiate between "liquibase core" and "foo liquibase core"?

jeremylong commented 3 weeks ago

This could get better for some analysis when we change to a different data source (see https://github.com/jeremylong/DependencyCheck/issues/6540). But for now - this is how it works.

If the matching was more strict in the lucene index - we would end up having false positives instead of false negatives.

jeremylong commented 3 weeks ago

wow, I just reread what I wrote and I flipped the false positives and negatives. If we used stricter matching in the lucene index there would be more false negatives.