The maven plugin does not take into account the vendor, hence many false positives

[zenonwch]

Describe the bug
We have the federation-graphql-java-support-api dependency in our project, but the dependency-check-maven plugin reports a HIGH vulnerability for it with references for the other vendor library cpe:2.3:a:apollo_project:apollo:2.0.8:::::::*.

The pkg:maven/com.apollographql.federation/federation-graphql-java-support-api@2.0.8 has no any known vulnerability nor in the OSS INDEX nor in the NVD

This is not the first time when the plugin matches only a "couple of symbols" from the library naming (in the current case the word apollo) instead of matching the whole vendor and library names. (#6538)

Version of dependency-check used
The problem occurs using versions 8.4.3 and 9.1.0 of the Maven plugin

To Reproduce
Steps to reproduce the behavior:

1. Add the federation-graphql-java-support-api library to the maven dependencies of the project
2. Run the dependency-check-maven plugin

Expected behavior
Only vulnerabilities related to the project's dependencies are present in the dependency-check-maven plugin's report

[zenonwch]

Another one example

The plugin mixed up our library with the library from the Maven repo

[OrangeDog]

The maven group and the CPE vendor often differ for major products. Also, many forks would have a different vendor but have the same vulnerabilities from the shared code.

It is better IMO to have a few false positives like these that you can notice and suppress, than to have many silent false negatives.

Though I agree that dependency check does get a little overenthusiastic about matching these x_project:x CPEs to anything containing the word x. It doesn't account for Bayes' theorum, unfortunately.

Your second example is because you've named your project exactly the same as a popular open source project. Even a human would assume it's a fork from a first glance.

[zenonwch]

I expect that each fork should have its own CPE. What if I fork a project without vulnerabilities, but introduce them in my forked version? By such logic - a project will have a false negative.

[OrangeDog]

If someone reports a CVE specifically in that fork then it will get its own CPE, but the NVD is not going to actively track every time anyone makes a fork of anything, even if that were possible to do.

All vulnerabilities that have been introduced but not yet reported are "false negatives", wherever they are.

[zenonwch]

And one more: what if I fork a library with vulnerability and give it a totally different name?
How plugin will detect that my forked version has a vulnerability?
IMHO: it's strange to try to "predict" vulnerabilities in a "might be" forked libraries.

Maybe it would be nice to have a configuration flag, that allows to switch on/off strict library name comparison.

[OrangeDog]

It doesn't detect it, nor does it try to predict anything.
It's just trying to match artefacts to CPEs, and being strict about it would miss a huge number of issues.

[zenonwch]

But I have feelings, that plugin even doesn't try, just found similar letters in the dependency that I use, and in the CPE dependency 😄 .
Anyway - the ability to change comparison behavior would be appreciated.

[aikebah]

Feel free to build and maintain a full packageUrl-to-CPE index API covering all publicly available packages and we might consider after some time to take it as a trustworthy source of CPE attribution.

Unfortunately there is no authoritive resource to map a library from package coordinates to a CPE, so fuzzy matching and taking the best available match is the best we can do for now (but, as already documented, has a chance of surfacing false positives, for which the suppression mechanism was introduced)

[aikebah]

Vendor is incorporated in the matching logic, but not as an authoritive field for the CPE vendor, as there are many cases where vendor in CPE does not match vendor in pom-file.

[zenonwch]

@OrangeDog, @aikebah - thanks for the responses.
Will close the question.