New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The maven plugin does not take into account the vendor, hence many false positives #6658
Comments
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 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. |
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. |
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. |
And one more: what if I fork a library with vulnerability and give it a totally different name? Maybe it would be nice to have a configuration flag, that allows to switch on/off strict library name comparison. |
It doesn't detect it, nor does it try to predict anything. |
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 😄 . |
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) |
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. |
@OrangeDog, @aikebah - thanks for the responses. |
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:
Expected behavior
Only vulnerabilities related to the project's dependencies are present in the dependency-check-maven plugin's report
The text was updated successfully, but these errors were encountered: