Hans Aikema

This is a finding originating from OSSINDEX, which has recently exposed more of its vulnerability research. Experience from earlier FP reports suggests that the finding is likely to be correct....

Dependency Check Azure DevOps Extension is a wrapper to run the CLI. That will indeed not work for gradle projects (that is to say: it will not detect any of...

While this is a false positive I would not recommend depending on the library. The library is in the dormant section of apache commons. https://commons.apache.org/dormant.html https://commons.apache.org/dormant/commons-discovery/index.html On top of that...

First of all I would suggest bumping DC to 7.1.1 (though I doubt whether it will solve your current issue it would at least save you having to do FP...

for b) the answer is in your report `/build/workspace/ntingApplication_master-depcheck/target/dependency-check-report.html` if you retrieve that and open it in your browser there should will be a 'suppress' link next to the CVE...

That sounds like a bug to me, I'll try and see if I can reproduce it. For in-reactor dependencies it should use the information available in the reactor.

What is the overall structure of your multimodule project? ear-file module side by side with the war-file module and maybe some supporting library modules under a multimodule umbrella project as...

Curious if in your report you see the same as I see in my quick-n-dirty reproducer attempt: a double listing of the dependencies of your war artifact - both as...

that duplicate library with the war-file-colon-prefix in the Dependency column would then likely be the one not sensitive to your suppression-file, while the first (the plain library name as a...

Appears to work without issues as long as the release-version of the war is not available in the maven local repository (e.g. if you run the dependency-check:aggregate in your build...